Release 8.2

Release 8.2

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2876 bytes --]

	
Hi everyone,

I have just released version 8.2 of Org mode.  This is rather a minor release,
mainly designed to do some stabilization and cleanup before the merge
into Emacs.  Bastien will do this next week (?).

Lets keep in mind that this is the first time that version 8 reaches Emacs,
so we can assume wider distribution, and possibly more issues and complaints
as the incompatible changes in version 8 reach this wider audience.  So we
should be prepared for the possibility of a more intensive period of questions.
We will see - I hope everything goes well.

Thanks to everyone who contributed to this release.

Enjoy!

- Carsten


Incompatible changes
====================

`xdg-open' has been removed again from `org-file-apps-defaults-gnu'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  This did not work properly in some environments as xdg-open is desktop
  specific.


Important bug fixes
===================

Match string for sparse trees can now contain a slash in a property value
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  You can now have searches like SOMEPROP="aaa/bbb".  Until now, this
  would break because the slash would be interpreted as the separator
  starting a TOTO match string.


New features
============

Changes in the default packages loaded for LaTeX
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  - `rotating' is now a default package, to support sideways tables.
  - `amsmath' is a default package
  - `eucal' package removed, no longer needed since amsmath is present

  Furthermore, the manual now specifically notes if an additional
  package is needed for one of the documented attributes.


Microsoft Outlook support has been added to /org-mac-link.el/
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  Thanks to Marc McLean for this patch.


Lazy autoloading of /org-id.el/ to follow links
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  When following a link that has an `id:' prefix, /org-id.el/ will now
  automatically be loaded.

  Thanks to Oleh for this patch


New functions for paragraph motion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  The commands `C-down' and `C-up' now invoke special commands that use
  knowledge from the org-elements parser to move the cursor in a
  paragraph-like way.

  Thanks to Nicolas Goaziou for the implementation.


New agenda fortnight view
~~~~~~~~~~~~~~~~~~~~~~~~~

  The agenda has not, in addition to day, week, month, and year views,
  also a fortnight view covering 14 days.

  Thanks to Michael Gauland for the implementation.


New options
===========

New option: [org-special-ctrl-o]
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

  This variable can be used to turn off the special behavior of `C-o' in
  tables.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Release 8.2

[Mehul Sanghvi]

[-- Attachment #1.1: Type: text/plain, Size: 3253 bytes --]

Maybe I'm being nit picky but here's a patch to get rid of a warning that
was coming up with lisp/ox-texinfo.el about using old-style backquotes.


cheers,

       mehul



On Thu, Sep 19, 2013 at 4:27 PM, Carsten Dominik
<carsten.dominik@gmail.com>wrote:

>
> Hi everyone,
>
> I have just released version 8.2 of Org mode.  This is rather a minor
> release,
> mainly designed to do some stabilization and cleanup before the merge
> into Emacs.  Bastien will do this next week (?).
>
> Lets keep in mind that this is the first time that version 8 reaches Emacs,
> so we can assume wider distribution, and possibly more issues and
> complaints
> as the incompatible changes in version 8 reach this wider audience.  So we
> should be prepared for the possibility of a more intensive period of
> questions.
> We will see - I hope everything goes well.
>
> Thanks to everyone who contributed to this release.
>
> Enjoy!
>
> - Carsten
>
>
> Incompatible changes
> ====================
>
> `xdg-open' has been removed again from `org-file-apps-defaults-gnu'
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   This did not work properly in some environments as xdg-open is desktop
>   specific.
>
>
> Important bug fixes
> ===================
>
> Match string for sparse trees can now contain a slash in a property value
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   You can now have searches like SOMEPROP="aaa/bbb".  Until now, this
>   would break because the slash would be interpreted as the separator
>   starting a TOTO match string.
>
>
> New features
> ============
>
> Changes in the default packages loaded for LaTeX
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   - `rotating' is now a default package, to support sideways tables.
>   - `amsmath' is a default package
>   - `eucal' package removed, no longer needed since amsmath is present
>
>   Furthermore, the manual now specifically notes if an additional
>   package is needed for one of the documented attributes.
>
>
> Microsoft Outlook support has been added to /org-mac-link.el/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   Thanks to Marc McLean for this patch.
>
>
> Lazy autoloading of /org-id.el/ to follow links
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   When following a link that has an `id:' prefix, /org-id.el/ will now
>   automatically be loaded.
>
>   Thanks to Oleh for this patch
>
>
> New functions for paragraph motion
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The commands `C-down' and `C-up' now invoke special commands that use
>   knowledge from the org-elements parser to move the cursor in a
>   paragraph-like way.
>
>   Thanks to Nicolas Goaziou for the implementation.
>
>
> New agenda fortnight view
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The agenda has not, in addition to day, week, month, and year views,
>   also a fortnight view covering 14 days.
>
>   Thanks to Michael Gauland for the implementation.
>
>
> New options
> ===========
>
> New option: [org-special-ctrl-o]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   This variable can be used to turn off the special behavior of `C-o' in
>   tables.
>
>


-- 
Mehul N. Sanghvi
email: mehul.sanghvi@gmail.com

[-- Attachment #1.2: Type: text/html, Size: 4097 bytes --]

[-- Attachment #2: org-mode-ox-texinfo-backquote-patch.diff --]
[-- Type: application/octet-stream, Size: 915 bytes --]

diff --git a/lisp/ox-texinfo.el b/lisp/ox-texinfo.el
index 30da39d..29fbc07 100644
--- a/lisp/ox-texinfo.el
+++ b/lisp/ox-texinfo.el
@@ -1710,7 +1710,7 @@ file-local settings.
 Return output file's name."
   (interactive)
   (let ((outfile (org-export-output-file-name ".texi" subtreep))
-	(org-export-coding-system ',org-texinfo-coding-system))
+	(org-export-coding-system `,org-texinfo-coding-system))
     (org-export-to-file 'texinfo outfile
       async subtreep visible-only body-only ext-plist)))
 
@@ -1747,7 +1747,7 @@ directory.
 Return INFO file's name."
   (interactive)
   (let ((outfile (org-export-output-file-name ".texi" subtreep))
-	(org-export-coding-system ',org-texinfo-coding-system))
+	(org-export-coding-system `,org-texinfo-coding-system))
     (org-export-to-file 'texinfo outfile
       async subtreep visible-only body-only ext-plist
       (lambda (file) (org-texinfo-compile file)))))

Re: Release 8.2

[Carsten Dominik]

[-- Attachment #1.1: Type: text/plain, Size: 3627 bytes --]

Hi Mehul,

thank you for this, I have made that change.

- Carsten

On 20.9.2013, at 06:32, Mehul Sanghvi <mehul.sanghvi@gmail.com> wrote:

> Maybe I'm being nit picky but here's a patch to get rid of a warning that was coming up with lisp/ox-texinfo.el about using old-style backquotes.
> 
> 
> cheers,
> 
>        mehul
> 
> 
> 
> On Thu, Sep 19, 2013 at 4:27 PM, Carsten Dominik <carsten.dominik@gmail.com> wrote:
> 
> Hi everyone,
> 
> I have just released version 8.2 of Org mode.  This is rather a minor release,
> mainly designed to do some stabilization and cleanup before the merge
> into Emacs.  Bastien will do this next week (?).
> 
> Lets keep in mind that this is the first time that version 8 reaches Emacs,
> so we can assume wider distribution, and possibly more issues and complaints
> as the incompatible changes in version 8 reach this wider audience.  So we
> should be prepared for the possibility of a more intensive period of questions.
> We will see - I hope everything goes well.
> 
> Thanks to everyone who contributed to this release.
> 
> Enjoy!
> 
> - Carsten
> 
> 
> Incompatible changes
> ====================
> 
> `xdg-open' has been removed again from `org-file-apps-defaults-gnu'
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   This did not work properly in some environments as xdg-open is desktop
>   specific.
> 
> 
> Important bug fixes
> ===================
> 
> Match string for sparse trees can now contain a slash in a property value
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   You can now have searches like SOMEPROP="aaa/bbb".  Until now, this
>   would break because the slash would be interpreted as the separator
>   starting a TOTO match string.
> 
> 
> New features
> ============
> 
> Changes in the default packages loaded for LaTeX
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   - `rotating' is now a default package, to support sideways tables.
>   - `amsmath' is a default package
>   - `eucal' package removed, no longer needed since amsmath is present
> 
>   Furthermore, the manual now specifically notes if an additional
>   package is needed for one of the documented attributes.
> 
> 
> Microsoft Outlook support has been added to /org-mac-link.el/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   Thanks to Marc McLean for this patch.
> 
> 
> Lazy autoloading of /org-id.el/ to follow links
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   When following a link that has an `id:' prefix, /org-id.el/ will now
>   automatically be loaded.
> 
>   Thanks to Oleh for this patch
> 
> 
> New functions for paragraph motion
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   The commands `C-down' and `C-up' now invoke special commands that use
>   knowledge from the org-elements parser to move the cursor in a
>   paragraph-like way.
> 
>   Thanks to Nicolas Goaziou for the implementation.
> 
> 
> New agenda fortnight view
> ~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   The agenda has not, in addition to day, week, month, and year views,
>   also a fortnight view covering 14 days.
> 
>   Thanks to Michael Gauland for the implementation.
> 
> 
> New options
> ===========
> 
> New option: [org-special-ctrl-o]
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>   This variable can be used to turn off the special behavior of `C-o' in
>   tables.
> 
> 
> 
> 
> -- 
> Mehul N. Sanghvi
> email: mehul.sanghvi@gmail.com
> <org-mode-ox-texinfo-backquote-patch.diff>


[-- Attachment #1.2: Type: text/html, Size: 4715 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: Release 8.2

[Alexander Baier]

Hello Carsten,

Carsten Dominik <carsten.dominik@gmail.com> writes:

[...]

> New agenda fortnight view
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
>   The agenda has not,

Shouldn't this be "The agenda has now,"?

>   in addition to day, week, month, and year views, also a fortnight
>   view covering 14 days.
>
>   Thanks to Michael Gauland for the implementation.

[...]

I do not know how this changelog was produced and if this was already a
typo in the corresponding commit-message and is not to be changed, but I
thought I mention it anyway.


Regards,
Alex

Re: Release 8.2

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 752 bytes --]

Beste Alex,

this is just my very own stupid typo.  Thanks!

- Carsten

On Sep 20, 2013, at 11:40 AM, Alexander Baier <lexi.baier@gmail.com> wrote:

> Hello Carsten,
> 
> Carsten Dominik <carsten.dominik@gmail.com> writes:
> 
> [...]
> 
>> New agenda fortnight view
>> ~~~~~~~~~~~~~~~~~~~~~~~~~
>> 
>>  The agenda has not,
> 
> Shouldn't this be "The agenda has now,"?
> 
>>  in addition to day, week, month, and year views, also a fortnight
>>  view covering 14 days.
>> 
>>  Thanks to Michael Gauland for the implementation.
> 
> [...]
> 
> I do not know how this changelog was produced and if this was already a
> typo in the corresponding commit-message and is not to be changed, but I
> thought I mention it anyway.
> 
> 
> Regards,
> Alex
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

BUG?: BABEL - Release 8.2

[Rainer M Krug]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> 	
> Hi everyone,
>
> I have just released version 8.2 of Org mode.  This is rather a minor release,
> mainly designed to do some stabilization and cleanup before the merge
> into Emacs.  Bastien will do this next week (?).

Just upgraded, to 8.2 and I found a bug:

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! 

he indirect buffer stays functional and, upon close vie C-c ' saves the
changes into the original buffer and overwrites changes done in this block.

Can somebody please confirm?

Rainer

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

BUG?: BABEL - Release 8.2

[Rainer M Krug]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> 	
> Hi everyone,
>
> I have just released version 8.2 of Org mode.  This is rather a minor release,
> mainly designed to do some stabilization and cleanup before the merge
> into Emacs.  Bastien will do this next week (?).

Just upgraded, to 8.2 and I found a bug:

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! 

he indirect buffer stays functional and, upon close vie C-c ' saves the
changes into the original buffer and overwrites changes done in this block.

Can somebody please confirm?

Rainer

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

Re: Release 8.2

[Suvayu Ali]

On Thu, Sep 19, 2013 at 10:27:35PM +0200, Carsten Dominik wrote:
> 
> Lets keep in mind that this is the first time that version 8 reaches Emacs,
> so we can assume wider distribution, and possibly more issues and complaints
> as the incompatible changes in version 8 reach this wider audience.  So we
> should be prepared for the possibility of a more intensive period of questions.
> We will see - I hope everything goes well.

More users and questions => more bugs discovered & fixed => better Org :)

-- 
Suvayu

Open source is the future. It sets us free.

Re: BUG?: BABEL - Release 8.2

[Rainer M Krug]

Just to reiterate - is this only me or others as well? I consider this
as a serious problem, as it can result in loss of data.

If it is only me, I have to dig deeper into my config.

Cheers,

Rainer 

Rainer M Krug <Rainer@krugs.de> writes:

> Carsten Dominik <carsten.dominik@gmail.com> writes:
>
>> 	
>> Hi everyone,
>>
>> I have just released version 8.2 of Org mode.  This is rather a minor release,
>> mainly designed to do some stabilization and cleanup before the merge
>> into Emacs.  Bastien will do this next week (?).
>
> Just upgraded, to 8.2 and I found a bug:
>
> 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! 
>
> he indirect buffer stays functional and, upon close vie C-c ' saves the
> changes into the original buffer and overwrites changes done in this block.
>
> Can somebody please confirm?
>
> Rainer
<#secure method=pgpmime mode=sign>

-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

Re: BUG?: Org-src - Release 8.2

[Eric Schulte]

One possible reason for a lack of reply is the miss-tagging with "babel"
in the subject line.  This doesn't have anything to do with code block
execution, so I've re-tagged the subject and hopefully someone with
knowledge of this portion of the code will reply.

Cheers,

Rainer M Krug <Rainer@krugs.de> writes:

> Just to reiterate - is this only me or others as well? I consider this
> as a serious problem, as it can result in loss of data.
>
> If it is only me, I have to dig deeper into my config.
>
> Cheers,
>
> Rainer 
>
> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>> 	
>>> Hi everyone,
>>>
>>> I have just released version 8.2 of Org mode.  This is rather a minor release,
>>> mainly designed to do some stabilization and cleanup before the merge
>>> into Emacs.  Bastien will do this next week (?).
>>
>> Just upgraded, to 8.2 and I found a bug:
>>
>> 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! 
>>
>> he indirect buffer stays functional and, upon close vie C-c ' saves the
>> changes into the original buffer and overwrites changes done in this block.
>>
>> Can somebody please confirm?
>>
>> Rainer
> <#secure method=pgpmime mode=sign>
>

-- 
Eric Schulte
https://cs.unm.edu/~eschulte
PGP: 0x614CA05D

Re: BUG?: BABEL - Release 8.2

[Ista Zahn]

I observe the same behavior with org installed from
elpa/org-plus-contrib-20130916.

Best,
Ista

On Sat, Sep 21, 2013 at 9:54 AM, Rainer M Krug <Rainer@krugs.de> wrote:
> Just to reiterate - is this only me or others as well? I consider this
> as a serious problem, as it can result in loss of data.
>
> If it is only me, I have to dig deeper into my config.
>
> Cheers,
>
> Rainer
>
> Rainer M Krug <Rainer@krugs.de> writes:
>
>> Carsten Dominik <carsten.dominik@gmail.com> writes:
>>
>>>
>>> Hi everyone,
>>>
>>> I have just released version 8.2 of Org mode.  This is rather a minor release,
>>> mainly designed to do some stabilization and cleanup before the merge
>>> into Emacs.  Bastien will do this next week (?).
>>
>> Just upgraded, to 8.2 and I found a bug:
>>
>> 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!
>>
>> he indirect buffer stays functional and, upon close vie C-c ' saves the
>> changes into the original buffer and overwrites changes done in this block.
>>
>> Can somebody please confirm?
>>
>> Rainer
> <#secure method=pgpmime mode=sign>
>
> --
> Rainer M. Krug
>
> email: RMKrug<at>gmail<dot>com
>
>

[BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 847 bytes --]

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: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

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 <Rainer@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: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2493 bytes --]

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 <Rainer@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)



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Sebastien Vauban]

Hello Carsten,

Carsten Dominik wrote:
> On 23.9.2013, at 09:40, Rainer M Krug <Rainer-vfylz/Ys1k4@public.gmane.org> 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: [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 2287 bytes --]


On 24.9.2013, at 18:17, Sebastien Vauban <sva-news@mygooglest.com> wrote:

> Hello Carsten,
> 
> Carsten Dominik wrote:
>> On 23.9.2013, at 09:40, Rainer M Krug <Rainer@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
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Sebastien Vauban]

Hi Carsten,

Carsten Dominik wrote:
> On 24.9.2013, at 18:17, Sebastien Vauban <sva-news-D0wtAvR13HarG/iDocfnWg@public.gmane.org> wrote:
>> Carsten Dominik wrote:
>>> On 23.9.2013, at 09:40, Rainer M Krug <Rainer-vfylz/Ys1k4@public.gmane.org> 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

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Carsten Dominik <carsten.dominik@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 <Rainer@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: RMKrug<at>gmail<dot>com

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

"Sebastien Vauban" <sva-news@mygooglest.com>
writes:

> Hi Carsten,
>
> Carsten Dominik wrote:
>> On 24.9.2013, at 18:17, Sebastien Vauban <sva-news@mygooglest.com> wrote:
>>> Carsten Dominik wrote:
>>>> On 23.9.2013, at 09:40, Rainer M Krug <Rainer@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: RMKrug<at>gmail<dot>com

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 3132 bytes --]


On 25.9.2013, at 08:53, Rainer M Krug <Rainer@krugs.de> wrote:

> "Sebastien Vauban" <sva-news@mygooglest.com>
> writes:
> 
>> Hi Carsten,
>> 
>> Carsten Dominik wrote:
>>> On 24.9.2013, at 18:17, Sebastien Vauban <sva-news@mygooglest.com> wrote:
>>>> Carsten Dominik wrote:
>>>>> On 23.9.2013, at 09:40, Rainer M Krug <Rainer@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: RMKrug<at>gmail<dot>com
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Carsten Dominik]

[-- Attachment #1: Type: text/plain, Size: 3607 bytes --]


On 25.9.2013, at 08:48, Rainer M Krug <Rainer@krugs.de> wrote:

> Carsten Dominik <carsten.dominik@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 <Rainer@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
> 
> 


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 455 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 25.9.2013, at 08:48, Rainer M Krug <Rainer@krugs.de> wrote:
>
>> Carsten Dominik <carsten.dominik@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 <Rainer@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

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

[-- Attachment #1: Type: text/plain, Size: 3597 bytes --]

Carsten Dominik <carsten.dominik@gmail.com> writes:

> On 25.9.2013, at 08:53, Rainer M Krug <Rainer@krugs.de> wrote:
>
>> "Sebastien Vauban" <sva-news@mygooglest.com>
>> writes:
>> 
>>> Hi Carsten,
>>> 
>>> Carsten Dominik wrote:
>>>> On 24.9.2013, at 18:17, Sebastien Vauban <sva-news@mygooglest.com> wrote:
>>>>> Carsten Dominik wrote:
>>>>>> On 23.9.2013, at 09:40, Rainer M Krug <Rainer@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: RMKrug<at>gmail<dot>com
>> 
>> 
>


-- 
Rainer M. Krug

email: RMKrug<at>gmail<dot>com

[-- Attachment #2: Type: application/pgp-signature, Size: 486 bytes --]

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Eric Schulte]

>>> 
>>> 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: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Eric Schulte <schulte.eric@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: RMKrug<at>gmail<dot>com

Re: [BUG] in Release 8.2 - editing code in indirect buffer

[Andreas Leha]

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: [BUG] in Release 8.2 - editing code in indirect buffer

[Rainer M Krug]

Andreas Leha <andreas.leha@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: RMKrug<at>gmail<dot>com

Re: Release 8.2

[Mike McLean]

[-- Attachment #1: Type: text/plain, Size: 344 bytes --]


On Sep 19, 2013, at 4:27 PM, Carsten Dominik <carsten.dominik@gmail.com> wrote:

> Microsoft Outlook support has been added to /org-mac-link.el/
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> 
>  Thanks to Marc McLean for this patch.
> 


Probably way to late now, but “Mike McLean” (not Marc)

No worries.



[-- Attachment #2: Type: text/html, Size: 3764 bytes --]