[BUG] defaults make it hard to edit Elisp blocks in org buffers

[BUG] defaults make it hard to edit Elisp blocks in org buffers

[gerard.vermeulen]

* Why I do (setopt org-src-preserve-indention t)

Sometimes, I want to do small Elisp edits without calling
org-edit-source-code.  Below, I describe a long standing bug
(several years) that is also present in main.
I use smartparens, but it reproduces also in a clean
environment (minimal init.el) using main.

#+begin_src emacs-lisp :results silent
(setopt org-edit-src-content-indentation 4 ;; to amplify the effect
         org-src-preserve-indentation nil)
#+end_src
Place point after the first open parenthesis below and type return.
#+begin_src emacs-lisp
     (())
#+end_src
This moves the code 4 spaces to the right.  Place point after the first
open parenthesis of the lowest line below and type return.
#+begin_src emacs-lisp
             (
              (
               ))
#+end_src
This moves the code again 4 spaces to the right. It does not matter
whether the the parentheses contain for instance a function definition.

* Therefore, I work with those settings breaking the default.
#+begin_src emacs-lisp :results silent
(setopt org-edit-src-content-indentation 2
         org-src-preserve-indentation t)
#+end_src
Place point after the first open parenthesis below and type return.
#+begin_src emacs-lisp
(())
#+end_src
The parentheses remain left-shifted.  Place point after the first
open parenthis of the lowest line below and type return.
#+begin_src emacs-lisp
(
  ())
#+end_src
Again, the parentheses remain left-shifted.
#+begin_src emacs-lisp
(
  (
   ))
#+end_src
The parentheses remain left-shifted.  I prefer this over the default.

I have only seen it with Elisp blocks.

Regards -- Gerard

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Sébastien Miquel]

Hi,

The issue is that when you press return, you insert a newline, with no
indentation, then call =org-indent-line= which edits the block in a
native buffer. This is supposed to remove any common indentation, but
there is now none. Then it reinserts the code in the org-buffer,
adding a new common indentation to the block.

If I recall correctly, in order to fix this, in =org-indent-line=,
before calling =TAB= in the native buffer, one should check the
current line indentation and if it is less than =block-content-ind=,
start by adding this much indentation to the current line.

This could be a bit fragile, and in particular it assumes that the
rest of the block has this =block-content-ind=, which might not be the
case. One could possibly at least check that the first line of the
block does have this much indentation. If it doesn't, just do
whatever.

--
Sébastien Miquel

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Ihor Radchenko]

Sébastien Miquel <sebastien.miquel@posteo.eu> writes:

> The issue is that when you press return, you insert a newline, with no
> indentation, then call =org-indent-line= which edits the block in a
> native buffer. This is supposed to remove any common indentation, but
> there is now none. Then it reinserts the code in the org-buffer,
> adding a new common indentation to the block.

Exactly.
Confirmed.

> If I recall correctly, in order to fix this, in =org-indent-line=,
> before calling =TAB= in the native buffer, one should check the
> current line indentation and if it is less than =block-content-ind=,
> start by adding this much indentation to the current line.
>
> This could be a bit fragile, and in particular it assumes that the
> rest of the block has this =block-content-ind=, which might not be the
> case. One could possibly at least check that the first line of the
> block does have this much indentation. If it doesn't, just do
> whatever.

What about a simpler approach - indent the line at point to block's
expected indentation (if it is not yet there) and then rely upon the
code block's major mode to do the right thing?

Even when we are in a situation when the user did not just press C-j or
<RET>, things should still work with the described approach.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Sébastien Miquel]

Ihor Radchenko writes:
>> If I recall correctly, in order to fix this, in =org-indent-line=,
>> before calling =TAB= in the native buffer, one should check the
>> current line indentation and if it is less than =block-content-ind=,
>> start by adding this much indentation to the current line.
>>
>> This could be a bit fragile, and in particular it assumes that the
>> rest of the block has this =block-content-ind=, which might not be the
>> case. One could possibly at least check that the first line of the
>> block does have this much indentation. If it doesn't, just do
>> whatever.
> What about a simpler approach - indent the line at point to block's
> expected indentation (if it is not yet there) and then rely upon the
> code block's major mode to do the right thing?

I cannot think of any common use where the two approches differ, and
it is indeed simpler. The possibility that the block does not have the
common indentation still stands.

-- 
Sébastien Miquel

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[gerard.vermeulen]

On 18.01.2024 17:45, Sébastien Miquel wrote:
> Ihor Radchenko writes:
>>> If I recall correctly, in order to fix this, in =org-indent-line=,
>>> before calling =TAB= in the native buffer, one should check the
>>> current line indentation and if it is less than =block-content-ind=,
>>> start by adding this much indentation to the current line.
>>> 
>>> This could be a bit fragile, and in particular it assumes that the
>>> rest of the block has this =block-content-ind=, which might not be 
>>> the
>>> case. One could possibly at least check that the first line of the
>>> block does have this much indentation. If it doesn't, just do
>>> whatever.
>> What about a simpler approach - indent the line at point to block's
>> expected indentation (if it is not yet there) and then rely upon the
>> code block's major mode to do the right thing?
> 
> I cannot think of any common use where the two approches differ, and
> it is indeed simpler. The possibility that the block does not have the
> common indentation still stands.

As far as I understand, the effect also occurs when the block has a
common indentation. Below are the steps:

With this settings:
#+begin_src emacs-lisp -i :results silent
(setopt org-adapt-indentation nil
         org-src-preserve-indentation nil
         org-edit-src-content-indentation 2)
#+end_src
And with POINT after "?" and typing ENTER (wait more than 1 second
for automatic indenting of 2 spaces), I can type parentheses with
some sort of common indentation like below:
#+begin_src emacs-lisp
   ;; common indentation?
   (())
   (())
   (())
#+end_src
When I place POINT in the middle of the lowest parentheses and
type ENTER, then everything moves 2 spaces to the right like below:
#+begin_src emacs-lisp
     ;; common indentation?
     (())
     (())
     ((
       ))
#+end_src
I think, this is different of what you are saying.

Looking at the code, I inferred that I can kill this behavior
with the `-i' switch, and that works.

Regards -- Gerard

Re: [BUG] defaults make it hard to edit Elisp blocks in org buffers

[Ihor Radchenko]

gerard.vermeulen@posteo.net writes:

>> I cannot think of any common use where the two approches differ, and
>> it is indeed simpler. The possibility that the block does not have the
>> common indentation still stands.
>
> As far as I understand, the effect also occurs when the block has a
> common indentation. Below are the steps:
> ...
> And with POINT after "?" and typing ENTER (wait more than 1 second
> for automatic indenting of 2 spaces), I can type parentheses with
> some sort of common indentation like below:
> #+begin_src emacs-lisp
>    ;; common indentation?
>    (())
>    (())
>    (())
> #+end_src
> When I place POINT in the middle of the lowest parentheses and
> type ENTER, then everything moves 2 spaces to the right like below:

This is expected, because we already have a special case for creating an
empty line - it does not contribute to common indentation we calculate.

But the special case for empty line does not cover your original
reproducer.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>