Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Andreas Leha andreas.l...@med.uni-goettingen.de writes: On the ess list (emacs.ess.general) there has been the announcement [fn:2] of polymode [fn:1] recently, which is going in this direction. True - sounds very much like what Eric mentioned. I poster a question there [1]to see if Vitalie could implement support for org mode. Since my elisp knowledge is limited to the least, this comment might be irrelevant here, in which case please ignore it. Not at all - don't worry. Your comment is spot on. Cheers, Rainer Regards, Andreas Footnotes: [fn:1] https://github.com/vitoshka/polymode [fn:2] http://comments.gmane.org/gmane.emacs.ess.general/6994 #secure method=pgpmime mode=sign Footnotes: [1] https://github.com/vitoshka/polymode/issues/9 -- Rainer M. Krug email: RMKrugatgmaildotcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
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. 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: RMKrugatgmaildotcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Sebastien Vauban sva-n...@mygooglest.com writes: Hi Carsten, Carsten Dominik wrote: On 24.9.2013, at 18:17, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I only mean while there is a special buffer also editing this block! Pfff! I'm relieved -- I should have understood it ;-) While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. Cheers, Rainer Best regards, Seb #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
On 25.9.2013, at 08:53, Rainer M Krug rai...@krugs.de wrote: Sebastien Vauban sva-n...@mygooglest.com writes: Hi Carsten, Carsten Dominik wrote: On 24.9.2013, at 18:17, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I only mean while there is a special buffer also editing this block! Pfff! I'm relieved -- I should have understood it ;-) While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. This is very complicated, because such functionality needs the entire environment of a mode. I think there are some solutions which allow multiple major modes - but I don't think we will go there with Org. However, I think this is really a question to Eric Schulte (in CC). - Carsten Cheers, Rainer Best regards, Seb #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
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: RMKrugatgmaildotcom signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
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: RMKrugatgmaildotcom #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Carsten Dominik carsten.domi...@gmail.com writes: On 25.9.2013, at 08:53, Rainer M Krug rai...@krugs.de wrote: Sebastien Vauban sva-n...@mygooglest.com writes: Hi Carsten, Carsten Dominik wrote: On 24.9.2013, at 18:17, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I only mean while there is a special buffer also editing this block! Pfff! I'm relieved -- I should have understood it ;-) While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. This is very complicated, because such functionality needs the entire environment of a mode. I think there are some solutions which allow multiple major modes - but I don't think we will go there with Org. This is definitely not an easy task, but which I think would be an very useful feature, making the work-flow of using embedded code much faster. However, I think this is really a question to Eric Schulte (in CC). Would be great, if there is would be a way of implementing this in the medium future. Cheers, Rainer - Carsten Cheers, Rainer Best regards, Seb #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom -- Rainer M. Krug email: RMKrugatgmaildotcom pgpFHaWFRygXe.pgp Description: PGP signature
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. This is very complicated, because such functionality needs the entire environment of a mode. I think there are some solutions which allow multiple major modes - but I don't think we will go there with Org. This is definitely not an easy task, but which I think would be an very useful feature, making the work-flow of using embedded code much faster. I don't think this is an attainable goal. Major modes assume that they are the sole owners of the current buffer and of the related state. Breaking this assumption would open a deep can of major-mode-specific problems which would each require major-mode-specific solutions. The only solution I see would be to somehow give each code block it's own buffer, and then trick Emacs into treating multiple buffers as a single buffer for purposes of display and cursor movement. If someone wanted to develop such functionality I think it would best be done independent of Org-mode. Best, -- Eric Schulte https://cs.unm.edu/~eschulte PGP: 0x614CA05D
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Eric Schulte schulte.e...@gmail.com writes: While we are at editing code blocks inline (I also do this quite often). This might have been asked before, but in code blocks we have - syntax highlighting - indenting using the code block language settings but would it be possible to have, when the cursor is in a code block, the menus and shortcuts for the language mode enabled, i.e. complete support for editing the code block language, as in the special buffer, but inline in org? Evaluationg single lines of code directly from the code block in org would be *brilliant*. This is very complicated, because such functionality needs the entire environment of a mode. I think there are some solutions which allow multiple major modes - but I don't think we will go there with Org. This is definitely not an easy task, but which I think would be an very useful feature, making the work-flow of using embedded code much faster. I don't think this is an attainable goal. Major modes assume that they are the sole owners of the current buffer and of the related state. Breaking this assumption would open a deep can of major-mode-specific problems which would each require major-mode-specific solutions. I agree that sounds quite difficult, especially as it would involve quite a number of different modes when different languages are used. The only solution I see would be to somehow give each code block it's own buffer, and then trick Emacs into treating multiple buffers as a single buffer for purposes of display and cursor movement. If someone wanted to develop such functionality I think it would best be done independent of Org-mode. Keep in mind my very limited emacs knowledge - but wouldn't it be possible to switch between modes depending where the cursor is? This would mean the buffer is in R-mode, when the cursor is in a R code block, and in org-mode, when the cursor is outside. One could even enable minor-org-mode to keep some functionality n the code blocks? I know this would not be ideal, but wouldn't that be possible? Thanks a lot, Rainer Best, #secure method=pgpmime mode=sign -- Rainer M. Krug email: RMKrugatgmaildotcom
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
On the ess list (emacs.ess.general) there has been the announcement [fn:2] of polymode [fn:1] recently, which is going in this direction. Since my elisp knowledge is limited to the least, this comment might be irrelevant here, in which case please ignore it. Regards, Andreas Footnotes: [fn:1] https://github.com/vitoshka/polymode [fn:2] http://comments.gmane.org/gmane.emacs.ess.general/6994
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hi before this gets lost - I think this is an serious bug, as it can easily lead to data loss. Thanks, Rainer Rainer M Krug rai...@krugs.de writes: 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. Rainer -- Rainer M. Krug email: RMKrugatgmaildotcom pgpra9bI3_smn.pgp Description: PGP signature
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
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. 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. 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. 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? 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) signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hello Carsten, Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I hope that we will block such a functionality, would the read-only feature become possible. 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? Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
On 24.9.2013, at 18:17, Sebastien Vauban sva-n...@mygooglest.com wrote: Hello Carsten, Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. Hi Sebastian, I only mean while there is a special buffer also editing this block! - Carsten I hope that we will block such a functionality, would the read-only feature become possible. 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? Best regards, Seb -- Sebastien Vauban signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [O] [BUG] in Release 8.2 - editing code in indirect buffer
Hi Carsten, Carsten Dominik wrote: On 24.9.2013, at 18:17, Sebastien Vauban sva-n...@mygooglest.com wrote: Carsten Dominik wrote: On 23.9.2013, at 09:40, Rainer M Krug rai...@krugs.de wrote: 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. 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. I never knew that your goal was to make the code block read-only in the Org buffer. Note that I would be really opposed to such a change. Editing code in the prose would really become a pain to me -- please know that I NEVER use the indirect buffer. I only mean while there is a special buffer also editing this block! Pfff! I'm relieved -- I should have understood it ;-) Best regards, Seb -- Sebastien Vauban
