[BUG] in last org in indentation of source blocks

[BUG] in last org in indentation of source blocks

[Rainer M Krug]

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

I reralised this morning that there eems to be a bug introduced in one
of the last commits which causes repeted editing of source blocks to
indent more each time the are edited (C-').

Original:
,----
| #+begin_src sh
| echo 2
| #+end_src
`----

After C-' and back again
,----
| #+begin_src sh
|   echo 2
| #+end_src
`----

After second C-' and back
,----
| #+begin_src sh
|     echo 2
| #+end_src
`----

When C-', the indirect buffer has the same indentation as the source
block, but when switching back, two more spaces are added.

Cheers,

Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: [BUG] in last org in indentation of source blocks

[Titus von der Malsburg]

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


On 2015-05-28 Thu 04:49, Rainer M Krug wrote:
> I reralised this morning that there eems to be a bug introduced in one
> of the last commits which causes repeted editing of source blocks to
> indent more each time the are edited (C-').
>
> Original:
> ,----
> | #+begin_src sh
> | echo 2
> | #+end_src
> `----
>
> After C-' and back again
> ,----
> | #+begin_src sh
> |   echo 2
> | #+end_src
> `----
>
> After second C-' and back
> ,----
> | #+begin_src sh
> |     echo 2
> | #+end_src
> `----
>
> When C-', the indirect buffer has the same indentation as the source
> block, but when switching back, two more spaces are added.

I can’t reproduce the second indent but I think it’s a bug that there is
any indentation at all.

The documentation of `org-edit-special' (C-x ') says:

  Call a special editor for the element at point. …

No mention of indentation or other reformatting of my code.

The same goes for `org-edit-src-exit' (C-c C-c) which says:

  Kill current sub-editing buffer and return to source buffer.

The edit-in-buffer feature should not touch the indentation.  If the
syntax of the language is sensitive to indentation (e.g. Python) this
can break the code.  Example:

#+BEGIN_SRC python :results output
  print "test"
#+END_SRC

is invalid Python syntax.

Also having one function perform two very different actions (edit code
in separate buffer *and* reformat the code) is poor design.  At least in
this special case.  When I open the code in a separate buffer but then
decide not to change it (C-c C-c), I'll end up with extra indentation
and this will create unnecessary changes when I commit the file in git.

  Titus


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: [BUG] in last org in indentation of source blocks

[Thomas S. Dye]

Titus von der Malsburg <malsburg@posteo.de> writes:

> I can’t reproduce the second indent but I think it’s a bug that there is
> any indentation at all.
>
> The documentation of `org-edit-special' (C-x ') says:
>
>   Call a special editor for the element at point. …
>
> No mention of indentation or other reformatting of my code.
>
> The same goes for `org-edit-src-exit' (C-c C-c) which says:
>
>   Kill current sub-editing buffer and return to source buffer.
>
> The edit-in-buffer feature should not touch the indentation.  If the
> syntax of the language is sensitive to indentation (e.g. Python) this
> can break the code.  Example:
>
> #+BEGIN_SRC python :results output
>   print "test"
> #+END_SRC
>
> is invalid Python syntax.
>
> Also having one function perform two very different actions (edit code
> in separate buffer *and* reformat the code) is poor design.  At least in
> this special case.  When I open the code in a separate buffer but then
> decide not to change it (C-c C-c), I'll end up with extra indentation
> and this will create unnecessary changes when I commit the file in git.

Does the variable org-src-preserve-indentation get the behavior you're
after?

hth,
Tom
-- 
Thomas S. Dye
http://www.tsdye.com

Re: [BUG] in last org in indentation of source blocks

[Titus von der Malsburg]

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


On 2015-05-28 Thu 11:15, Thomas S. Dye wrote:
> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> I can’t reproduce the second indent but I think it’s a bug that there is
>> any indentation at all.
>>
>> The documentation of `org-edit-special' (C-x ') says:
>>
>>   Call a special editor for the element at point. …
>>
>> No mention of indentation or other reformatting of my code.
>>
>> The same goes for `org-edit-src-exit' (C-c C-c) which says:
>>
>>   Kill current sub-editing buffer and return to source buffer.
>>
>> The edit-in-buffer feature should not touch the indentation.  If the
>> syntax of the language is sensitive to indentation (e.g. Python) this
>> can break the code.  Example:
>>
>> #+BEGIN_SRC python :results output
>>   print "test"
>> #+END_SRC
>>
>> is invalid Python syntax.
>>
>> Also having one function perform two very different actions (edit code
>> in separate buffer *and* reformat the code) is poor design.  At least in
>> this special case.  When I open the code in a separate buffer but then
>> decide not to change it (C-c C-c), I'll end up with extra indentation
>> and this will create unnecessary changes when I commit the file in git.
>
> Does the variable org-src-preserve-indentation get the behavior you're
> after?

It does.  I propose two changes:

1.) The default value `org-src-preserve-indentation' should be t because
that is safer (see Python example) and more conservative.  (Don’t mess
with my code!)

2.) The documentation of `org-edit-special' and `org-edit-src-exit'
should point out that depending on `org-src-preserve-indentation' the
code may be re-indented.

Even better would be to remove `org-src-preserve-indentation' and to do
the right thing, which is to leave the code untouched.  Emacs already
has facilities for indenting code.  No need to reinvent the wheel.

  Titus



[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 472 bytes --]

Re: [BUG] in last org in indentation of source blocks

[Rainer M Krug]

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

tsd@tsdye.com (Thomas S. Dye) writes:

> Titus von der Malsburg <malsburg@posteo.de> writes:
>
>> I can’t reproduce the second indent but I think it’s a bug that there is
>> any indentation at all.
>>
>> The documentation of `org-edit-special' (C-x ') says:
>>
>>   Call a special editor for the element at point. …
>>
>> No mention of indentation or other reformatting of my code.
>>
>> The same goes for `org-edit-src-exit' (C-c C-c) which says:
>>
>>   Kill current sub-editing buffer and return to source buffer.
>>
>> The edit-in-buffer feature should not touch the indentation.  If the
>> syntax of the language is sensitive to indentation (e.g. Python) this
>> can break the code.  Example:
>>
>> #+BEGIN_SRC python :results output
>>   print "test"
>> #+END_SRC
>>
>> is invalid Python syntax.
>>
>> Also having one function perform two very different actions (edit code
>> in separate buffer *and* reformat the code) is poor design.  At least in
>> this special case.  When I open the code in a separate buffer but then
>> decide not to change it (C-c C-c), I'll end up with extra indentation
>> and this will create unnecessary changes when I commit the file in git.
>
> Does the variable org-src-preserve-indentation get the behavior you're
> after?

If I set it to nil, I don't have the runway indentation, if I set it to
non-nil, I have the runaway indentation.

But I can't use nil, as I need the indentation for tangling of some
files.

Rainer

>
> hth,
> Tom

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: [BUG] in last org in indentation of source blocks

[Rainer M Krug]

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

Titus von der Malsburg <malsburg@posteo.de> writes:

> On 2015-05-28 Thu 04:49, Rainer M Krug wrote:
>> I reralised this morning that there eems to be a bug introduced in one
>> of the last commits which causes repeted editing of source blocks to
>> indent more each time the are edited (C-').
>>
>> Original:
>> ,----
>> | #+begin_src sh
>> | echo 2
>> | #+end_src
>> `----
>>
>> After C-' and back again
>> ,----
>> | #+begin_src sh
>> |   echo 2
>> | #+end_src
>> `----
>>
>> After second C-' and back
>> ,----
>> | #+begin_src sh
>> |     echo 2
>> | #+end_src
>> `----
>>
>> When C-', the indirect buffer has the same indentation as the source
>> block, but when switching back, two more spaces are added.
>
> I can’t reproduce the second indent but I think it’s a bug that there is
> any indentation at all.

I just checked again, and the incremental indentation is there if I set
~org-src-preserve-indentation~ to non-nil.

Rainer

>
> The documentation of `org-edit-special' (C-x ') says:
>
>   Call a special editor for the element at point. …
>
> No mention of indentation or other reformatting of my code.
>
> The same goes for `org-edit-src-exit' (C-c C-c) which says:
>
>   Kill current sub-editing buffer and return to source buffer.
>
> The edit-in-buffer feature should not touch the indentation.  If the
> syntax of the language is sensitive to indentation (e.g. Python) this
> can break the code.  Example:
>
> #+BEGIN_SRC python :results output
>   print "test"
> #+END_SRC
>
> is invalid Python syntax.
>
> Also having one function perform two very different actions (edit code
> in separate buffer *and* reformat the code) is poor design.  At least in
> this special case.  When I open the code in a separate buffer but then
> decide not to change it (C-c C-c), I'll end up with extra indentation
> and this will create unnecessary changes when I commit the file in git.
>
>   Titus
>

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: [BUG] in last org in indentation of source blocks

[Nicolas Goaziou]

Hello,

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

> I reralised this morning that there eems to be a bug introduced in one
> of the last commits which causes repeted editing of source blocks to
> indent more each time the are edited (C-').
>
> Original:
> ,----
> | #+begin_src sh
> | echo 2
> | #+end_src
> `----
>
> After C-' and back again
> ,----
> | #+begin_src sh
> |   echo 2
> | #+end_src
> `----
>
> After second C-' and back
> ,----
> | #+begin_src sh
> |     echo 2
> | #+end_src
> `----
>
> When C-', the indirect buffer has the same indentation as the source
> block, but when switching back, two more spaces are added.

This should be fixed in a33acf61917d8c72369297289031d8745e08e320. Thank
you.


Regards,

-- 
Nicolas Goaziou

Re: [BUG] in last org in indentation of source blocks

[Rainer M Krug]

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

Nicolas Goaziou <mail@nicolasgoaziou.fr> writes:

> Hello,
>
> Rainer M Krug <Rainer@krugs.de> writes:
>
>> I reralised this morning that there eems to be a bug introduced in one
>> of the last commits which causes repeted editing of source blocks to
>> indent more each time the are edited (C-').
>>
>> Original:
>> ,----
>> | #+begin_src sh
>> | echo 2
>> | #+end_src
>> `----
>>
>> After C-' and back again
>> ,----
>> | #+begin_src sh
>> |   echo 2
>> | #+end_src
>> `----
>>
>> After second C-' and back
>> ,----
>> | #+begin_src sh
>> |     echo 2
>> | #+end_src
>> `----
>>
>> When C-', the indirect buffer has the same indentation as the source
>> block, but when switching back, two more spaces are added.
>
> This should be fixed in a33acf61917d8c72369297289031d8745e08e320. Thank
> you.

Thanks Nicolas,

Rainer

>
>
> Regards,

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]

Re: [BUG] in last org in indentation of source blocks - confirmed with emacs -Q

[Rainer M Krug]

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

Just confirmed this bug with the following setup:

Just load

--8<---------------cut here---------------start------------->8---
emacs -Q
--8<---------------cut here---------------end--------------->8---

#+begin_src emacs-lisp
  (add-to-list 'load-path "~/.emacs.d/org-mode/lisp")
  (add-to-list 'load-path "~/.emacs.d/org-mode/contrib/lisp")
  (require 'org)
  (setq org-src-preserve-indentation nil)
#+end_src

Proper indentation of any source block

#+begin_src emacs-lisp
  (setq org-src-preserve-indentation t)
#+end_src

runaway indentation

#+begin_src emacs-lisp
  (setq org-src-preserve-indentation t)
#+end_src

,----
| 
| Org-mode version 8.3beta (release_8.3beta-1178-g317886 @ /Users/rainerkrug/.emacs.d/org-mode/lisp/)
| GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, Carbon Version 157 AppKit 1347.57) of 2015-04-13 on Rainers-MacBook-Pro.local
`----

Cheers,

Rainer




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

> I reralised this morning that there eems to be a bug introduced in one
> of the last commits which causes repeted editing of source blocks to
> indent more each time the are edited (C-').
>
> Original:
> ,----
> | #+begin_src sh
> | echo 2
> | #+end_src
> `----
>
> After C-' and back again
> ,----
> | #+begin_src sh
> |   echo 2
> | #+end_src
> `----
>
> After second C-' and back
> ,----
> | #+begin_src sh
> |     echo 2
> | #+end_src
> `----
>
> When C-', the indirect buffer has the same indentation as the source
> block, but when switching back, two more spaces are added.
>
> Cheers,
>
> Rainer

-- 
Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany)

Centre of Excellence for Invasion Biology
Stellenbosch University
South Africa

Tel :       +33 - (0)9 53 10 27 44
Cell:       +33 - (0)6 85 62 59 98
Fax :       +33 - (0)9 58 10 27 44

Fax (D):    +49 - (0)3 21 21 25 22 44

email:      Rainer@krugs.de

Skype:      RMkrug

PGP: 0x0F52F982

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 494 bytes --]