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. - 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 > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
