Carsten Dominik <carsten.domi...@gmail.com> writes: > On 25.9.2013, at 08:48, Rainer M Krug <rai...@krugs.de> wrote: > >> Carsten Dominik <carsten.domi...@gmail.com> writes: >> >>> Hi Rainer, hi Carsten, >>> >>> it does not get lost - it is in my queue. As are, unfortunately, >>> another 35 threads with possible bugs. Help is definitely wanted. >> >> That's what I was looking for - confirmation that is in somebodys >> processing queue. Thanks Carsten. >> >> Unfortunately I can't hel as I have barely the elisp knowledge to >> maintain my .emacs file. >> >>> >>> Please see below for my comments and a possible fix. >>> >>> On 23.9.2013, at 09:40, Rainer M Krug <rai...@krugs.de> wrote: >>> >>>> I just resend this bug report which has been confirmed by Ista Zahn. >>>> >>>> Updated via git ust now: >>>> >>>> Org-mode version 8.2 (release_8.2-14-ge5f16b @ >>>> /Users/rainerkrug/.emacs.d/org-mode/lisp/) >>>> >>>> >>>> When starting to edit a code block via C-c ' everything works as expected >>>> and the code block is highlighted and an indirect buffer is opened. >>>> >>>> When I click into the highlighted block, I an "send" to the indirect >>>> buffer. This behavior changes, after saving with C-s, even when nothing >>>> has been edited: the area in the original org file looses its magic, and >>>> looks normal again and can also be edited! >>>> >>>> The indirect buffer stays functional and, upon close via C-c ' saves the >>>> changes into the original buffer and *overwrites* changes done in this >>>> block in the org document. >>> >>> This is a bug which is difficult to fix in all generality. What >>> should really happen is that the text in the original buffer is made >>> read-only. >> >> Yup - exactly. That would be the best solution. >> >>> But so far this does not happen in our implementation (due >>> to Dan Davison IIRC). The reason for this is that read-only text >>> properties left by accident in a buffer are difficult to get rid of. >>> >>> There are many things the user could go back and screw up the >>> original. That's why Org choses to protect with highlighting with an >>> overlay. Note that this is not a protection against editing, but it >>> is a visual warning. >> >> Possibly because I am using the mouse most of the time to navigate in >> text and select buffers, I did not realize this. >> >>> >>> However, what happens during saving is indeed a problem - the overlay >>> gets lost (not really, it gets squeezed to zero by first removing the >>> source code and then inserting the modified version). >>> >>> Could you please try this patch and test it to see if it is stable and >>> does the right thing? >> >> Tried briefly and it seems to work: >> >> 1) the visual overlay stays there upon C-x s from indirect buffer >> >> 2) If I click with the mouse into it, I am redirected to the indirect >> buffer (correct terminology here?) >> >> Let me know when you pushed it to git, than I can upgrade again. > > I pushed this fix to maint and master.
Thanks, Rainer > > - Carsten > >> >> Thanks, >> >> Rainer >> >>> >>> Thank you. >>> >>> - Carsten >>> >>> diff --git a/lisp/org-src.el b/lisp/org-src.el >>> index 0f88174..062d2d7 100644 >>> --- a/lisp/org-src.el >>> +++ b/lisp/org-src.el >>> @@ -757,6 +757,8 @@ with \",*\", \",#+\", \",,*\" and \",,#+\"." >>> (delete-region beg (max beg end)) >>> (unless (string-match "\\`[ \t]*\\'" code) >>> (insert code)) >>> + ;; Make sure the overlay stays in place >>> + (when (eq context 'save) (move-overlay ovl beg (point))) >>> (goto-char beg) >>> (if single (just-one-space)))) >>> (if (memq t (mapcar (lambda (overlay) >>> >>> >> <#secure method=pgpmime mode=sign> >> >> -- >> Rainer M. Krug >> >> email: RMKrug<at>gmail<dot>com >> >> > <#secure method=pgpmime mode=sign> -- Rainer M. Krug email: RMKrug<at>gmail<dot>com
