From: Gustavo Barros <email@example.com> To: Tim Cross <firstname.lastname@example.org> Cc: email@example.com Subject: Re: Changed list indentation behavior: how to revert? Date: Mon, 16 Nov 2020 08:21:53 -0300 Message-ID: <firstname.lastname@example.org> (raw) In-Reply-To: <email@example.com> (Tim Cross's message of "Mon, 16 Nov 2020 18:15:30 +1100") Hi Tim, Hi All, On Mon, 16 Nov 2020 at 18:15, Tim Cross <firstname.lastname@example.org> wrote: > Tim Cross <email@example.com> writes: > >> >> Thanks for clarifying this Kyle. >> >> So essentially, this change has been made to make org-mode consistent >> with the rest of emacs which enabled electric-indent by default in Emacs >> 24. this is a good thing. Org should be consistent with other modes. Any >> differences are likely to be the source of confusion and bug reports. >> >> I am a little confused about the purpose of org-adapt-indentation >> though. According to the org news file, to get back the old behaviour, >> it says to explicity disable electric-indent mode using org-mode-hook. >> There is no mention of org-adapt-indentation. >> >> Is this just an artefact from before and in effect, we have two methods >> to disable the indentation behaviour? Is there anything functionally >> different between disabling electric-indent by calling >> electric-indent-local-mode -1 or setting org-adapt-indent to nil or is >> the result functionally equivalent? >> > > Following up to my own question. The two are NOT functionally equivalent > in that org-adapt-indentation supports other values than t or nil. You > can use this variable to tweak how the adaptive indentation works. While > setting it to nil may be equivalent to turning of electric-indent mode, > it can be used to adjust how adaptive indentation works as well. > > Tim > > -- > Tim Cross I think I might chime in again, as perhaps I have a point to add, and Tim's formulation here is a good hook for that. Setting `org-adapt-indentation' to nil is not equivalent to disabling `electric-indent-mode' not because there are more values than t or nil for the first, but because they are conceptually different. `org-adapt-indentation' controls how the indentation should be done by Org, `electric-indent-mode' just applies this setting when you hit RET. If you have `electric-indent-mode' off, but `org-adapt-indentation' set to t, type a heading hit RET, than TAB, you will get the same indentation up to the heading stars level. But the point of interest here, is not this difference by itself, but in some of its implications, and why so many people were unaware of `org-adapt-indentation'. I think this is the case because, with `electric-indent-mode' off, it is easy to slip through the right indentation, and get to believe things are working as expected, when they are actually just doing so by coincidence. Suppose you are in the status quo before 9.4, that is `org-adapt-indentation' set to its default value of true, and `electric-indent-mode' off, and you start to type a little document. If you type it always hitting TAB after RET, you will get: #+begin_src org ,** Foo First line Second line #+end_src (Indentation appears off, but that's just the escape comma). If, instead, you just type RET, you get what many people surprised by the change in this thread expect: #+begin_src org ,** Foo First line Second line #+end_src Now, the point is that, if you just miss the TAB on the first line, even if you hit TAB to indent on the subsequent ones, they will still not indent and be kept on the left margin. So things *appear* to be working as expected, but they are not. What is happening here is that *because indentation is broken in the first line* it goes amiss in the following ones. One might argue that, if it appears to work on all accounts, it is actually working. But if you have this situation, you will then be subject to all sorts of strange things. Suppose we are in the situation of the last block, and demote the heading: #+begin_src org ,*** Foo First line Second line #+end_src Surprise! the content of the heading was moved to the right by one space which is neither indented as it should, nor at the left margin as "expected". Now you try to "fix" this "incorrect" dragging of the content, by selecting the subtree and calling `org-indent-region'. #+begin_src org ,*** Foo First line Second line #+end_src Surprise! it's even "worse". So you then undo twice, and type the star directly to "correct" it (how else?). Try to expand an org-tempo template and get surprised that you can't get a non-indented expansion right after the heading, but you can do it after some content (from a real case at https://emacs.stackexchange.com/q/55413/18951). I haven't tried further, but I wouldn't be surprised if similar "strange" behaviors would also affect killing-yanking subtrees, refiling, etc. So, keeping `org-adapt-indentation' to t, but "solving" the inconvenience by disabling `electric-indent-mode' is not a solution, because this will just hide (keep hiding?) from you the fact that you are editing a document which is different from what Org is actually expecting according to the indentation settings, and this will result in inconsistencies of behavior at a number of points. We should probably thank `electric-indent-mode' for making people more aware of this user option, and correct this setting to their actual use, regardless of whether they choose to use `electric-indent-mode' at Org. Bitter medicine? Perhaps. But it's good. Best regards, Gustavo.
next prev parent reply other threads:[~2020-11-16 11:22 UTC|newest] Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-13 17:30 Karl Voit 2020-11-13 21:10 ` Gustavo Barros 2020-11-13 21:38 ` Jean Louis 2020-11-14 3:02 ` Greg Minshall 2020-11-13 21:47 ` Jean Louis 2020-11-13 22:13 ` Gustavo Barros 2020-11-13 22:21 ` Jean Louis 2020-11-14 17:28 ` Diego Zamboni 2020-11-14 19:10 ` Jean Louis 2020-11-15 12:44 ` Kévin Le Gouguec 2020-11-15 13:26 ` Jean Louis 2020-11-15 21:59 ` Kévin Le Gouguec 2020-11-15 22:15 ` Jean Louis 2020-11-16 7:15 ` Dr. Arne Babenhauserheide 2020-11-16 6:26 ` Greg Minshall 2020-11-14 10:45 ` Diego Zamboni 2020-11-13 21:31 ` Jean Louis 2020-11-14 22:43 ` David Rogers 2020-11-15 5:38 ` Jean Louis 2020-11-15 7:47 ` David Rogers 2020-11-15 8:54 ` Jean Louis 2020-11-15 10:37 ` Greg Minshall 2020-11-15 11:42 ` Tim Cross 2020-11-15 11:48 ` Gustavo Barros 2020-11-15 11:58 ` Detlef Steuer 2020-11-15 12:09 ` Jean Louis 2020-11-15 14:50 ` Gustavo Barros 2020-11-15 15:11 ` Jean Louis 2020-11-15 10:44 ` Dr. Arne Babenhauserheide 2020-11-15 11:22 ` Detlef Steuer 2020-11-15 14:03 ` Kévin Le Gouguec 2020-11-16 5:24 ` Kyle Meyer 2020-11-16 6:41 ` Tim Cross 2020-11-16 7:15 ` Tim Cross 2020-11-16 11:21 ` Gustavo Barros [this message] 2020-11-16 23:24 ` T.F. Torrey 2020-11-17 1:21 ` Tom Gillespie 2020-11-17 7:01 ` Dr. Arne Babenhauserheide 2020-11-17 7:48 ` Michal Politowski 2020-11-19 4:17 ` Marcel Ventosa 2020-11-16 8:06 ` Kévin Le Gouguec 2020-11-16 12:10 ` Bill Burdick 2020-11-16 6:54 ` Greg Minshall 2020-11-16 7:12 ` Tim Cross 2020-11-17 4:03 ` Greg Minshall 2020-11-17 5:25 ` Tim Cross 2020-11-17 13:15 ` Greg Minshall 2020-11-16 7:01 ` Dr. Arne Babenhauserheide 2020-11-16 7:22 ` Tim Cross 2020-11-16 16:04 ` Dr. Arne Babenhauserheide 2020-11-16 16:26 ` Tom Gillespie 2020-11-16 18:12 ` gyro funch 2020-11-16 18:48 ` Tom Gillespie 2020-11-16 19:41 ` Bill Burdick 2020-11-16 19:56 ` Tom Gillespie 2020-11-16 21:50 ` Tim Cross 2020-11-16 23:01 ` Tom Gillespie 2020-11-16 21:44 ` Tim Cross 2020-11-16 18:20 ` gyro funch 2020-11-16 20:56 ` Tim Cross 2020-11-16 21:35 ` Bill Burdick 2020-11-16 22:44 ` Tom Gillespie 2020-11-16 23:55 ` Dr. Arne Babenhauserheide 2020-11-17 9:05 ` Stefan Nobis 2020-11-17 9:15 ` Loris Bennett 2020-11-17 9:32 ` Diego Zamboni 2020-11-17 14:29 ` Dr. Arne Babenhauserheide 2020-11-17 16:25 ` Robert Pluim 2020-11-16 23:39 ` Dr. Arne Babenhauserheide 2020-11-16 21:35 ` Tim Cross 2020-11-17 0:11 ` Dr. Arne Babenhauserheide 2020-11-17 8:45 ` Detlef Steuer 2020-11-17 9:41 ` Jean Louis 2020-11-17 15:33 ` Maxim Nikulin 2020-11-16 13:00 ` Uwe Brauer 2020-11-16 16:10 ` Dr. Arne Babenhauserheide
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style List information: https://orgmode.org * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Org-mode mailing list This inbox may be cloned and mirrored by anyone: git clone --mirror https://orgmode.org/list/0 list/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 list list/ https://orgmode.org/list \ firstname.lastname@example.org public-inbox-index list Example config snippet for mirrors. Newsgroups are available over NNTP: nntp://news.yhetil.org/yhetil.emacs.orgmode nntp://news.gmane.io/gmane.emacs.orgmode AGPL code for this site: git clone https://public-inbox.org/public-inbox.git