Changed list indentation behavior: how to revert?

Changed list indentation behavior: how to revert?

[Karl Voit]

Hi!

I'm on Org mode maint git repo, currently v9.3.6.

I recently upgraded from an older git commit version.

Since the upgrade I do have a different behavior:

- Consider this list itemX
A 1
2

When I press RET at the "X" above, I end up at position "1". With
another RET, cursor ends up at "2". I'd love to get back the
previous behavior where RET at "X" always ended up at "A".

Unfortunately, there are tons of org*indent* variables out there.
I'd appreciate it very much if somebody knows what variable I need
to modify to get back to the previous behavior.

Thanks!


If somebody is interested why I do find the old one much better:
When I need one multi-line list item, I just keep on typing while
auto-wrap is active or I press M-q to re-format the item
accordingly. For a new list item, I'm using M-RET which solves the
indentation correctly.

When I press RET after the last list item to continue with a
non-list item, I prefer the old behavior which does not add the
extra spaces.

-- 
get mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML into Org-mode:
       > get Memacs from https://github.com/novoid/Memacs <
Personal Information Management > http://Karl-Voit.at/tags/pim/
Emacs-related > http://Karl-Voit.at/tags/emacs/

Re: Changed list indentation behavior: how to revert?

[Gustavo Barros]

Hi Karl,

On Fri, 13 Nov 2020 at 18:30, Karl Voit <devnull@Karl-Voit.at> wrote:

> Hi!
>
> I'm on Org mode maint git repo, currently v9.3.6.
>
> I recently upgraded from an older git commit version.
>
> Since the upgrade I do have a different behavior:
>
> - Consider this list itemX
> A 1
> 2
>
> When I press RET at the "X" above, I end up at position "1". With
> another RET, cursor ends up at "2". I'd love to get back the
> previous behavior where RET at "X" always ended up at "A".
>
> Unfortunately, there are tons of org*indent* variables out there.
> I'd appreciate it very much if somebody knows what variable I need
> to modify to get back to the previous behavior.
>
> Thanks!

I'll answer, because I feel somewhat responsible for your upgrade. ;-)

Since recently Org is set to respect Emacs' `eletric-indent-mode'.  If
I'm not mistaken, it made to the 9.4 release, I presume that's what you
are getting.

You can find the Org News entry, and how to get the previous behavior
back in:
https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323

A couple of threads that might help understand the change and the
reasoning behind it:
https://orgmode.org/list/877dxpazbo.fsf_-_@gmail.com/
https://orgmode.org/list/878sfbycip.fsf@iki.fi/

HTH,
Gustavo.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-14 00:12]:
> I'll answer, because I feel somewhat responsible for your upgrade. ;-)
> 
> Since recently Org is set to respect Emacs' `eletric-indent-mode'.  If
> I'm not mistaken, it made to the 9.4 release, I presume that's what you
> are getting.
> 
> You can find the Org News entry, and how to get the previous behavior
> back in:
> https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323
> 
> A couple of threads that might help understand the change and the
> reasoning behind it:
> https://orgmode.org/list/877dxpazbo.fsf_-_@gmail.com/
> https://orgmode.org/list/878sfbycip.fsf@iki.fi/

Then I find it wrong for the following reason:

- when I am typing:

** New
   
   ^ cursor appears here and that is wrong.

*** More
    
    ^ cursor appears here

So that is wrong because I have started writing the line at position 0
and you are counting it after stars.

If somebody however writes like this:

    ** New

Then it would be alright to indent as:


    ** New

    - here list
    - more here

but it is not alright to do this:

** New

   - new 
   - new

As that does not align with that what electric-indent really does.

I hope you will revert back that change as it is very
disturbing. Thank you.

Jean

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

so, i also agree that the new('ish) behavior is somewhat surprising.

[i once changed the behavior of the "Enter" key in Berkeley Unix, and
suffered the (well-deserved, in that case) arrows that soon entered my
back.]

from that perspective, i wonder if maybe there's an interpretation of
elastic-indent mode that is more in line with what at least some of us
expect?

cheers, Greg

[ps -- in the BSD case above, i was tied to a very particular reading of
a section of the early Telnet RFC (sadly, i've always tended to
dogmatism).  there had been plenty of discussion, albeit within a small
group of BSD developers, and, with reservations, agreement had been
reached to make the change.  after releasing that version of BSD Unix,
users started reacting, and Mike Karels worked me into seeing an
alternative interpretation, we made the fix, patches were released, and
all, other than my somewhat bruised ego, were soon well.]

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-14 00:12]:
> I'll answer, because I feel somewhat responsible for your upgrade. ;-)
> 
> Since recently Org is set to respect Emacs' `eletric-indent-mode'.  If
> I'm not mistaken, it made to the 9.4 release, I presume that's what you
> are getting.
> 
> You can find the Org News entry, and how to get the previous behavior
> back in:
> https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323
> 
> A couple of threads that might help understand the change and the
> reasoning behind it:
> https://orgmode.org/list/877dxpazbo.fsf_-_@gmail.com/
> https://orgmode.org/list/878sfbycip.fsf@iki.fi/

I have seen discussion with very little reasoning. You are changing
default for many users and large subset of those users will not read
the NEWS. And now you are discovering that there are people who get
messed up with it. Is it really useful? So far I remember the
electric-indent-mode did work in Org mode without this anti-enhancement.

If user starts typing line like:

  Right here

Then user has decided that line begins at the letter R(ight).

And you are deciding for users that their line begin at letter (h)ere.

I did not see any reasoning why should programmer change the default
behavior of electric-indent into something untested by more than just
few people.

If such function is wanted by subset of users then make it optional
for those.

Introducing default that changes habits and gives more work to present
users is not useful.

Did you consider number of users who would now maybe need to introduce
local variable just to turn that off? Sorry that I do not find this
case reasonable.

Re: Changed list indentation behavior: how to revert?

[Gustavo Barros]

On Fri, 13 Nov 2020 at 18:47, Jean Louis <bugs@gnu.support> wrote:

> * Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-14 00:12]:
>
> I have seen discussion with very little reasoning. You are changing
> default for many users and large subset of those users will not read
> the NEWS. And now you are discovering that there are people who get
> messed up with it. Is it really useful? So far I remember the
> electric-indent-mode did work in Org mode without this 
> anti-enhancement.
>
[...]
>
> Introducing default that changes habits and gives more work to present
> users is not useful.
>
> Did you consider number of users who would now maybe need to introduce
> local variable just to turn that off? Sorry that I do not find this
> case reasonable.

Oh, my!  I'm not even the person you should be ranting to.  I'm just an 
user, and someone who follows this list, and was trying to be helpful.

But, as such, I do get what motivated maintainers to make the change 
from the linked threads.  And I also got from them and the News the 
information needed to adjust for the change, in case I'd want to. 
Perhaps we read differently.

Best regards,
Gustavo.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-14 01:14]:
> 
> On Fri, 13 Nov 2020 at 18:47, Jean Louis <bugs@gnu.support> wrote:
> 
> > * Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-14 00:12]:
> > 
> > I have seen discussion with very little reasoning. You are changing
> > default for many users and large subset of those users will not read
> > the NEWS. And now you are discovering that there are people who get
> > messed up with it. Is it really useful? So far I remember the
> > electric-indent-mode did work in Org mode without this anti-enhancement.
> > 
> [...]
> > 
> > Introducing default that changes habits and gives more work to present
> > users is not useful.
> > 
> > Did you consider number of users who would now maybe need to introduce
> > local variable just to turn that off? Sorry that I do not find this
> > case reasonable.
> 
> Oh, my!  I'm not even the person you should be ranting to.  I'm just an
> user, and someone who follows this list, and was trying to be helpful.
> 
> But, as such, I do get what motivated maintainers to make the change from
> the linked threads.  And I also got from them and the News the information
> needed to adjust for the change, in case I'd want to. Perhaps we read
> differently.

Sorry. I was wondering for quite some time what is happening as I use
development Emacs version. It was so annoying. Now when I know what is
going on I can turn it off.

So far I was thinking that most common Org writing is like this:

* Heading
** Second
*** Third
**** Fourth

And not like:

* Heading
  ** Second
     *** Third
         **** Fourth

As that is how ugly and less visible it should look like if the same
principle should be followed. As if somebody forces me to indent list
items like that, then they shall also force headings. So consistency
is lacking. /s

Please send that to those people to reconsider taking it back.

Re: Changed list indentation behavior: how to revert?

[Diego Zamboni]

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

Jean,

On Sat, Nov 14, 2020 at 8:53 AM Jean Louis <bugs@gnu.support> wrote:

> As that is how ugly and less visible it should look like if the same
> principle should be followed. As if somebody forces me to indent list
> items like that, then they shall also force headings. So consistency
> is lacking. /s
>

No one is forcing you to do anything, particularly given that there are
ways to disable it.

If it had bothered you so much, why had you not looked into it, or asked
about it?

Please send that to those people to reconsider taking it back.
>

I'm not sure to whom you are referring. I guess "those people" would be the
developers and maintainers and other users who do a lot of work *for free*
so that we can all use the tools we love. And furthermore, to whom you can
talk directly through this mailing list.

Best,
--Diego

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

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Diego Zamboni <diego@zzamboni.org> [2020-11-14 20:29]:
> Jean,
> 
> On Sat, Nov 14, 2020 at 8:53 AM Jean Louis <bugs@gnu.support> wrote:
> 
> > As that is how ugly and less visible it should look like if the same
> > principle should be followed. As if somebody forces me to indent list
> > items like that, then they shall also force headings. So consistency
> > is lacking. /s
> >
> 
> No one is forcing you to do anything, particularly given that there are
> ways to disable it.

Well, I did not know what is causing it that I would need to report or
find out. I was thinking it is some of packages. You are right I may
disable it. My thought here is rather for usefulness for others.

I have presented reasoning as if one wish to indent something as
convenience then indentation should be customary, something that people are used to.

* First headingRET
  - something hereRET
    - something hereRET
      (at this line becomes hard or unknown where to go back with indentation)
      ** Maybe like this?
  ** Maybe like this?RET If I press RET there, then it does not work
  It brings me here. So it is not logical
** Maybe here?
   Then
   Something

Indentation in fundamental mode:

** HereRET
I come here.
But only if I start indenting
   Like hereRET
   Then I continue here

In general before deciding to introduce a new feature or
something considered feature or convenience for many users,
something that changes habits of many users than at least there
shall be discussion with users to find out what is useful or not,
or at least some feeling if it is.

Introducing something just for case to accommodate
electric-indent-mode where it changes habits of many does not
sound to me as convenience.

In general, I always agree to final decision of developers and I
am as one least problem there. Whatever they wish and want.

Re: Changed list indentation behavior: how to revert?

[Kévin Le Gouguec]

Jean Louis <bugs@gnu.support> writes:

> Indentation in fundamental mode:
>
> ** HereRET
> I come here.
> But only if I start indenting
>    Like hereRET
>    Then I continue here

Hi Jean,

My understanding of electric-indent-mode is that it tries to make "RET"
equivalent to "insert newline; indent according to major mode rules".
E.g. in c-mode, when point is after the brace:

if (condition) {

RET will move point to column 2, while C-j will just insert a newline
and stay at column 0.

Likewise in python-mode, when point is after the colon:

def foobar():

RET will insert a newline and move point to column 4; C-j will stay at
column 0.

Your counter-example in fundamental-mode only shows that there are no
"smart indentation" rules in this mode; hitting TAB more than once keeps
on inserting horizontal space unconditionally instead of snapping to the
"correct" indentation level.


I've used Emacs's programming language modes for years before finally
trying out Org, where I noticed that the keys were swapped: RET was the
"plain dumb newline" key, and C-j was the "smart newline-then-indent"
key.  IIUC this was how the rest of Emacs behaved before
electric-indent-mode became enabled by default.

I personally found the difference infuriating.  Everywhere else in
Emacs,
- C-m and <Return> do smart indentation,
- C-j ≡ ^J ≡ (insert "\N{LINE FEED (LF)}")

The changes in Org 9.4 aimed to make Org consistent with this "new"
convention, so that hitting RET immediately indents paragraphs below a
heading (as if the user hit TAB right after inserting a newline), and a
user wishing to "just insert some vertical space" can just whale on C-j.


FWIW, what I wonder about is /why/ Org hard-indents section bodies by
default (org-indent-mode, which I use, soft-indents instead using
overlays).

IIUC this can be toggled off by setting org-adapt-indentation to nil;
FWIW this is what the .dir-locals.el file at the root of Org's
repository does…


I haven't read this whole thread thoroughly; I've had trouble staying on
top of Emacs's mailing lists this week.

Apologies if I've missed something, and thanks for your patience.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Kévin Le Gouguec <kevin.legouguec@gmail.com> [2020-11-15 15:45]:
:PROPERTIES:
:CREATED:  [2020-11-15 Sun 16:26]
:ID:       e454756a-3123-42dc-8c44-8682f12927ad
:END:
> Jean Louis <bugs@gnu.support> writes:
> 
> > Indentation in fundamental mode:
> >
> > ** HereRET
> > I come here.
> > But only if I start indenting
> >    Like hereRET
> >    Then I continue here
> 
> Hi Jean,
> 
> My understanding of electric-indent-mode is that it tries to make "RET"
> equivalent to "insert newline; indent according to major mode rules".
> E.g. in c-mode, when point is after the brace:
> 
> if (condition) {
> 
> RET will move point to column 2, while C-j will just insert a newline
> and stay at column 0.

> Likewise in python-mode, when point is after the colon:
> 
> def foobar():
> 
> RET will insert a newline and move point to column 4; C-j will stay at
> column 0.
> 
> Your counter-example in fundamental-mode only shows that there are no
> "smart indentation" rules in this mode; hitting TAB more than once keeps
> on inserting horizontal space unconditionally instead of snapping to the
> "correct" indentation level.

I know it behaves different in different modes.

And there is also to consider (which I did not test in many modes)
that in majority of modes not being programming language user may move
either with TAB or SPC to any column and RET will be aligned to begin
of that previous line.

      anywhere
      this lines alignes with the first one

Which is generally good think.

There is just slight difference, and that is what I learned from
introduction to Org mode that it is "plain text" kind of mode. I can
do and write how I wish. My habit comes from being used to indent when
I want and then to follow indentation in that specific paragraph. That
is really great.

But I was not used to have it indented by programmer like the
introduction of this new default feature, which I consider is not
useful to be default.

> I've used Emacs's programming language modes for years before finally
> trying out Org, where I noticed that the keys were swapped: RET was the
> "plain dumb newline" key, and C-j was the "smart newline-then-indent"
> key.  IIUC this was how the rest of Emacs behaved before
> electric-indent-mode became enabled by default.
> 
> I personally found the difference infuriating.  Everywhere else in
> Emacs,
> - C-m and <Return> do smart indentation,
> - C-j ≡ ^J ≡ (insert "\N{LINE FEED (LF)}")

I understand it for you, you got also surprised as you were used to it.

> The changes in Org 9.4 aimed to make Org consistent with this "new"
> convention, so that hitting RET immediately indents paragraphs below a
> heading (as if the user hit TAB right after inserting a newline), and a
> user wishing to "just insert some vertical space" can just whale on
> C-j.

Somehow I protest against it as it is not what I learned from roots of
Org writing, so introducing it as default is breaking habits and
consistency.

Observe this official presentation and you will see how current
indentation is not consistent to what is shown:
https://orgmode.org/resources/img/features/folding.gif

Look at this official presentation and you will see that even headings
are indented for which we say it should not be so:
https://orgmode.org/resources/img/features/clocking.svg

The official presentation here:
https://orgmode.org/

does not show any indentation at all.

And in Info file I find nothing of it.

All I say, when default is introduced, should be well documented how
and why. Before it is introduced it is better to discuss wider with
people.

Few of people reading these exchanges may find how to turn it off,
majority will not find it.

> FWIW, what I wonder about is /why/ Org hard-indents section bodies by
> default (org-indent-mode, which I use, soft-indents instead using
> overlays).
> 
> IIUC this can be toggled off by setting org-adapt-indentation to nil;
> FWIW this is what the .dir-locals.el file at the root of Org's
> repository doe

With 2000+ directories containing Org file of persons, held on this
system that would mean turning it on 2000+ times. Because in general I
do not use that type of indentation I have just set it in main
~/.emacs.d/init.el file.

We concluded that configuring is easy and that is great.

What is not concluded is that the default impacts too many people who
may not find out how to configure it back and that designing user
interface shall be made with more care.

Re: Changed list indentation behavior: how to revert?

[Kévin Le Gouguec]

Jean Louis <bugs@gnu.support> writes:

> There is just slight difference, and that is what I learned from
> introduction to Org mode that it is "plain text" kind of mode. I can
> do and write how I wish. My habit comes from being used to indent when
> I want and then to follow indentation in that specific paragraph. That
> is really great.
>
> But I was not used to have it indented by programmer like the
> introduction of this new default feature, which I consider is not
> useful to be default.

Note that even before this change, Org's indentation already behaved
like a "programming mode".  TAB does not allow you to move to "any
column":

- either org-adapt-indentation is t (the default) and TAB moves your
  paragraph to column LEVEL+1,
- or it is nil, and TAB is a no-op.

> Observe this official presentation and you will see how current
> indentation is not consistent to what is shown:
> https://orgmode.org/resources/img/features/folding.gif
>
> Look at this official presentation and you will see that even headings
> are indented for which we say it should not be so:
> https://orgmode.org/resources/img/features/clocking.svg

Yep, AFAICT this has been produced with org-indent-mode, which
soft-indents using overlays.

> The official presentation here:
> https://orgmode.org/
>
> does not show any indentation at all.
>
> And in Info file I find nothing of it.

Yep; what this (along with the way org-adapt-indentation is unset in
Org's own repo) suggests to me is that Org, by default, should not
indent section bodies.

This means *not only* that RET should not indent, but that /TAB/ should
not rigidly indent to column LEVEL+1 (I don't have a strong opinion
about whether it should rigidly indent to column 0, or if it should
behave as in text-mode).

So AFAIU the issue lies not with RET becoming consistent with the rest
of Emacs and doing "insert newline then indent smartly"; rather it lies
with how Org defines "smartly".  From what I gather from this thread,
lots of folks would like Org to keep section bodies at column 0.

> All I say, when default is introduced, should be well documented how
> and why. Before it is introduced it is better to discuss wider with
> people.
>
> Few of people reading these exchanges may find how to turn it off,
> majority will not find it.

Before being applied, this change has been discussed on emacs-devel and
emacs-orgmode; it has then been documented in ORG-NEWS.  Which other
places do you think we should have reached out to?

>> IIUC this can be toggled off by setting org-adapt-indentation to nil;
>> FWIW this is what the .dir-locals.el file at the root of Org's
>> repository doe
>
> With 2000+ directories containing Org file of persons, held on this
> system that would mean turning it on 2000+ times. Because in general I
> do not use that type of indentation I have just set it in main
> ~/.emacs.d/init.el file.
>
> We concluded that configuring is easy and that is great.
>
> What is not concluded is that the default impacts too many people who
> may not find out how to configure it back and that designing user
> interface shall be made with more care.

I admit to not having put as much thought in a "migration plan" as I
could have.  My reasoning was that since Org indents text by default
(/when/ hitting TAB or using the "smart newline" command), users were
probably fine with it.

IIUC I failed to understand that:

- Plenty of Org users do not expect it to behave like programming modes
  wrt indentation (they might not even use programming modes).

    - These users were using RET as a "dumb newline" command, unaware
      that by default, Org considers that text should be indented.

- org-adapt-indentation…

    - exists (really, I just found out about it today, after wondering
      why on Earth Org does not indent text in doc/org-guide.org, and
      tracing it to the repository's directory-local variables).

    - has a default value that does not reflect how Org text is indented
      in official examples, nor in Org's own repository.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Kévin Le Gouguec <kevin.legouguec@gmail.com> [2020-11-16 01:00]:
:PROPERTIES:
:CREATED:  [2020-11-16 Mon 01:15]
:ID:       bd11f325-c034-4f9b-baa6-b7d606af3cbb
:END:
> - Plenty of Org users do not expect it to behave like programming modes
>   wrt indentation (they might not even use programming modes).
> 
>     - These users were using RET as a "dumb newline" command, unaware
>       that by default, Org considers that text should be indented.

You have all nice good points, thank you.

My confusion comes from the below advertised liberties:

- Org Mode 

- Your life in plain text

- A GNU Emacs major mode for convenient plain text markup — and much more.

And so all the time I have expected Org to be very liberal. I could
write it in any mode, any editor, and I could still use it back in
Emacs.

Special stuff as I understood it since beginning is just header,
properties or tags and tables and special blocks. Everything else
should be liberal. Using RET as newline, yes. This is only how I was
hooked onto Org.

Side notes:

Personally I would like Org to be either rigid or not rigid and
liberal. It is either one of those. Indentation by default is
nowhere. Neither rigid or not rigid as it is not mature feature.

It is hard to express me. I have given examples when indentation is
not following with itself. But if all other functions are following
nicely with indentation AND bunch of users seek that, why not.

When copying subtrees into different headings, identation is not
always following nicely. When demoting upmoting headings, is not
following nicely.

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:
> Before being applied, this change has been discussed on emacs-devel and
> emacs-orgmode; it has then been documented in ORG-NEWS.  Which other
> places do you think we should have reached out to?

I don’t think you really had a chance to reach enough people. I’m here
on the list now because I got a note about the call for help from a
colleague at work. Before that I was simply happy that most things
worked, wrote the occassional M-x org-submit-bug-report (actually with
Ido: M-x org-bug) and dug through emacswiki or the web when something
didn’t work. When missing names for some annoyance, I couldn’t do much
about it, because I couldn’t search for it.

Changes like these which affect existing behavior are just really hard
to do in a way that doesn’t create problems.

There’s a deep challenge hidden beneath this which Steve Losh wrote
masterfully about:
https://stevelosh.com/blog/2012/04/volatile-software/

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

i wanted first to thank everyone for their participation in this
discussion.  i want to not be annoying.  and, yes, this is a long
thread, and for me, at least, it's hard to keep track of what was said.

(like many, i assumed this was some bug, triggered by my configuration
TIMES emacs release TIMES org release, and that it would eventually
clear up or i'd eventually track down whatever in my .emacs that was
causing it.)

Kévin Le Gouguec said

> My understanding of electric-indent-mode is that it tries to make
> "RET" equivalent to "insert newline; indent according to major mode
> rules".

and i wonder if this might be a big part of the "problem": exactly what
*are* the major mode rules when org-mode is the major mode?  my sense is
that for some of us, column 1 (modulo lists) rules; for others, column
(n*asterisks+1) is the rule.

both seem reasonable choices.  afaict, either, if adopted as "the" major
mode rule for org-mode, could be said to be playing to the tune of
emacs' electric indent.


then, more mundanely, i'll note that setting 'org-adapt-indentation' to
nil doesn't seem to take at least me back to (my column-1 version of)
nirvana.  if i type (ignore square brackets):
----
[- this<RET>is<RET>a<RET>test]
----

i end up with:
----
- this
  is
  a
  test
----

rather than
----
- this
is
a
test
----
which i think was the previous behavior.  (in the previous, iirc, M-q
and/or word-wrapping would wrap w.r.t. the indentation of the current
(sub-)list item.)

cheers, Greg

ps -- Gustavo, again, thanks.

> You (plural) could probably also get some juice from looking into, and
> incorporating to muscle memory, `M-RET', `C-RET' and `C-j'.

i tried that with the BSD users.  there, it didn't sell.  (almost) forty
years, and a couple of thousand users, later, maybe it will take!  (but,
obviously, i sort of hope not, now that i'm vaguely on the other side of
the table. :) best.

Re: Changed list indentation behavior: how to revert?

[Diego Zamboni]

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

Hi Gustavo,

Thanks for the pointer! I noticed this change some time ago, but it hadn't
bothered me so much as to go look how to fix it - now you gave me the
solution :)

Cheers,
--Diego


On Fri, Nov 13, 2020 at 10:11 PM Gustavo Barros <gusbrs.2016@gmail.com>
wrote:

> Hi Karl,
>
> On Fri, 13 Nov 2020 at 18:30, Karl Voit <devnull@Karl-Voit.at> wrote:
>
> > Hi!
> >
> > I'm on Org mode maint git repo, currently v9.3.6.
> >
> > I recently upgraded from an older git commit version.
> >
> > Since the upgrade I do have a different behavior:
> >
> > - Consider this list itemX
> > A 1
> > 2
> >
> > When I press RET at the "X" above, I end up at position "1". With
> > another RET, cursor ends up at "2". I'd love to get back the
> > previous behavior where RET at "X" always ended up at "A".
> >
> > Unfortunately, there are tons of org*indent* variables out there.
> > I'd appreciate it very much if somebody knows what variable I need
> > to modify to get back to the previous behavior.
> >
> > Thanks!
>
> I'll answer, because I feel somewhat responsible for your upgrade. ;-)
>
> Since recently Org is set to respect Emacs' `eletric-indent-mode'.  If
> I'm not mistaken, it made to the 9.4 release, I presume that's what you
> are getting.
>
> You can find the Org News entry, and how to get the previous behavior
> back in:
> https://code.orgmode.org/bzg/org-mode/src/master/etc/ORG-NEWS#L323
>
> A couple of threads that might help understand the change and the
> reasoning behind it:
> https://orgmode.org/list/877dxpazbo.fsf_-_@gmail.com/
> https://orgmode.org/list/878sfbycip.fsf@iki.fi/
>
> HTH,
> Gustavo.
>
>

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

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Karl Voit <devnull@Karl-Voit.at> [2020-11-13 20:40]:
> If somebody is interested why I do find the old one much better:
> When I need one multi-line list item, I just keep on typing while
> auto-wrap is active or I press M-q to re-format the item
> accordingly. For a new list item, I'm using M-RET which solves the
> indentation correctly.
> 
> When I press RET after the last list item to continue with a
> non-list item, I prefer the old behavior which does not add the
> extra spaces.

Myself I was badly surprised with that change. I am glad to read here
to get pointers how to revert it.

Re: Changed list indentation behavior: how to revert?

[David Rogers]

Hello

After reading several of the responses to this, I’ve started to 
wonder: Is electric-indent-mode broken for everybody because it 
contains a bug or design flaw, or is electric-indent-mode working 
fine but simply not suitable for every situation?

In other words, where is the “right” place to fix this problem?

-- 
David Rogers

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* David Rogers <davidandrewrogers@gmail.com> [2020-11-15 01:44]:
> Hello
> 
> After reading several of the responses to this, I’ve started to wonder: Is
> electric-indent-mode broken for everybody because it contains a bug or
> design flaw, or is electric-indent-mode working fine but simply not suitable
> for every situation?
> 
> In other words, where is the “right” place to fix this problem?

It was working in Org file automatically well and fine.

As if user decides to indent, electric-indent would help the user:

** HeadingRET

At this point below user may decide to indent:

   - First itemRET after RET
   ^
   - the new line appears here

User has to move the cursor to the point shown above for indentation
to begin. That is good as user decides it and it is text, it is not
programming language with special convention for indentation.

Electric indent mode always worked like that, including in Org mode
without any problems.

The change that is introduced in my opinion, and I did not look into
code, is changing how electric indent mode behaves specifically for
Org mode as somebody assumes that immediately after headingRET the new
lines should be indented, like if there is some special indentation
convention for Org mode.

So without user deciding to indent, it does following:

** HeadingRET
   - First line here
   
But there is no indentation convetion for Org mode of that kind that I
know.

The Org file shown on https://orgmode.org/ does not follow that type
of indenting.

Common indenting in Org mode is:

* Heading
Text
** Heading
Text
*** Heading text
Text
**** Heading
Text here
***** Heading
Text
****** Heading
Text

AND if somebody likes to indent differently electric indent mode would help.

Common indenting is not (other may tell me that I am wrong if this statement is wrong)

* Heading
  Text
** Heading
   Text
*** Heading text
    Text
**** Heading
     Text here
***** Heading
      Text
****** Heading
       Text

The above change was introduced as default to many users and is not
conveniente.

Especially not conveniente I find that I need to delete by using
backspace all the spaces inserted that I did not want after pressing
RET after inserting heading.

Some people will insert ONLY heading as a test without any text.


    

Re: Changed list indentation behavior: how to revert?

[David Rogers]

Jean Louis <bugs@gnu.support> writes:

> * David Rogers <davidandrewrogers@gmail.com> [2020-11-15 01:44]:
>> Hello
>> 
>> After reading several of the responses to this, I’ve started to 
>> wonder: Is
>> electric-indent-mode broken for everybody because it contains a 
>> bug or
>> design flaw, or is electric-indent-mode working fine but simply 
>> not suitable
>> for every situation?
>> 
>> In other words, where is the “right” place to fix this problem?
>
> It was working in Org file automatically well and fine.
>
> As if user decides to indent, electric-indent would help the 
> user:
>
> ** HeadingRET
>
> At this point below user may decide to indent:
>
>    - First itemRET after RET
>    ^
>    - the new line appears here
>
> User has to move the cursor to the point shown above for 
> indentation
> to begin. That is good as user decides it and it is text, it is 
> not
> programming language with special convention for indentation.
>
> Electric indent mode always worked like that, including in Org 
> mode
> without any problems.
>
> The change that is introduced in my opinion, and I did not look 
> into
> code, is changing how electric indent mode behaves specifically 
> for
> Org mode as somebody assumes that immediately after headingRET 
> the new
> lines should be indented, like if there is some special 
> indentation
> convention for Org mode.
>
> So without user deciding to indent, it does following:
>
> ** HeadingRET
>    - First line here
>    
> But there is no indentation convetion for Org mode of that kind 
> that I
> know.
>
> The Org file shown on https://orgmode.org/ does not follow that 
> type
> of indenting.
>
> Common indenting in Org mode is:
>
> * Heading
> Text
> ** Heading
> Text
> *** Heading text
> Text
> **** Heading
> Text here
> ***** Heading
> Text
> ****** Heading
> Text
>
> AND if somebody likes to indent differently electric indent mode 
> would help.
>
> Common indenting is not (other may tell me that I am wrong if 
> this statement is wrong)
>
> * Heading
>   Text
> ** Heading
>    Text
> *** Heading text
>     Text
> **** Heading
>      Text here
> ***** Heading
>       Text
> ****** Heading
>        Text
>
> The above change was introduced as default to many users and is 
> not
> conveniente.
>
> Especially not conveniente I find that I need to delete by using
> backspace all the spaces inserted that I did not want after 
> pressing
> RET after inserting heading.
>
> Some people will insert ONLY heading as a test without any text.

Thank you! You’ve really explained this clearly, and I understand 
your point.
Am I crazy to say that your last example of unwanted behavior is 
easier for me to read and understand? (and to me the common 
indenting is a hopeless mess?)

But I can see potential problems with it too - a long paragraph on 
a narrow screen would become hard to read and edit if there were 
very many indent levels. And I have no idea how code blocks would 
be affected because I don’t write any real code.

If the new behavior really does what you showed under “Common 
indenting is not…”, then I think I prefer the new way for my own 
use. And it makes sense to me that it should automatically work 
like that. I think the cursor jumping all the way back to the left 
margin after I’ve created a multi-starred heading makes no sense. 
But I’m also likely to forget to consider things that might go 
wrong with implementing a new plan, so I’m not a great judge.

Does the new behavior “break” something for you (causing errors 
etc), or does it just look wrong?

-- 
David Rogers

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* David Rogers <davidandrewrogers@gmail.com> [2020-11-15 10:48]:
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       e9973880-3447-42c6-99e4-2a0b430d136b
  :END:
> Jean Louis <bugs@gnu.support> writes:
> 
> > * David Rogers <davidandrewrogers@gmail.com> [2020-11-15 01:44]:
> > > Hello
> > > 
> > > After reading several of the responses to this, I’ve started to
> > > wonder: Is
> > > electric-indent-mode broken for everybody because it contains a bug
> > > or
> > > design flaw, or is electric-indent-mode working fine but simply not
> > > suitable
> > > for every situation?
> > > 
> > > In other words, where is the “right” place to fix this problem?
> > 
> > It was working in Org file automatically well and fine.
> > 
> > As if user decides to indent, electric-indent would help the user:
> > 
> > ** HeadingRET
> > 
> > At this point below user may decide to indent:
> > 
> >    - First itemRET after RET
> >    ^
> >    - the new line appears here
> > 
> > User has to move the cursor to the point shown above for indentation
> > to begin. That is good as user decides it and it is text, it is not
> > programming language with special convention for indentation.
> > 
> > Electric indent mode always worked like that, including in Org mode
> > without any problems.
> > 
> > The change that is introduced in my opinion, and I did not look into
> > code, is changing how electric indent mode behaves specifically for
> > Org mode as somebody assumes that immediately after headingRET the new
> > lines should be indented, like if there is some special indentation
> > convention for Org mode.
> > 
> > So without user deciding to indent, it does following:
> > 
> > ** HeadingRET
> >    - First line here
> >     But there is no indentation convetion for Org mode of that kind that
> > I
> > know.
> > 
> > The Org file shown on https://orgmode.org/ does not follow that type
> > of indenting.
> > 
> > Common indenting in Org mode is:
> > 
> > * Heading
> > Text
> > ** Heading
> > Text
> > *** Heading text
> > Text
> > **** Heading
> > Text here
> > ***** Heading
> > Text
> > ****** Heading
> > Text
> > 
> > AND if somebody likes to indent differently electric indent mode would
> > help.
> > 
> > Common indenting is not (other may tell me that I am wrong if this
> > statement is wrong)
> > 
> > * Heading
> >   Text
> > ** Heading
> >    Text
> > *** Heading text
> >     Text
> > **** Heading
> >      Text here
> > ***** Heading
> >       Text
> > ****** Heading
> >        Text
> > 
> > The above change was introduced as default to many users and is not
> > conveniente.
> > 
> > Especially not conveniente I find that I need to delete by using
> > backspace all the spaces inserted that I did not want after pressing
> > RET after inserting heading.
> > 
> > Some people will insert ONLY heading as a test without any text.
> 
> Thank you! You’ve really explained this clearly, and I understand your
> point.
> Am I crazy to say that your last example of unwanted behavior is easier for
> me to read and understand? (and to me the common indenting is a hopeless
> mess?)

I am not against indenting how users wish and want.

That is why electric-indent is there, it is by default there.

When you with your wanted behavior write this line:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       4e00e232-bf01-4ba5-a87b-6b0a9747ecee
   :END:

and press TAB, your cursor should automatically come to here below:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       be2a9fb6-bb27-416d-aa84-17e83a97f024
   :END:

   ^

Then when you start writing a line:

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       bb1feeb1-0e3c-429f-90a7-86b577f3b0c9
   :END:

   Line here
   Next line automatically here

Your next line is automatically there.

Does programmer impose to you HOW to indent? No. You explicitly decide
by using TAB and writing indented lines that you wish electric-indent
mode to work for you.

> If the new behavior really does what you showed under “Common
> indenting is not…”, then I think I prefer the new way for my own
> use.

I prefer that every user can explicityl decide how to indent. User
group that wish to indent exactly under the letter where heading
begins, they can press TAB and continue doing it.

It is one key press.

If that is introduced as default then users with many Org files on
file system are by default faced with inconvenience for the sake of
those who find it convenient.

> And it makes sense to me that it should automatically work like
> that. I think the cursor jumping all the way back to the left margin
> after I’ve created a multi-starred heading makes no sense.

As you are indenting it that way I can understand that. I have tried
that in past. Try M-S-left M-S-right on heading to see what is
happening with such indentation if your heading was with more stars.

If I write:

* HeadingRET
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       b2aaa359-12d6-4e64-a5d8-ec02b0f79532
  :END:
     - one line
     - second line

Then if I go back to H in Heading and do M-S-left to make parent
heading, indentation is not moving along. Then I am left to correct
all the indentations manually.

If I wish to use M-q on region to indent how I mean it, it does not
work. That is my expectation but this specific need not be right.

Because I do lessen the number of stars in heading I do not wish to be
bothered with indentation that is disturbing otherwise nice considered
structure.

If I remember well when copying trees it was also about same or
related problem either introducing new indentation or not keeping the
wanted indentation.

I am not talking against your indentation neither against mine. Just
pointing out that default features that are not mature and are not
compatible with habbits of users neither of Org in general, should not
be introduced as such. That is not enough tested.

If you do copy subtree with heading 2 below with some text under the
list of items with C-c C-x M-w and later insert under Heading 1 with
C-c C-x C-y you will get heading 3 as you see below which is not
indented. That is to me bug. It is not bug if users do not mind WHERE
to indent, if they do not mind that indentation is moved for one char
to the right side. It definitely does not support consistency.

* Heading 1
  :PROPERTIES:
  :CREATED:  [2020-11-15 Sun 11:53]
  :ID:       f490a670-487c-4bc7-b57d-e0b3052f1291
  :END:

** Heading 3
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       722e5db0-9da1-43c8-9e1e-030957dfe742
   :END:
    - line
    - line

If there is text HERE.

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       b46215dd-c4a9-47f1-a293-282c59021401
   :END:
   - line
   - line
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       f5775fe6-6771-4b59-9b15-d9720c9e5e12
    :END:
*** Heading 2
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       b4e9f819-8517-45d7-9237-0d654c99b657
    :END:
    - line
    - line

If there is text HERE.

** Here is end of headings
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       28bd67c3-906c-4ce7-ae63-79611938b018
   :END:

Feature of indentation after heading is not mature to be introduced by
default to all user of Org file.

Instead new option should be included that users who need that can
turn it on, and I do not mean to change anything with electric-indent
as default. Leave defaults how they are.

It is not logical to say to users of electric-indent, please remove it
only for Org files because we made defaults this way. I do need
electric indent including in Org files and it does work well itself.

But I’m also likely to forget to consider things that might go wrong
with implementing a new plan, so I’m not a great judge.  Does the
new behavior “break” something for you (causing errors etc), or does
it just look wrong?

** Heading
   :PROPERTIES:
   :CREATED:  [2020-11-15 Sun 11:53]
   :ID:       005cd684-f363-4008-a36e-d109d50a3f4f
   :END:
   - line
   - line
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       f018afcd-ed2c-4092-8e3e-f50ad915c2df
    :END:
*** Heading
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       a98ea345-3a42-4063-a795-0aad9790095f
    :END:
    - line
    - line
      
*** New
    :PROPERTIES:
    :CREATED:  [2020-11-15 Sun 11:53]
    :ID:       06bec39a-8f48-44cf-860f-614f3d85d5e7
    :END:
    
> But I’m also likely to forget to consider things that might go wrong
> with implementing a new plan, so I’m not a great judge.  Does the
> new behavior “break” something for you (causing errors etc), or does
> it just look wrong?  -- David Rogers

I have explained it above. It was introduced slightly and for I don't
know how many months I get all wrong indentations. It breaks
M-S-left/right and it breaks C-c C-x M-w based copy of trees and
subtrees and placing them in other parts of Org files.

Unspoken of table and other formatting that need to be compared
vertically, that goes out of any alignments. Using occur becomes hell,
but that is my personal preference just as it is yours to indent.

Table under one heading I wish to have aligned under different heading
in same columns.

You may like to have one table little right or left, those are
personal preferences.

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

hi, all.

David Rogers <davidandrewrogers@gmail.com> wrote:

> Am I crazy to say that your last example of unwanted behavior is
> easier for me to read and understand? (and to me the common 
> indenting is a hopeless mess?)

yes, in fact, the "new" way sort of has the buffer indentation match
that of the outline structure of the file (specified by asterisks).
there's a lot to be said for that.  (though, obviously, it's not what
everyone would want.)

if the new mode stays as the standard, maybe we'd want to capture an
asterisk typed immediately after a newline that would (by default), put
that line-beginning asterisk back in column one?

otherwise, this is what one gets (without remembering to do a C-j
instead of <RET>):
-----
* i wanted a headline<RET>
  * i wanted a subhead, but it's ignored by org mode
-----
which is maybe not optimal?

in most non-org modes (including in Org Src... buffers, and in org files
when writing org-mode lists), i'm a big fan of electric indent mode.

maybe an org-specific setting, "org-file-indent-follows-structure"?  if
true, it means the user wants to have a "raw" org document laid out
according to the outline structure of the document.  if false, it means
one, in general, wants the org file laid out with left-alignment (or,
right, in right-to-left) languages (not including embedded lists, and
whatever else i might be ignoring).

cheers, Greg

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

> hi, all.
>
> David Rogers <davidandrewrogers@gmail.com> wrote:
>
>> Am I crazy to say that your last example of unwanted behavior is
>> easier for me to read and understand? (and to me the common
>> indenting is a hopeless mess?)
>
> yes, in fact, the "new" way sort of has the buffer indentation match
> that of the outline structure of the file (specified by asterisks).
> there's a lot to be said for that.  (though, obviously, it's not what
> everyone would want.)
>
> if the new mode stays as the standard, maybe we'd want to capture an
> asterisk typed immediately after a newline that would (by default), put
> that line-beginning asterisk back in column one?
>

I think this would be a great improvement. It is probably more comon
that that when you type an asterisk as the first character in the line
you want it to be a header and therefore, in the first column. On rare
occasions when you do want an asterisk at the beginning of the line, you
can indent it manually.

> otherwise, this is what one gets (without remembering to do a C-j
> instead of <RET>):
> -----
> * i wanted a headline<RET>
>   * i wanted a subhead, but it's ignored by org mode
> -----
> which is maybe not optimal?
>
> in most non-org modes (including in Org Src... buffers, and in org files
> when writing org-mode lists), i'm a big fan of electric indent mode.
>
> maybe an org-specific setting, "org-file-indent-follows-structure"?  if
> true, it means the user wants to have a "raw" org document laid out
> according to the outline structure of the document.  if false, it means
> one, in general, wants the org file laid out with left-alignment (or,
> right, in right-to-left) languages (not including embedded lists, and
> whatever else i might be ignoring).
>

Seems like a reasonable approach to me.


--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Gustavo Barros]

Hi All,

On Sun, 15 Nov 2020 at 13:37, Greg Minshall <minshall@umich.edu> wrote:

> hi, all.
>
> David Rogers <davidandrewrogers@gmail.com> wrote:
>
>> Am I crazy to say that your last example of unwanted behavior is
>> easier for me to read and understand? (and to me the common 
>> indenting is a hopeless mess?)
>
> yes, in fact, the "new" way sort of has the buffer indentation match
> that of the outline structure of the file (specified by asterisks).
> there's a lot to be said for that.  (though, obviously, it's not what
> everyone would want.)
>
> if the new mode stays as the standard, maybe we'd want to capture an
> asterisk typed immediately after a newline that would (by default), put
> that line-beginning asterisk back in column one?
>
> otherwise, this is what one gets (without remembering to do a C-j
> instead of <RET>):
> -----
> * i wanted a headline<RET>
>   * i wanted a subhead, but it's ignored by org mode
> -----
> which is maybe not optimal?
>
> in most non-org modes (including in Org Src... buffers, and in org files
> when writing org-mode lists), i'm a big fan of electric indent mode.
>
> maybe an org-specific setting, "org-file-indent-follows-structure"?  if
> true, it means the user wants to have a "raw" org document laid out
> according to the outline structure of the document.  if false, it means
> one, in general, wants the org file laid out with left-alignment (or,
> right, in right-to-left) languages (not including embedded lists, and
> whatever else i might be ignoring).
>
> cheers, Greg

I'm quite surprised by the reaction to this issue, because
`electric-indent-mode' *does not change Org's indentation settings*, it
just applies them alongside RET.  Which makes me think that those who've
been so bitten by it where actually manually overriding (their own)
settings in this area by never applying indentation.  If that's your
case, you'd probably be very surprised of running `org-indent-region' in
your documents (don't do it, I don't want to break them).

In particular, one "surprising" result of the "new behavior" is that of
indentation after a heading.  That was already and continues to be
controlled by the user option `org-adapt-indentation'.  If you don't
want your content to be indented after a heading, set it to nil.  And
`electric-indent-mode' should do what you expect in this regard. 

I'm not sure if thus overriding your own (or Org's, if you prefer)
indentation settings by selectively applying indentation is a sane
approach, so perhaps `electric-indent-mode' may help you discipline your
editing to your benefit.  And make you more conscious of Org
indentation.  Especially because indentation is not a "free variable" in
Org, it is a syntactical aspect of an Org document and, conspicuously,
is critical to the definition of a heading and of plain lists.

An example from Greg:

> -----
> * i wanted a headline<RET>
>   * i wanted a subhead, but it's ignored by org mode
> -----

That's because the first one is indeed a heading, and the second is not,
it is a plain list item.  By definition a heading must start at the
left margin.

You (plural) could probably also get some juice from looking into, and
incorporating to muscle memory, `M-RET', `C-RET' and `C-j'.

Of course, with that said, if you really don't like
`electric-indent-mode' for Org, you can disable it as described in the
Org News, previously linked to in this thread.  There is ground to
prefer this, particularly for the list case, mentioned by Karl in the
original message of this thread.  But `electric-indent-mode' does not
induce a new pattern of indentation for Org, it just applies your
settings in this area, whose defaults have not changed of recent, as far
as I recall.

Finally, the "change" was not brought about by Org, but by Emacs.  Org
just (belatedly) tagged along.

Best regards,
Gustavo.

Re: Changed list indentation behavior: how to revert?

[Detlef Steuer]

Am Sun, 15 Nov 2020 08:48:56 -0300
schrieb Gustavo Barros <gtvbrs@gmail.com>:

> Hi All,
> 
> On Sun, 15 Nov 2020 at 13:37, Greg Minshall <minshall@umich.edu>
> wrote:
> 
> > hi, all.
> >
> > David Rogers <davidandrewrogers@gmail.com> wrote:
> >  
> >> Am I crazy to say that your last example of unwanted behavior is
> >> easier for me to read and understand? (and to me the common 
> >> indenting is a hopeless mess?)  
> >
> > yes, in fact, the "new" way sort of has the buffer indentation match
> > that of the outline structure of the file (specified by asterisks).
> > there's a lot to be said for that.  (though, obviously, it's not
> > what everyone would want.)
> >
> > if the new mode stays as the standard, maybe we'd want to capture an
> > asterisk typed immediately after a newline that would (by default),
> > put that line-beginning asterisk back in column one?
> >
> > otherwise, this is what one gets (without remembering to do a C-j
> > instead of <RET>):
> > -----
> > * i wanted a headline<RET>
> >   * i wanted a subhead, but it's ignored by org mode
> > -----
> > which is maybe not optimal?
> >
> > in most non-org modes (including in Org Src... buffers, and in org
> > files when writing org-mode lists), i'm a big fan of electric
> > indent mode.
> >
> > maybe an org-specific setting, "org-file-indent-follows-structure"?
> >  if true, it means the user wants to have a "raw" org document laid
> > out according to the outline structure of the document.  if false,
> > it means one, in general, wants the org file laid out with
> > left-alignment (or, right, in right-to-left) languages (not
> > including embedded lists, and whatever else i might be ignoring).
> >
> > cheers, Greg  
> 
> I'm quite surprised by the reaction to this issue, because
> `electric-indent-mode' *does not change Org's indentation settings*,
> it just applies them alongside RET.  Which makes me think that those
> who've been so bitten by it where actually manually overriding (their
> own) settings in this area by never applying indentation.  If that's
> your case, you'd probably be very surprised of running
> `org-indent-region' in your documents (don't do it, I don't want to
> break them).
> 
> In particular, one "surprising" result of the "new behavior" is that
> of indentation after a heading.  That was already and continues to be
> controlled by the user option `org-adapt-indentation'.  If you don't
> want your content to be indented after a heading, set it to nil.  And
> `electric-indent-mode' should do what you expect in this regard. 
> 
> I'm not sure if thus overriding your own (or Org's, if you prefer)
> indentation settings by selectively applying indentation is a sane
> approach, so perhaps `electric-indent-mode' may help you discipline
> your editing to your benefit.  And make you more conscious of Org
> indentation.  Especially because indentation is not a "free variable"
> in Org, it is a syntactical aspect of an Org document and,
> conspicuously, is critical to the definition of a heading and of
> plain lists.
> 
> An example from Greg:
> 
> > -----
> > * i wanted a headline<RET>
> >   * i wanted a subhead, but it's ignored by org mode
> > -----  
> 
> That's because the first one is indeed a heading, and the second is
> not, it is a plain list item.  By definition a heading must start at
> the left margin.
> 
> You (plural) could probably also get some juice from looking into, and
> incorporating to muscle memory, `M-RET', `C-RET' and `C-j'.
> 
> Of course, with that said, if you really don't like
> `electric-indent-mode' for Org, you can disable it as described in the
> Org News, previously linked to in this thread.  There is ground to
> prefer this, particularly for the list case, mentioned by Karl in the
> original message of this thread.  But `electric-indent-mode' does not
> induce a new pattern of indentation for Org, it just applies your
> settings in this area, whose defaults have not changed of recent, as
> far as I recall.
> 
> Finally, the "change" was not brought about by Org, but by Emacs.  Org
> just (belatedly) tagged along.
> 
> Best regards,
> Gustavo.
> 

Thank you for clearing that up!

Detlef

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Gustavo Barros <gtvbrs@gmail.com> [2020-11-15 14:49]:
:PROPERTIES:
:CREATED:  [2020-11-15 Sun 15:09]
:ID:       fef3cdfd-8870-4471-bcc7-4d690bfaceb2
:END:
> I'm quite surprised by the reaction to this issue, because
> `electric-indent-mode' *does not change Org's indentation settings*, it
> just applies them alongside RET.  Which makes me think that those who've
> been so bitten by it where actually manually overriding (their own)
> settings in this area by never applying indentation.  If that's your
> case, you'd probably be very surprised of running `org-indent-region' in
> your documents (don't do it, I don't want to break them).
> 
> In particular, one "surprising" result of the "new behavior" is that of
> indentation after a heading.  That was already and continues to be
> controlled by the user option `org-adapt-indentation'.  If you don't
> want your content to be indented after a heading, set it to nil.  And
> `electric-indent-mode' should do what you expect in this regard.

That is useful.

What is not useful is introducing default to thousands of users
without asking at least 1% of them. I have 2456 Org files on my system
and inconsistency introduced only on my system also affects people
like me and those who receive Org files produced on my system.

What about other users among 1% of them...

I propose that NEWS and Info files shall include pointers from
indentation descriptions to that option, as authors considered
including function to turn off electric indent mode, while it is now
obvious that this function here already does the work. So
documentation and NEWS shall be updated.

> An example from Greg:
> 
> > -----
> > * i wanted a headline<RET>
> >   * i wanted a subhead, but it's ignored by org mode
> > -----
> 
> That's because the first one is indeed a heading, and the second is not,
> it is a plain list item.  By definition a heading must start at the
> left margin.

That I did not know. Maybe I remember wrong but back in time even
indented headings worked. Now I have tested it they do not work, so
they need to be on the first column on left side.

Side thought: what about hebrew and arabic, how does Org mode work for
those languages?

> You (plural) could probably also get some juice from looking into, and
> incorporating to muscle memory, `M-RET', `C-RET' and `C-j'.

I do, thank you for reminder. Us in plural are sometimes teachers or
mentors who educate other people who are supposed to edit Org files in
most simple manner, and those people will never be able to write to
this list to find out which option where, not even to know about
indentation things. When default is introduced then all people
following an educator has to turn off default. They will not even know
why. One default introduced can cause butterfly effect.

General design of user interface should not conquer their habits
unless substantial amount of users have demanded it so.

> Of course, with that said, if you really don't like
> `electric-indent-mode' for Org, you can disable it as described in
> the Org News, previously linked to in this thread.  There is ground
> to prefer this, particularly for the list case, mentioned by Karl in
> the original message of this thread.  But `electric-indent-mode'
> does not induce a new pattern of indentation for Org, it just
> applies your settings in this area, whose defaults have not changed
> of recent, as far as I recall.  Finally, the "change" was not
> brought about by Org, but by Emacs.  Org just (belatedly) tagged
> along.  Best regards, Gustavo.

For me is now better to simple adjust: org-indent-region variable just
as you said.

Thank you for references.

Re: Changed list indentation behavior: how to revert?

[Gustavo Barros]

Hi Jean,

On Sun, 15 Nov 2020 at 09:09, Jean Louis <bugs@gnu.support> wrote:

>
> That is useful.
>

I'm glad to hear that.

>
>> You (plural) could probably also get some juice from looking into, 
>> and
>> incorporating to muscle memory, `M-RET', `C-RET' and `C-j'.
>
> I do, thank you for reminder. Us in plural are sometimes teachers or
> mentors who educate other people who are supposed to edit Org files in
> most simple manner, and those people will never be able to write to
> this list to find out which option where, not even to know about
> indentation things. When default is introduced then all people
> following an educator has to turn off default. They will not even know
> why. One default introduced can cause butterfly effect.
>

Also a fellow teacher here.  As you, I'm trying to transmit this 
information to you and others, because I find it useful.  Nobody needs 
to use `M-RET', `C-RET' and `C-j'.

> General design of user interface should not conquer their habits
> unless substantial amount of users have demanded it so.
>

And how exactly would maintainers know that?  Do you claim to be 
speaking on their (substantial amount of users) behalf?

>
> For me is now better to simple adjust: org-indent-region variable just
> as you said.
>

Please, don't confuse.  I said you should *not* use (the command) 
`org-indent-region' if you were systematically manually overriding 
indentation defaults.  I recommended to set the user option 
`org-adapt-indentation' to nil, which seems to be the desired value for 
most of the manifestations on this thread.

Best regards,
Gustavo.

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Gustavo Barros <gusbrs.2016@gmail.com> [2020-11-15 17:51]:
> > I do, thank you for reminder. Us in plural are sometimes teachers or
> > mentors who educate other people who are supposed to edit Org files in
> > most simple manner, and those people will never be able to write to
> > this list to find out which option where, not even to know about
> > indentation things. When default is introduced then all people
> > following an educator has to turn off default. They will not even know
> > why. One default introduced can cause butterfly effect.
> > 
> 
> Also a fellow teacher here.  As you, I'm trying to transmit this information
> to you and others, because I find it useful.  Nobody needs to use `M-RET',
> `C-RET' and `C-j'.

You are right, I am totally in agreement that it is useful as a
feature. In general I am using electric-indent mode.

Though that it is introduced by default is arguable what can be seen in responses here.

> > General design of user interface should not conquer their habits
> > unless substantial amount of users have demanded it so.
> 
> And how exactly would maintainers know that?  Do you claim to be speaking on
> their (substantial amount of users) behalf?

In this specific case it is easy to know what was the condition before
and what is condition after introduction of that new feature. Somebody
offered reasoning and I have seen 3-4 people declaring that function
works OK. Super fine. But that is not reasoning enough to change some
default behavior of a program for maybe hundreds of thousands of
users.

Better reasoning could be to ask on the mailing list what people think
about it and how they are using indentation as that way more
information may be obtained if such or any new feature would be more
useful or contraproductive for users.

You ask them.

> Please, don't confuse.  I said you should *not* use (the command)
> `org-indent-region' if you were systematically manually overriding
> indentation defaults.  I recommended to set the user option
> `org-adapt-indentation' to nil, which seems to be the desired value
> for most of the manifestations on this thread.

Maybe I made a mistake, as that is exactly what I did set. 

I am using Org for some years, so of course it came to me very
surprising. Person who just start using it recently with such defaults
should rarely find it awkward as person learns about it and assumes it
is how it is.

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


David Rogers <davidandrewrogers@gmail.com> writes:

>> Common indenting in Org mode is:
>>
>> * Heading
>> Text
>> ** Heading
>> Text
>> *** Heading text
>> Text
>> **** Heading
>> Text here
>> ***** Heading
>> Text
>> ****** Heading
>> Text
>>
>> AND if somebody likes to indent differently electric indent mode
>> would help.
>>
>> Common indenting is not (other may tell me that I am wrong if this
>> statement is wrong)
>>
>> * Heading
>>   Text
>> ** Heading
>>    Text
>> *** Heading text
>>     Text
>> **** Heading
>>      Text here
>> ***** Heading
>>       Text
>> ****** Heading
>>        Text
>>
>> The above change was introduced as default to many users and is not
>> conveniente.

> Am I crazy to say that your last example of unwanted behavior is
> easier for me to read and understand? (and to me the common 
> indenting is a hopeless mess?)

I think the second becomes horribly hard to read if you have more than
one line in the body. I use org-mode for writing long prose and having
all my text indented is pretty annoyming. I’ve tried to ignore and work
around it for some time now because I assumed it was a bug but didn’t
have a clear view when it appears.

I have text like this:

**** Exilanten: Clanjäger-Fuchsmenschen

*Fuchsmenschen mit Berserkererbe, das die Realität wanken lässt. Jäger
mit starken Sinnen, denen Gruppe und Clan stabilen Halt geben.*

Außensicht: /Einst unaufhaltsame Berserker, heute an ihre Clansregeln
gebundene Jäger, Piloten und Leibwächter. Sie erkennen mehr, als sie
zeigen./

Innensicht: /Der Clan ist deine Familie, die Tradition der Jagd dein
Halt in der Welt. Wenn deine Sinne die gesamte Welt zu durchdringen
scheinen, ist dein Biest nicht weit./

…

***** Kernantriebe

 #+caption: Kernantriebe der Ranmex
 #+attr_latex: :placement [H]
 #+tblname: kernantriebe-ranmex
 | Wollen     | Handeln       | Sein           |
 |------------+---------------+----------------|
 | Ansehen    | Tradition     | Leistungsstark |
 | Sicherheit | Anpassung     | Zuverlässig    |
 | Genugtuung | Unterstützung | Loyal          |

…

****** Beispiel: Chessos Reluna

 -  Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex.
 -  Zitat: „Was kriegen wir dafür?“
 -  Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches
    Schiff für einen eigenen Clan zu kaufen.

 Eigenschaften:

 -  Sehr Geschäftstüchtig: + (15)

 Berufe:

 -  Söldner: + (9)
 -  Pilot: + (9)

…

From here: https://hg.sr.ht/~arnebab/ews/browse/Hauptdokument/ews30/ews.org?rev=b8e3899c6d8b#L2644

> Does the new behavior “break” something for you (causing errors etc),
> or does it just look wrong?

It becomes much harder to work in prose. What you’ll note in my files is
that they all have

#+STARTUP: hidestars

So the above does not look to me like

****** Beispiel: Chessos Reluna

 -  Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex.
 -  Zitat: „Was kriegen wir dafür?“
 -  Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches
    Schiff für einen eigenen Clan zu kaufen.

But like

     * Beispiel: Chessos Reluna

 -  Beschreibung: Geschäftstüchtiger und kampferprobter Ranmex.
 -  Zitat: „Was kriegen wir dafür?“
 -  Motivation: Will genug Geld verdienen, um ein großes, kampftaugliches
    Schiff für einen eigenen Clan zu kaufen.


Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Detlef Steuer]

> 
> > Am I crazy to say that your last example of unwanted behavior is
> > easier for me to read and understand? (and to me the common 
> > indenting is a hopeless mess?)  
> 
> I think the second becomes horribly hard to read if you have more than
> one line in the body. I use org-mode for writing long prose and having
> all my text indented is pretty annoyming. I’ve tried to ignore and
> work around it for some time now because I assumed it was a bug but
> didn’t have a clear view when it appears.
> 


Just like Arne I thought it to be some kind or quirk in the code that
would self-heal at some point in time.

I'm constantly bitten by that change, but was too lazy to dig for the
cause. But now that I know, I want to add 2c.

If one writes prose it looks much more natural to have

* Healine<Ret>

start editing in column 1 of next row.
(Personally I would prefer to start at row 3, but independent
 of the depth of the heading. Probably there is a setting already?)

C-j is fine and nice, but I *feel* the default should be the other
way round.

I'm in no way emotional about these changes, but as Arne demonstrates
in his example text, org files become less readable when using the new
default. Heavy indenting is not what we are used to see if we have
subheadings in prose. Readability of org on the screen should be very high
in list of usability target. (Most probably it indeed is for the developers!
I'm not assuming you would neglect it!)
Maybe all boils down to a matter of taste, but at least imho Arne's
example shows the problem quite clearly.

For lists or sequences of mostly empty headings this does not matter
as much.

Furthermore: If I understand correctly electric-ident mode is thought to
be a helper for programming major modes. In my opinion org is no (not
only, much more than a) programming mode, so maybe electric ident is not
the optimal default. 

Just one more opinion.
Detlef

Re: Changed list indentation behavior: how to revert?

[Kévin Le Gouguec]

Detlef Steuer <steuer@hsu-hh.de> writes:

> I'm constantly bitten by that change, but was too lazy to dig for the
> cause. But now that I know, I want to add 2c.
>
> If one writes prose it looks much more natural to have
>
> * Healine<Ret>
>
> start editing in column 1 of next row.
> (Personally I would prefer to start at row 3, but independent
>  of the depth of the heading. Probably there is a setting already?)
>
> C-j is fine and nice, but I *feel* the default should be the other
> way round.
>
> I'm in no way emotional about these changes, but as Arne demonstrates
> in his example text, org files become less readable when using the new
> default. Heavy indenting is not what we are used to see if we have
> subheadings in prose. Readability of org on the screen should be very high
> in list of usability target. (Most probably it indeed is for the developers!
> I'm not assuming you would neglect it!)
> Maybe all boils down to a matter of taste, but at least imho Arne's
> example shows the problem quite clearly.
>
> For lists or sequences of mostly empty headings this does not matter
> as much.
>
> Furthermore: If I understand correctly electric-ident mode is thought to
> be a helper for programming major modes. In my opinion org is no (not
> only, much more than a) programming mode, so maybe electric ident is not
> the optimal default. 

Note that indenting section bodies by default predates Org 9.4: in Org
9.3, hitting TAB on the first line of text after a heading indents it to
column LEVEL+1.

IMHO, the default value of org-adapt-indentation might be the issue here
(made more visible by the change in 9.4): I agree that hard-indenting
prose should not be the default behaviour.  FWIW the .dir-locals.el file
at the root of Org's own repository sets this variable to nil; maybe
that suggests that it would be a better default?

(As I said in my reply to Jean Louis: I've only skimmed over this
thread; apologies if I've missed anything.)

Re: Changed list indentation behavior: how to revert?

[Kyle Meyer]

Kévin Le Gouguec writes:

> Detlef Steuer <steuer@hsu-hh.de> writes:
> Note that indenting section bodies by default predates Org 9.4: in Org
> 9.3, hitting TAB on the first line of text after a heading indents it to
> column LEVEL+1.

Yes, org-adapt-indentation has been around (with a default of t) since
4be4c5623 (version 4.12a, 2008-01-31).

> IMHO, the default value of org-adapt-indentation might be the issue here
> (made more visible by the change in 9.4): I agree that hard-indenting
> prose should not be the default behaviour.  FWIW the .dir-locals.el file
> at the root of Org's own repository sets this variable to nil; maybe
> that suggests that it would be a better default?

Perhaps.  I certainly prefer org-adapt-indentation at nil and would vote
for that if we were introducing the option today, but this would be
changing a longstanding default.

So, it seems that changing Org to honor electric-indent-mode is now
making some users aware of org-adapt-indentation and that its default
value is not what they want.

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Kyle Meyer <kyle@kyleam.com> writes:

> Kévin Le Gouguec writes:
>
>> Detlef Steuer <steuer@hsu-hh.de> writes:
>> Note that indenting section bodies by default predates Org 9.4: in Org
>> 9.3, hitting TAB on the first line of text after a heading indents it to
>> column LEVEL+1.
>
> Yes, org-adapt-indentation has been around (with a default of t) since
> 4be4c5623 (version 4.12a, 2008-01-31).
>
>> IMHO, the default value of org-adapt-indentation might be the issue here
>> (made more visible by the change in 9.4): I agree that hard-indenting
>> prose should not be the default behaviour.  FWIW the .dir-locals.el file
>> at the root of Org's own repository sets this variable to nil; maybe
>> that suggests that it would be a better default?
>
> Perhaps.  I certainly prefer org-adapt-indentation at nil and would vote
> for that if we were introducing the option today, but this would be
> changing a longstanding default.
>
> So, it seems that changing Org to honor electric-indent-mode is now
> making some users aware of org-adapt-indentation and that its default
> value is not what they want.

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?

Tim

--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Tim Cross <theophilusx@gmail.com> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>
>> Kévin Le Gouguec writes:
>>
>>> Detlef Steuer <steuer@hsu-hh.de> writes:
>>> Note that indenting section bodies by default predates Org 9.4: in Org
>>> 9.3, hitting TAB on the first line of text after a heading indents it to
>>> column LEVEL+1.
>>
>> Yes, org-adapt-indentation has been around (with a default of t) since
>> 4be4c5623 (version 4.12a, 2008-01-31).
>>
>>> IMHO, the default value of org-adapt-indentation might be the issue here
>>> (made more visible by the change in 9.4): I agree that hard-indenting
>>> prose should not be the default behaviour.  FWIW the .dir-locals.el file
>>> at the root of Org's own repository sets this variable to nil; maybe
>>> that suggests that it would be a better default?
>>
>> Perhaps.  I certainly prefer org-adapt-indentation at nil and would vote
>> for that if we were introducing the option today, but this would be
>> changing a longstanding default.
>>
>> So, it seems that changing Org to honor electric-indent-mode is now
>> making some users aware of org-adapt-indentation and that its default
>> value is not what they want.
>
> 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

Re: Changed list indentation behavior: how to revert?

[Gustavo Barros]

Hi Tim,
Hi All,

On Mon, 16 Nov 2020 at 18:15, Tim Cross <theophilusx@gmail.com> wrote:

> Tim Cross <theophilusx@gmail.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.

Re: Changed list indentation behavior: how to revert?

[T.F. Torrey]

Hello all,

I apologize in advance that this is so long.

I've been following this thread closely, because I've been using Org
mode daily for well over a decade, and this behavior affects me in
several important ways.  I think this summary might be helpful.

Forever, it has been possible to start a heading in Org by typing a
return one or more times, then typing an asterisk and a space and the
heading text.  To add a series of headings, just keep hitting return at
the end of the current one, type an asterisk and a space and the next
one, then repeat.  If you want subheadings, it is as simple as typing
more asterisks.  Easy.

This worked because electric-indent-mode defaulted to off, and although
org-adapt-indentation defaulted to t, it didn't affect this situation.

The default behavior here matters because Org is a killer feature of
Emacs, enticing many people to give it a try, including my nine-year-old
daughter.  For them, it should behave by default the way it looks like
it should.  That means, typing asterisks and text for headings, followed
by returns, and text, and more asterisks, should just work by default.

#+NAME: Old Defaults: electric-indent-mode OFF and org-adapt-indent t
#+begin_example org
,* Testing out Org, type <RET> here once or twice

I get it!  I'll type <RET> once or twice again and start a subheading.

,** Headings are easy!  Now another <RET> or two for subhead content

This is awesome!  It works just as I expect, and I don't have to
memorize a bunch of key chords just to get started.  And folding is
awesome!  I love Org!  I will stick with it and learn it all!
#+end_example

I have probably typed close to a million headings like this all by
myself, and collectively we have probably typed billions or more.

The last release, as everyone knows, turned on electric-indent-mode by
default.  So, right now, typing an Org document with default settings
does not work like it looks like it should.  This is the new experience
for people used to the old defaults, and beginners like my daughter:

#+NAME: New Defaults: electric-indent-mode ON and org-adapt-indent t
#+begin_example org
,* I typed an asterisk for this heading, how about <RET> here once or twice

  Okay.  This is indented.  Since I'm new, I don't realize it isn't
  useful yet, or that it makes a difference at all.  How about a
  subheading?  I'll hit <RET> a couple times, they type two asterisks.

  ,** Is this a subheading? It looks like one.  <RET> again here ...

  Okay, the indentation isn't the same, but maybe it's okay?  I
  probably didn't even notice.

  ,*** I think I'm organizing my document with *'s and <RET>'s

  I'm going to try folding my stuff, becaue I saw that and it looks
  awesome.

  Wait!  The instructions say <TAB> will cycle the folding, but it
  only works on the top level.  What?

  Okay, some searching said I have to modify init, or something, or
  type some weird key combinations.  What?  This looked like it was
  going to be easy.  Nerds are liars.

  I can't figure this out, and I don't have time to mess with this.
  I'm going back to Word.  Maybe I'll try Markdown tomorrow.
#+end_example

For new users, step one is either to start changing default settings,
start learning key chords and/or arcane (to beginners) commands---or go
back to Word or Markdown.

Turning on electric-indent-mode, all by itself, shouldn't break the
useful or customary indentation that the users of Org expect, but it
has.  Instead of starting a new heading by typing <RET> one or more
times, then typing an asterisk and a space and a new heading, a user
has to either hit some control characters with returns, or backspace to
column zero, or something else.

The manual shows heading and body formatting as this:

#+NAME: Org Manual Sample: electric-indent-mode on, org-adapt-indent t
#+begin_example org
,* Top level headline
,** Second level
,*** Third level
    some text
,*** Third level
    more text
,* Another top level headline
#+end_example

I don't recall ever seeing an Org document in real life with the body
indented at the level of each heading, and I haven't seen anyone argue
for that behavior on this thread.  I've tried it, and the text body
width rapidly becomes too narrow to be useful.  As several people have
noted, even the Org repositories turn this off, which suggests even
the developers don't find it useful.  Why this is set as the default,
I have no idea, but it didn't really matter until now.

An Org document looks like you can create it by typing asterisks,
text, and returns, but you can't, not by default, anyway.

That's the root of the problem: the longstanding default *behavior*
has been changed.  The only people unaffected are people who already
had compensatory settings in their init files.

As far as I can tell, turning on electric-indent-mode by default was
done for no reason other than other Emacs modes have it as a default.

The proper fix for this is one of two choices:

1. If keeping electric-indent-mode on is really important, the easiest
   way to restore intuitive behavior is to change the default of
   org-adapt-indentation to nil.  Yes, this changes a longstanding
   default, but it is necessitated because of the change of another
   longstanding default: electric-indent-mode.  Before, anyone who
   wanted text indented by default needed to specify that in their init
   file, so this should not inconvenience anyone who wasn't
   inconvenienced before.

or

2. More involved would be to change the default behavior of Org's
   electric indentation so that typing <RET> at the end of a heading
   takes you back to column 0 by default.  In many contexts, the
   indentation provided by org-auto-indent is useful, but not this
   one.

The Emacs manual says that "Electric Indent mode is a global minor mode
that automatically indents the line after every <RET> you type", but
that's not exactly true.  What it does do is indent a line to what is
useful or customary based on the context, which is often not at all.  In
the context of hitting <RET> at the end of a heading in Org, what is
useful may be debatable, but it seems customary for all serious Org
users to return to column 0, and that seems what new and casual users
expect.

Finally, I can point out that, for myself, adding another line to my
init file (actually a literate Org doc) is not a big deal.  I've been
using Org and Emacs long enough that changing defaults doesn't bother me
much.

For new and casual users, including my nine-year-old daughter, however,
I hope we can change the defaults so that it works the way it looks like
it should.  It's not easy to get her to try Emacs and Org, and this
makes it harder.

Side note: the manual frequently refers to headings as "headlines", but
that is not the right use of that word.  To whit: there is no such thing
as a "subheadline", but there is a "subheading", because that construct
is a "heading", and a "headline" is something else.

All the best,
Terry

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

Terry,
   Thank you very much for the clear articulation of the problem,
it enable me to see what the issue is and find more and deeper
issues with the change.

Speaking as someone who was not affected by this change
due to the peculiarities of my config, let me say as a fairly
impartial participant, this change is completely broken and
it is clear upstream Emacs did zero due diligence on the
impact it would have for org-mode. The current implementation
of elastic-indent-mode is obviously broken for use in org.

What do I mean? Currently, electric-intent-mode t is actively
destructive in certain cases. Consider a headline created by *-space
or M-ret. If you then hit return (because you don't know what to call
that headline but have the idea you want to type) electric-intent-mode
will delete the trailing space making it no longer a headline!!!!!!!!!!!!
WHAT?! This is horrible broken behavior in org mode!

At the very least this must be fixed if electric-indent-mode is to be on
by default in org-mode. It is clear that electric-indent-mode as implemented,
is unsuitable for use in org-mode since it actively ignores significant trailing
whitespace.

The sane thing to do is to revert to electric-indent-mode nil at least until
the obvious brokeness is fixed, and even then, why make people undo
a stupid computer decision by typing backspace when they can just
as easily do what they mean by typing tab!??! We don't even have to
poll the community to figure out who is going to be forced to type more.

I don't mean to sound ungrateful to the folks who have worked to match
with upstream, but it is clear that upstream has done zero testing on
the impact of that change on org-mode (or any other mode for that matter).
Until the upstream behavior can be fixed or org can patch the brokenness
this needs to be reverted. Even then, why is the "smart" option that changes
the meaning of the bloody return key enabled by default? I will point back to
https://orgmode.org/list/87ees6fp8r.fsf@nicolasgoaziou.fr/ and state that
had I spotted this thread at the time, I would have spoken up to point out
that it would likely not be a welcome change, as this thread shows. The
good news is that all is not lost and now when users want electric-indent-mode
in org it will be consistent with upstream.

Best,
Tom

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Tom Gillespie <tgbugs@gmail.com> writes:
> with upstream, but it is clear that upstream has done zero testing on
> the impact of that change on org-mode (or any other mode for that matter).

I think this statement is too hard. If you use org purely for the
example usecase (headings with a single content-line) and use CTRL-RET
to create new headings, you won’t notice the change. And I’m pretty sure
they tested that.

The change hurts for those who use org-mode as plain text with
superpowers, or as general source-format that can export to plain text,
LaTeX, html, and many more.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Michal Politowski]

On Mon, 16 Nov 2020 16:24:45 -0700, T.F. Torrey wrote:
[...]
> The proper fix for this is one of two choices:
> 
> 1. If keeping electric-indent-mode on is really important, the easiest
>    way to restore intuitive behavior is to change the default of
>    org-adapt-indentation to nil.  Yes, this changes a longstanding
>    default, but it is necessitated because of the change of another
>    longstanding default: electric-indent-mode.  Before, anyone who
>    wanted text indented by default needed to specify that in their init
>    file, so this should not inconvenience anyone who wasn't
>    inconvenienced before.
> 
> or
> 
> 2. More involved would be to change the default behavior of Org's
>    electric indentation so that typing <RET> at the end of a heading
>    takes you back to column 0 by default.  In many contexts, the
>    indentation provided by org-auto-indent is useful, but not this
>    one.

Or maybe?
3. Pair the electric indentation + org-adapt-indentation with electric asterisk
(actually more of an electric space) so that "<RET>* " removes the indentation.

So this is similar to conditional option 2. I do not think I really understand
the benefits of option 2. as is. Wouldn't it be doing a lot of work to just
unconditionally undo the work of electric indentation and o-a-i without actually
turning them off?

Finally, given how few people seem to have benefitted from or even noticed
org-adapt-indentation, option 1. does seem reasonable to this casual user
(who has o-a-i turned off almost accidentally, via org-indent-mode).

-- 
Michał Politowski
Talking has been known to lead to communication if practiced carelessly.

Re: Changed list indentation behavior: how to revert?

[Marcel Ventosa]

Hi all,

I've just caught up with this conversation after feeling similar
friction to others since the 'electric-indent' change.

When it happened, I spent time trying to figure out how to revert the
change (thinking I had introduced the bug myself in my configuration
somehow) and ended up setting 'org-adapt-indentation' to 'nil', which
solved some of my inconvenience while typing headlines, lists, etc.,
but not source blocks.


Source blocks
=============

After the change, it became extremely inconvenient to edit them inline,
as the level of indentation for the whole block changed constantly in
unexpected and unpredictable ways (when I pressed TAB, but maybe also in
other cases?).

In the end, the only solution has been to use {C-c'} any time I want to
modify one. While I understand that editing the source block in a
separate buffer is probably the "correct(TM)" way, I often make small
changes while looking at another buffer on a split screen, and {C-c'}
always pops up in a new buffer and forces me to reconfigure my buffers
to continue (I realize I can change 'org-src-window-setup', but
sometimes I still just want to edit the code in the actual Org document
itself).


---------------

I understand why the change was introduced, but it has really caused
some friction in my day-to-day work. I am very happy to find out today
how to undo this upgrade: I disliked and resented the rigitidy it
introduced into my interactions with Org. Looking back, I wish I'd spent
more time investigating the cause.


Best regards,

Marcel


On Mon, 16 Nov 2020 08:21:53 -0300
Gustavo Barros <gusbrs.2016@gmail.com> wrote:

> Hi Tim,
> Hi All,
> 
> On Mon, 16 Nov 2020 at 18:15, Tim Cross <theophilusx@gmail.com> wrote:
> 
> > Tim Cross <theophilusx@gmail.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.
> 

Re: Changed list indentation behavior: how to revert?

[Kévin Le Gouguec]

Tim Cross <theophilusx@gmail.com> writes:

> 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.

Yep; as I mentioned in <87k0umjn74.fsf@gmail.com>, I didn't know about
org-adapt-indentation when I wrote this NEWS entry.  If I had, I would
have
- mentioned this variable in the NEWS entry, and/or
- campaigned for a change to the default value.

Re: Changed list indentation behavior: how to revert?

[Bill Burdick]

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

On Mon, Nov 16, 2020 at 8:43 AM Tim Cross <theophilusx@gmail.com> wrote:

> 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.
>

Hi Tim,

Consistency is good but when people have been using org-mode for 10+ years
get a fundamental behavior change (like when you hit enter) through an
update it can be confusing. Perhaps old behavior should be preserved by
default for current org users but the new behavior adopted for new installs.

Maybe a heuristic something like this would work:

1) when org-mode starts, it could check to see if there are any
existing customizations at all -- if there are, the user has used org before
2) if org-adapt-indentation is not currently customized, customize it to nil

Or something like that.

This should preserve the old behavior for old org users but use the new
behavior for new users (except for old users with fresh emacs installs but
maybe this is good enough).


-- Bill

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

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

i wonder if a grid might help?  i.e., contexts in which we are all
happy, others where we might disagree?  below, i try; i'm sure i've
missed cases.

question: what does <RET> do/would we like it to do when we are in?

=========================================
tables: next row, current column

Org Src buffers: electric-indent per declared language major
mode rules.

src blocks: same as in Org Src buffers (i think there have been some
very nice "recent" improvements here, which are great, and for which,
belated thanks!)

^^   i think we are all happy with those
=========================================
=========================================
vv   here, i think, well, "Houston, ..." :)

after n* heading:
    column 1
  vs
    column n+2

list entry (end of line):
    column where previous "-" was (to start a new list item)
  vs
    two columns *after* where previous "-" was (to continue with the
    current list item)

immediately after (non-blank, non-list, non-heading) with text starting
in column n:
    column 1
  vs
    column n

immediately after a blank line:
    column 1
  vs
    column of first non-blank character of most recent non-blank line?
=========================================

surveymonkey, anyone?  :)  not to vote, but i'm curious to what extent
we divide cleanly into two groups (in which case, maybe an option for
which "major mode indentation" style one prefers for org-mode makes
sense), or if we are uniformly distributed across the power set. :)

btw, it seems to me that M-q (fill-paragraph) also has *something* to
say here.  i.e., though *i* want <RET> from a list entry to line me up
at the previous "-", i want M-q within a list entry to add new lines
starting two columns past that point.  i guess i see it as orthogonal
(and, so far, non-controversial) to the current discussion, and hope it
so stays!

cheers, Greg

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Greg Minshall <minshall@umich.edu> writes:

> i wonder if a grid might help?  i.e., contexts in which we are all
> happy, others where we might disagree?  below, i try; i'm sure i've
> missed cases.
>
> question: what does <RET> do/would we like it to do when we are in?
>
> =========================================
> tables: next row, current column
>
> Org Src buffers: electric-indent per declared language major
> mode rules.
>
> src blocks: same as in Org Src buffers (i think there have been some
> very nice "recent" improvements here, which are great, and for which,
> belated thanks!)
>
> ^^   i think we are all happy with those
> =========================================
> =========================================
> vv   here, i think, well, "Houston, ..." :)
>
> after n* heading:
>     column 1
>   vs
>     column n+2
>
> list entry (end of line):
>     column where previous "-" was (to start a new list item)
>   vs
>     two columns *after* where previous "-" was (to continue with the
>     current list item)
>
> immediately after (non-blank, non-list, non-heading) with text starting
> in column n:
>     column 1
>   vs
>     column n
>
> immediately after a blank line:
>     column 1
>   vs
>     column of first non-blank character of most recent non-blank line?
> =========================================
>
> surveymonkey, anyone?  :)  not to vote, but i'm curious to what extent
> we divide cleanly into two groups (in which case, maybe an option for
> which "major mode indentation" style one prefers for org-mode makes
> sense), or if we are uniformly distributed across the power set. :)
>
> btw, it seems to me that M-q (fill-paragraph) also has *something* to
> say here.  i.e., though *i* want <RET> from a list entry to line me up
> at the previous "-", i want M-q within a list entry to add new lines
> starting two columns past that point.  i guess i see it as orthogonal
> (and, so far, non-controversial) to the current discussion, and hope it
> so stays!
>
> cheers, Greg

Hi Greg,

I think there are more than two groups.

I would start by considering it as two top level groups

  1. Indentation behaviour with electric-indent enabled and
  org-adapt-indent set to t (the current defaults)
  2. Indentation behaviour with electric-indent disabled as suggested in
  the org NEWS file.
  3. Indentation behaviour with different values for org-adaptive-indentation.

Then we have the different values which org-adapt-indentation can be set
to that will 'tweak' the way adaptive indentation works in different
contexts.

It is my guess that the majority of people can in fact have the
behaviour they want either by turning of electric indent mode or by
setting org-adaptive-indentation to one of the supported values. I would
encourage anyone who is not happy with the default to look at the
different supported values for org-adaptive-indentation to see if the
tweaking it provides might make org indentation work closer to what they
like (as opposed to turning all automatic indentation off).

There are probably a few edge cases, but to identify those, we need to
first eliminate all the cases which can be 'resolved' with existing
configuration options.

Tim

--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

hi, Tim, et al.

i started feeling guilty yesterday, partly for being party to prolonging
this discussion (though i do think it may be important?).  but also for
realizing i had *not* explored the alternatives Tim, Gustavo, and others
have suggested.

the following is *clearly* the department of irreproducible results.
but, i've tried to document the effects of 'electric-indent-mode' and
'org-adapt-indentation' on a number of scenarios.  i present the results
with some explanation, but without much analysis.

the irreproducibility is just (afaict) a function of my not being able
to type the same thing over and over again, and/or transcribe the
results correctly.  the results here are, for the most part, the result
of several runs, trying to eliminate disparities, and add new forms of
results (such as, "two <RET>, then third returns to column one").  but,
if anyone wants to try on their own, or automate further (the
possibilities are endless! :), please, lütfen!

there's an e-lisp function, and the shell double for loop towards the
end of this e-mail.

first, here's the *transposed* table, as i think it is more readable.
(the word "transpose" should show up in the info pages!).  at the end of
the e-mail, though, i'll put the non-transposed -- maybe one sees
some things there easier.

|           | t,t     | t,headline-data |   t,nil | nil,t     | nil,headline-data |   nil,nil |
|-----------+---------+-----------------+---------+-----------+-------------------+-----------|
| head      | n       |         n,nbl,1 |       1 | 1         |                 1 |         1 |
| head<C-j> | 1       |               1 |       1 | n         |           n,nbl,1 |         1 |
| src{      | n       |             n+2 |     n+2 | 1         |                 1 |         1 |
| src{<C-j> | 1       |               1 |       1 | n+2 [t-2] |         n+2 [t-2] | n+2 [t-2] |
| src;      | n-4     |             n-2 |     n-2 | 1         |                 1 |         1 |
| src;<C-j> | 1       |               1 |       1 | n-2 [t+2] |         n-2 [t+2] | n-2 [t+2] |
| list<RET> | n+2*2,1 |               1 | n+2*2,1 | 1         |                 1 |         1 |
| list<C-j> | 1       |               1 |       1 | n+2*2,1   |                 1 |   n+2*2,1 |
| line      | n       |               1 |       n | 1         |                 1 |         1 |
| line<C-j> | 1       |               1 |       1 | n         |                 1 |         n |

the columns are (electric-indent,org-adapt-indentation) pairs.

here are the cases (rows) and results (contents of cells).  the
"<C-j>"-suffixed cases use C-j rather than <RET>.

- head :: <RET> from a headline
  - n :: stays indented for "infinite" blank <RET>
  - n,nbl,1 :: n, then after first non-blank line, <RET> goes
    to 1
  - 1 :: goes
- src{ :: <RET> from, e.g., 'if (x) {'
  - n-2 :: undents by 2
  - n+2 :: indents
  - n+2 [t-2] :: goes to n+2 (but, <TAB> of non-blank line goes to
    n+4)
  - n-2 [t+2] :: goes to n-2 (but, that 2 past the previous <TAB>
    indentation level)
- src; :: <RET> from a regular program statement
- list<RET> :: <RET> from item in list
  - n+2 :: indents once
  - n+2*2,1 :: indents once, stays on next <RET>, then 1 on next <RET>
    (three <RET> total)
  - 1 :: column 1
- line :: <RET> from an indented line
  - n :: never goes to 1
  - 1 :: goes to 1


brute force lisp code
#+begin_src elisp
(defun feorge (el oai fname)
  (progn
    (add-hook 'org-mode-hook (electric-indent-mode (if el 1 0)))
    (find-file fname)
    (setq org-adapt-indentation oai)
    (let
        ((header "| |head | head<C-j> | src{ | src{<C-j> | src; | src;<C-j> | list<RET> | list<C-j> | line | line<C-j>|")
         (hline "|-+-+-+-+-+-+-+-+-+-+-|")
         (results (format "| %s,%s | ||||||||||" electric-indent-mode org-adapt-indentation)))
      (goto-char (point-max))
      (insert (format "el %s; oai %s" el oai))
      (goto-char (point-max))
      (newline)
      (insert (version))
      (goto-char (point-max))
      (newline)
      (insert (org-version))
      (goto-char (point-max))
      (newline)
      (insert header)
      (goto-char (point-max))
      (newline)
      (insert hline)
      (goto-char (point-max))
      (newline)
      (insert results)
      (goto-char (point-max))
      (newline)
      (goto-char (point-max))
      (newline))))
#+end_src

and, the shell loop-de-loop
#+begin_src sh
  for el in t nil; do
      for oai in t \'headline-data nil; do
          rm -f *x.org*;
          emacs -l ~/tmp/feorge.el --eval "(feorge ${el} ${oai} \"x.org\")";     
      done;   
  done
#+end_src

untransposed table:

|                   |    head | head<C-j> | src{ | src{<C-j> | src; | src;<C-j> | list<RET> | list<C-j> | line | line<C-j> |
|-------------------+---------+-----------+------+-----------+------+-----------+-----------+-----------+------+-----------|
| t,t               |       n |         1 | n    | 1         | n-4  | 1         |   n+2*2,1 |         1 |    n |         1 |
| t,headline-data   | n,nbl,1 |         1 | n+2  | 1         | n-2  | 1         |         1 |         1 |    1 |         1 |
| t,nil             |       1 |         1 | n+2  | 1         | n-2  | 1         |   n+2*2,1 |         1 |    n |         1 |
| nil,t             |       1 |         n | 1    | n+2 [t-2] | 1    | n-2 [t+2] |         1 |   n+2*2,1 |    1 |         n |
| nil,headline-data |       1 |   n,nbl,1 | 1    | n+2 [t-2] | 1    | n-2 [t+2] |         1 |         1 |    1 |         1 |
| nil,nil           |       1 |         1 | 1    | n+2 [t-2] | 1    | n-2 [t+2] |         1 |   n+2*2,1 |    1 |         n |

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

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

Good work Greg.

My only comment is about the tests in src blocks. I'm not sure about these
as I always use the special editing mode for source blocks and I would
expect that when you do this, the editing buffer would adopt the semantics
of the native mode for the source language being edited. (I have
org-src-tab-acts-natively t in my init). Were your tests just inside a src
block in an org buffer or inside the special editing buffer?

From that table and what others have posted, I suspect many would be best
off with org-adapt-indentation set to nil or possible 'heading-data.
Personally, I've not found the change an issue, but I rarely go more than 3
or 4 levels deep in my headlines and am use to C-j to add a non-indented
line. However, I'm thinking about giving heading-data a spin as I like the
indentation for planning lines and have less of a preference for the entry
content.

Tim

On Tue, 17 Nov 2020 at 15:03, Greg Minshall <minshall@umich.edu> wrote:

> hi, Tim, et al.
>
> i started feeling guilty yesterday, partly for being party to prolonging
> this discussion (though i do think it may be important?).  but also for
> realizing i had *not* explored the alternatives Tim, Gustavo, and others
> have suggested.
>
> the following is *clearly* the department of irreproducible results.
> but, i've tried to document the effects of 'electric-indent-mode' and
> 'org-adapt-indentation' on a number of scenarios.  i present the results
> with some explanation, but without much analysis.
>
> the irreproducibility is just (afaict) a function of my not being able
> to type the same thing over and over again, and/or transcribe the
> results correctly.  the results here are, for the most part, the result
> of several runs, trying to eliminate disparities, and add new forms of
> results (such as, "two <RET>, then third returns to column one").  but,
> if anyone wants to try on their own, or automate further (the
> possibilities are endless! :), please, lütfen!
>
> there's an e-lisp function, and the shell double for loop towards the
> end of this e-mail.
>
> first, here's the *transposed* table, as i think it is more readable.
> (the word "transpose" should show up in the info pages!).  at the end of
> the e-mail, though, i'll put the non-transposed -- maybe one sees
> some things there easier.
>
> |           | t,t     | t,headline-data |   t,nil | nil,t     |
> nil,headline-data |   nil,nil |
>
> |-----------+---------+-----------------+---------+-----------+-------------------+-----------|
> | head      | n       |         n,nbl,1 |       1 | 1         |
>      1 |         1 |
> | head<C-j> | 1       |               1 |       1 | n         |
>  n,nbl,1 |         1 |
> | src{      | n       |             n+2 |     n+2 | 1         |
>      1 |         1 |
> | src{<C-j> | 1       |               1 |       1 | n+2 [t-2] |
>  n+2 [t-2] | n+2 [t-2] |
> | src;      | n-4     |             n-2 |     n-2 | 1         |
>      1 |         1 |
> | src;<C-j> | 1       |               1 |       1 | n-2 [t+2] |
>  n-2 [t+2] | n-2 [t+2] |
> | list<RET> | n+2*2,1 |               1 | n+2*2,1 | 1         |
>      1 |         1 |
> | list<C-j> | 1       |               1 |       1 | n+2*2,1   |
>      1 |   n+2*2,1 |
> | line      | n       |               1 |       n | 1         |
>      1 |         1 |
> | line<C-j> | 1       |               1 |       1 | n         |
>      1 |         n |
>
> the columns are (electric-indent,org-adapt-indentation) pairs.
>
> here are the cases (rows) and results (contents of cells).  the
> "<C-j>"-suffixed cases use C-j rather than <RET>.
>
> - head :: <RET> from a headline
>   - n :: stays indented for "infinite" blank <RET>
>   - n,nbl,1 :: n, then after first non-blank line, <RET> goes
>     to 1
>   - 1 :: goes
> - src{ :: <RET> from, e.g., 'if (x) {'
>   - n-2 :: undents by 2
>   - n+2 :: indents
>   - n+2 [t-2] :: goes to n+2 (but, <TAB> of non-blank line goes to
>     n+4)
>   - n-2 [t+2] :: goes to n-2 (but, that 2 past the previous <TAB>
>     indentation level)
> - src; :: <RET> from a regular program statement
> - list<RET> :: <RET> from item in list
>   - n+2 :: indents once
>   - n+2*2,1 :: indents once, stays on next <RET>, then 1 on next <RET>
>     (three <RET> total)
>   - 1 :: column 1
> - line :: <RET> from an indented line
>   - n :: never goes to 1
>   - 1 :: goes to 1
>
>
> brute force lisp code
> #+begin_src elisp
> (defun feorge (el oai fname)
>   (progn
>     (add-hook 'org-mode-hook (electric-indent-mode (if el 1 0)))
>     (find-file fname)
>     (setq org-adapt-indentation oai)
>     (let
>         ((header "| |head | head<C-j> | src{ | src{<C-j> | src; |
> src;<C-j> | list<RET> | list<C-j> | line | line<C-j>|")
>          (hline "|-+-+-+-+-+-+-+-+-+-+-|")
>          (results (format "| %s,%s | ||||||||||" electric-indent-mode
> org-adapt-indentation)))
>       (goto-char (point-max))
>       (insert (format "el %s; oai %s" el oai))
>       (goto-char (point-max))
>       (newline)
>       (insert (version))
>       (goto-char (point-max))
>       (newline)
>       (insert (org-version))
>       (goto-char (point-max))
>       (newline)
>       (insert header)
>       (goto-char (point-max))
>       (newline)
>       (insert hline)
>       (goto-char (point-max))
>       (newline)
>       (insert results)
>       (goto-char (point-max))
>       (newline)
>       (goto-char (point-max))
>       (newline))))
> #+end_src
>
> and, the shell loop-de-loop
> #+begin_src sh
>   for el in t nil; do
>       for oai in t \'headline-data nil; do
>           rm -f *x.org*;
>           emacs -l ~/tmp/feorge.el --eval "(feorge ${el} ${oai} \"x.org\")";
>
>       done;
>   done
> #+end_src
>
> untransposed table:
>
> |                   |    head | head<C-j> | src{ | src{<C-j> | src; |
> src;<C-j> | list<RET> | list<C-j> | line | line<C-j> |
>
> |-------------------+---------+-----------+------+-----------+------+-----------+-----------+-----------+------+-----------|
> | t,t               |       n |         1 | n    | 1         | n-4  | 1
>      |   n+2*2,1 |         1 |    n |         1 |
> | t,headline-data   | n,nbl,1 |         1 | n+2  | 1         | n-2  | 1
>      |         1 |         1 |    1 |         1 |
> | t,nil             |       1 |         1 | n+2  | 1         | n-2  | 1
>      |   n+2*2,1 |         1 |    n |         1 |
> | nil,t             |       1 |         n | 1    | n+2 [t-2] | 1    | n-2
> [t+2] |         1 |   n+2*2,1 |    1 |         n |
> | nil,headline-data |       1 |   n,nbl,1 | 1    | n+2 [t-2] | 1    | n-2
> [t+2] |         1 |         1 |    1 |         1 |
> | nil,nil           |       1 |         1 | 1    | n+2 [t-2] | 1    | n-2
> [t+2] |         1 |   n+2*2,1 |    1 |         n |
>


-- 
regards,

Tim

--
Tim Cross

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

Re: Changed list indentation behavior: how to revert?

[Greg Minshall]

Tim,

thanks.

my tests were in a src block inside the main buffer.  like you, i
normally edit in an Org Src... buffer.  but, it's nice when it basically
"works" even in the main buffer (for minor edits, etc.).

and, yes, setting org-adapt-indentation to either 'headline-data or nil
seems likely to make many of us that much happier.

cheers, Greg

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Kyle Meyer <kyle@kyleam.com> writes:
> So, it seems that changing Org to honor electric-indent-mode is now
> making some users aware of org-adapt-indentation and that its default
> value is not what they want.

I’ve seen before that increasing the depth of a headline with M-→
indents all its content. That was mildly annoying, but nothing to worry
about.

It’s the change to the behavior of RET that disturbs my writing flow.
Now I always have to hit RET twice, or hit RET C-a to start typing.

It’s not just about the default, it is about long-standing muscle memory
suddenly being wrong. This breaks my workflow on an update and requires
me to start digging to find out how to get my system back into a good
state.

That’s something which makes me nervous, because I often don’t have the
time or energy to investigate when something breaks, so when that
workflow is broken, I’m bound to operate on a broken workflow for
anything from days to months, because I cannot estimate how much time
will be required to fix it (and at work I should not just take 3 hours
off to search for some configuration value).

Best wishes,
Arne

PS: I started to donate to org-mode a few weeks ago when I realized just
    how central it is to my workflows. If it’s the same for you, please
    join up: https://liberapay.com/bzg
    Creating reliable funding for development of essential Free Software
    tools is one of the critical tasks for spreading Free Software.
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Dr. Arne Babenhauserheide <arne_bab@web.de> writes:

> Kyle Meyer <kyle@kyleam.com> writes:
>> So, it seems that changing Org to honor electric-indent-mode is now
>> making some users aware of org-adapt-indentation and that its default
>> value is not what they want.
>
> I’ve seen before that increasing the depth of a headline with M-→
> indents all its content. That was mildly annoying, but nothing to worry
> about.
>
> It’s the change to the behavior of RET that disturbs my writing flow.
> Now I always have to hit RET twice, or hit RET C-a to start typing.
>
> It’s not just about the default, it is about long-standing muscle memory
> suddenly being wrong. This breaks my workflow on an update and requires
> me to start digging to find out how to get my system back into a good
> state.
>
> That’s something which makes me nervous, because I often don’t have the
> time or energy to investigate when something breaks, so when that
> workflow is broken, I’m bound to operate on a broken workflow for
> anything from days to months, because I cannot estimate how much time
> will be required to fix it (and at work I should not just take 3 hours
> off to search for some configuration value).
>

Hi Arne,

I can completely understand your position. However, I wanted to point
out that this change was documented in the org NEWS file, where all
version changes are documented. When upgrading to a new version of org,
everyone should look there, ideally before the upgrade or soon
afterwards and definitely when you notice some changed behaviour. It
will save hours of trouble shooting and often tells you how to restore
previous behaviour. A very under appreciated piece of valuable
documentation.

Tim


--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Tim Cross <theophilusx@gmail.com> writes:
> I can completely understand your position. However, I wanted to point
> out that this change was documented in the org NEWS file, where all
> version changes are documented. When upgrading to a new version of org,
> everyone should look there, ideally before the upgrade or soon
> afterwards and definitely when you notice some changed behaviour. It
> will save hours of trouble shooting and often tells you how to restore
> previous behaviour. A very under appreciated piece of valuable
> documentation.

I would like to agree, because I wish people would also read NEWS for my
projects, but since I use at least 10-20 programs daily which depend on
hundreds of libraries that might change their behavior, that’s
unrealistic.

I cannot read NEWS entries whenever my distro updates org-mode,
therefore I depend on org-mode not breaking during updates.

If an update changes behavior in a way that requires people to read up
on stuff to find out how to continue working, that means that the
program breaks with that update.

I’ve been more liberal on that point before I saw the problems that
arose from the Python2->Python3 transition. Many changes that each seem
small on their own can cause significant damage, because there will
always be some people that get hit by them during a period in their life
when they cannot follow them, because they are fully occupied by work
(mentally or because of little time) so the tools they trained with must
just keep working.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

Would it help if major releases maintained a mini-config that if added
to init.el would allow users to retain old behavior? That way they
wouldn't have to read the NEWS but could just add the relevant lines,
or maybe even just call the org-old-default-behavior-9.1 or
org-old-default-behavior-9.4. The workflow during development would be
to account for any change to defaults in those functions. Thoughts?
Tom

Re: Changed list indentation behavior: how to revert?

[gyro funch]

On 11/16/2020 9:26 AM, Tom Gillespie wrote:
> Would it help if major releases maintained a mini-config that if added
> to init.el would allow users to retain old behavior? That way they
> wouldn't have to read the NEWS but could just add the relevant lines,
> or maybe even just call the org-old-default-behavior-9.1 or
> org-old-default-behavior-9.4. The workflow during development would be
> to account for any change to defaults in those functions. Thoughts?
> Tom
> 
> 

I hate to open a new can of worms, but could semantic versioning be used
such that it is obvious when there are changes that are not backwards
compatible?

-gyro

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

Semver is unlikely to help because the question is what is "broken" by
a change in version. Semver would likely be about breaking changes to
internal org apis, not changes to default behavior that affect users,
so you have two different "semantics" which put us right back where we
are now -- to know what really changed you have to read the NEWS.
Bastien has also talked about hear-ye versioning, which says when a
version changes users need to read the news. Best,
Tom


On Mon, Nov 16, 2020 at 1:15 PM gyro funch <gyromagnetic@gmail.com> wrote:
>
> On 11/16/2020 9:26 AM, Tom Gillespie wrote:
> > Would it help if major releases maintained a mini-config that if added
> > to init.el would allow users to retain old behavior? That way they
> > wouldn't have to read the NEWS but could just add the relevant lines,
> > or maybe even just call the org-old-default-behavior-9.1 or
> > org-old-default-behavior-9.4. The workflow during development would be
> > to account for any change to defaults in those functions. Thoughts?
> > Tom
> >
> >
>
> I hate to open a new can of worms, but could semantic versioning be used
> such that it is obvious when there are changes that are not backwards
> compatible?
>
> -gyro
>
>

Re: Changed list indentation behavior: how to revert?

[Bill Burdick]

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

Ugh, I update my emacs package pretty infrequently and I usually have 30 or
more packages updating at a time -- I can't see wading through 30 NEWS
files searching for landmines...


-- Bill


On Mon, Nov 16, 2020 at 9:10 PM Tom Gillespie <tgbugs@gmail.com> wrote:

> Semver is unlikely to help because the question is what is "broken" by
> a change in version. Semver would likely be about breaking changes to
> internal org apis, not changes to default behavior that affect users,
> so you have two different "semantics" which put us right back where we
> are now -- to know what really changed you have to read the NEWS.
> Bastien has also talked about hear-ye versioning, which says when a
> version changes users need to read the news. Best,
> Tom
>
>
> On Mon, Nov 16, 2020 at 1:15 PM gyro funch <gyromagnetic@gmail.com> wrote:
> >
> > On 11/16/2020 9:26 AM, Tom Gillespie wrote:
> > > Would it help if major releases maintained a mini-config that if added
> > > to init.el would allow users to retain old behavior? That way they
> > > wouldn't have to read the NEWS but could just add the relevant lines,
> > > or maybe even just call the org-old-default-behavior-9.1 or
> > > org-old-default-behavior-9.4. The workflow during development would be
> > > to account for any change to defaults in those functions. Thoughts?
> > > Tom
> > >
> > >
> >
> > I hate to open a new can of worms, but could semantic versioning be used
> > such that it is obvious when there are changes that are not backwards
> > compatible?
> >
> > -gyro
> >
> >
>
>

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

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

Right there with you. My primary org file has a section filled with
rage when some default gets changed in org or some other part of
Emacs. The vast majority of the time the underlying change was in the
NEWS. Since there is already a habit of updating the NEWS it doesn't
seem unreasonable to put all those changes somewhere in an elisp file
that could restore old default behavior.

On Mon, Nov 16, 2020 at 2:41 PM Bill Burdick <bill.burdick@gmail.com> wrote:
>
> Ugh, I update my emacs package pretty infrequently and I usually have 30 or more packages updating at a time -- I can't see wading through 30 NEWS files searching for landmines...
>
>
> -- Bill
>
>
> On Mon, Nov 16, 2020 at 9:10 PM Tom Gillespie <tgbugs@gmail.com> wrote:
>>
>> Semver is unlikely to help because the question is what is "broken" by
>> a change in version. Semver would likely be about breaking changes to
>> internal org apis, not changes to default behavior that affect users,
>> so you have two different "semantics" which put us right back where we
>> are now -- to know what really changed you have to read the NEWS.
>> Bastien has also talked about hear-ye versioning, which says when a
>> version changes users need to read the news. Best,
>> Tom
>>
>>
>> On Mon, Nov 16, 2020 at 1:15 PM gyro funch <gyromagnetic@gmail.com> wrote:
>> >
>> > On 11/16/2020 9:26 AM, Tom Gillespie wrote:
>> > > Would it help if major releases maintained a mini-config that if added
>> > > to init.el would allow users to retain old behavior? That way they
>> > > wouldn't have to read the NEWS but could just add the relevant lines,
>> > > or maybe even just call the org-old-default-behavior-9.1 or
>> > > org-old-default-behavior-9.4. The workflow during development would be
>> > > to account for any change to defaults in those functions. Thoughts?
>> > > Tom
>> > >
>> > >
>> >
>> > I hate to open a new can of worms, but could semantic versioning be used
>> > such that it is obvious when there are changes that are not backwards
>> > compatible?
>> >
>> > -gyro
>> >
>> >
>>

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Bill Burdick <bill.burdick@gmail.com> writes:

> Ugh, I update my emacs package pretty infrequently and I usually have 30 or
> more packages updating at a time -- I can't see wading through 30 NEWS
> files searching for landmines...
>

Yes, this I think is a problem. Most of those packages probably only
have minor changes and bug fixes. We really need some way to be able to
sort or grade those packages based on whether they are minor or major
upgrades. Some sort of metric which would let you gauge the amount of
change and decide if checking the NEWS file would be advisable.

--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

> > Ugh, I update my emacs package pretty infrequently and I usually have 30 or
> > more packages updating at a time -- I can't see wading through 30 NEWS
> > files searching for landmines...
> >
>
> Yes, this I think is a problem. Most of those packages probably only
> have minor changes and bug fixes. We really need some way to be able to
> sort or grade those packages based on whether they are minor or major
> upgrades. Some sort of metric which would let you gauge the amount of
> change and decide if checking the NEWS file would be advisable.

An aside.

This is one of the reasons that I generally oppose breaking up repositories
into smaller projects. Some users want more frequent updates to some
parts of a codebase, but they are usually outliers. The end result is that
splitting the repo pushes more and more work onto the users, most of
whom receive no benefit since they are not bleeding edgers, because
now it is up to them to determine compatibility, read the NEWS, etc.

Sometimes deeper coupling can actually help. For example in this
thread if Emacs and Org were more tightly coupled in their releases
then the changes to electric indent mode might not have gone through
at all, or might have been delayed until Org could coordinate the change
so that users only had to deal with it once.

Do we actually want Org and Emacs development to be more coupled?
Probably not, but I suspect there is a systematic bias on the part of
more frequent participants to want greater decoupling because they are
often engaged in the development process and thus have a skewed
perspective on what is important --- namely to make development easier.

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Tom Gillespie <tgbugs@gmail.com> writes:

> Semver is unlikely to help because the question is what is "broken" by
> a change in version. Semver would likely be about breaking changes to
> internal org apis, not changes to default behavior that affect users,
> so you have two different "semantics" which put us right back where we
> are now -- to know what really changed you have to read the NEWS.
> Bastien has also talked about hear-ye versioning, which says when a
> version changes users need to read the news. Best,
> Tom
>

The 'hard' part of me says that if you upgrade org to a new major
version, don't read the NEWS file and are then surprised by changes, you
get what you deserve. Perhaps a tad too hard, but I do think users need
to take more responsibility here. At the same time, I do think there are
some things we could do to help them.

I've mentioned in another message that the way MELPA and other
repositories report versions is not helpful. All I get from the package
names now is that a new version has arrived and the date it was
released. There is no indication whether the new version is just bug
fixes, new functionality or a major new version. I only know this by
following this list.

What can we do to encourage users to read the NEWS file? Would it be
feasible to add code so that the first time someone opens an org file
after a major version upgrade the NEWS file is displayed? Would it be
useful to document ways of pinning package versions or implementing
package rollback functionality?
--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[gyro funch]

On 11/16/2020 9:26 AM, Tom Gillespie wrote:
> Would it help if major releases maintained a mini-config that if added
> to init.el would allow users to retain old behavior? That way they
> wouldn't have to read the NEWS but could just add the relevant lines,
> or maybe even just call the org-old-default-behavior-9.1 or
> org-old-default-behavior-9.4. The workflow during development would be
> to account for any change to defaults in those functions. Thoughts?
> Tom
> 
> 

I hate to open a new can of worms, but could semantic versioning be used
such that it is obvious when there are changes that are not backwards
compatible?

-gyro

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Tom Gillespie <tgbugs@gmail.com> writes:

> Would it help if major releases maintained a mini-config that if added
> to init.el would allow users to retain old behavior? That way they
> wouldn't have to read the NEWS but could just add the relevant lines,
> or maybe even just call the org-old-default-behavior-9.1 or
> org-old-default-behavior-9.4. The workflow during development would be
> to account for any change to defaults in those functions. Thoughts?
> Tom

If people don't have time to read the NEWS file, I also doubt they would
be aware of the mini config file or have the time to add it to their
setup. There would be an additional burden on developers to maintain the
mini-config which might not actually result in any real benefit. I would
also be concerned this might setup an expectation which is difficult to
meet. It may not always be straight-forward to provide such a
mini-config and sometimes, it may actually be in the best interests of
the user to force a change on them because it brings other benefits that
outweigh the initial 'change pain'.

I do wonder if Org would benefit from adopting semantic versioning? This
could provide a way to convey more information to the user in the
version number e.g x.y.z => MAJOR.MINOR.PATCH where

- PATCH = bug fix only. No changes to API or interface
- MINOR = extensions (additions) to API or interface, but no change to
          existing API and interface
- MAJOR = breaking change - either API or interface has changed

In general, my experience has been that the org developers have worked
hard to keep things stable in a very complex environment. The challenge
is when there is a breaking change, how to effectively communicate this
and minimise surprises for the user and how to accurately gauge the
impact from a change.

At the same time, us users also need to take on some of the
responsibility and recognise that major version upgrades may break or
change their workflow. If you have a situation where stability of your
environment is critical to your work and your strapped for time so that
any change will be unacceptably disruptive, you need to adopt an upgrade
workflow which mitigates that risk. For example, my workflow allows me
to roll back any package which I upgrade. If I upgrade a package and it
breaks things and I don't have time to troubleshoot, I can roll it back.
Some distributions also include this feature. This is one area where I
feel the ELPA system could be improved. Right now, if you use the
org-plus-contrib package (or the org package) from either the org or
melpa package, it reports as something like org-plus-contrib-20201118,
which tells me very little apart from there is an update. I cannot tell
from this name if it is a major, minor or bug fix update. Not a big deal
for me as I can always roll back, but not everyone has that ability.

Change is inevitable and if we focus too much on not changing existing
behaviour or API, we run the risk of overly constraining development.
Communication of change is a challenge, but critically important. I feel
we would get the most benefit by focusing on how to communicate breaking
changes effectively and ensure when such change is introduced, as far as
possible, details on how to restore the previous behaviour are provided.


--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Bill Burdick]

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

Heh, I had time to read EMACS NEWS when I used it in 1985 (and still do for
new EMACS versions). Now there are soooo many packages, each with their own
news...


-- Bill


On Mon, Nov 16, 2020 at 10:59 PM Tim Cross <theophilusx@gmail.com> wrote:

>
> Tom Gillespie <tgbugs@gmail.com> writes:
>
> > Would it help if major releases maintained a mini-config that if added
> > to init.el would allow users to retain old behavior? That way they
> > wouldn't have to read the NEWS but could just add the relevant lines,
> > or maybe even just call the org-old-default-behavior-9.1 or
> > org-old-default-behavior-9.4. The workflow during development would be
> > to account for any change to defaults in those functions. Thoughts?
> > Tom
>
> If people don't have time to read the NEWS file, I also doubt they would
> be aware of the mini config file or have the time to add it to their
> setup. There would be an additional burden on developers to maintain the
> mini-config which might not actually result in any real benefit. I would
> also be concerned this might setup an expectation which is difficult to
> meet. It may not always be straight-forward to provide such a
> mini-config and sometimes, it may actually be in the best interests of
> the user to force a change on them because it brings other benefits that
> outweigh the initial 'change pain'.
>
> I do wonder if Org would benefit from adopting semantic versioning? This
> could provide a way to convey more information to the user in the
> version number e.g x.y.z => MAJOR.MINOR.PATCH where
>
> - PATCH = bug fix only. No changes to API or interface
> - MINOR = extensions (additions) to API or interface, but no change to
>           existing API and interface
> - MAJOR = breaking change - either API or interface has changed
>
> In general, my experience has been that the org developers have worked
> hard to keep things stable in a very complex environment. The challenge
> is when there is a breaking change, how to effectively communicate this
> and minimise surprises for the user and how to accurately gauge the
> impact from a change.
>
> At the same time, us users also need to take on some of the
> responsibility and recognise that major version upgrades may break or
> change their workflow. If you have a situation where stability of your
> environment is critical to your work and your strapped for time so that
> any change will be unacceptably disruptive, you need to adopt an upgrade
> workflow which mitigates that risk. For example, my workflow allows me
> to roll back any package which I upgrade. If I upgrade a package and it
> breaks things and I don't have time to troubleshoot, I can roll it back.
> Some distributions also include this feature. This is one area where I
> feel the ELPA system could be improved. Right now, if you use the
> org-plus-contrib package (or the org package) from either the org or
> melpa package, it reports as something like org-plus-contrib-20201118,
> which tells me very little apart from there is an update. I cannot tell
> from this name if it is a major, minor or bug fix update. Not a big deal
> for me as I can always roll back, but not everyone has that ability.
>
> Change is inevitable and if we focus too much on not changing existing
> behaviour or API, we run the risk of overly constraining development.
> Communication of change is a challenge, but critically important. I feel
> we would get the most benefit by focusing on how to communicate breaking
> changes effectively and ensure when such change is introduced, as far as
> possible, details on how to restore the previous behaviour are provided.
>
>
> --
> Tim Cross
>
>

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

Re: Changed list indentation behavior: how to revert?

[Tom Gillespie]

> If people don't have time to read the NEWS file, I also doubt they would
> be aware of the mini config file or have the time to add it to their
> setup. There would be an additional burden on developers to maintain the
> mini-config which might not actually result in any real benefit. I would
> also be concerned this might setup an expectation which is difficult to
> meet. It may not always be straight-forward to provide such a
> mini-config and sometimes, it may actually be in the best interests of
> the user to force a change on them because it brings other benefits that
> outweigh the initial 'change pain'.

Clearly this would not work for all types of changes. However there are
numerous cases where a variable is changed from t to nil or similar where
such functionality would be straightforward to implement and might be
able to cover 80% of these kinds of issues.

It should be entirely possible to teach users that as part of their upgrade
process there is an option that they can set or command they can invoke
which will automatically make changes to their config to preserve old
default behavior. M-x org-post-update-restore-old-defaults or something.

There are also intermediate changes such as the addition of the :extend
keyword for faces which was given a default value that changed existing
behavior by defaulting to nil instead of t. This kind of change is a
combination of useful, annoying, and hard to fix without reading the
NEWS if it is something that breaks your workflow. Emacs is usually
pretty good about avoiding these kinds of major changes in behavior
but sometimes the slip through and sometimes a change does need
to be made and the best time to do so is as soon as possible.

I suspect that this might be an area where org could benefit from more
extensive testing coverage. There was a change between 9.1 and 9.3 that
completely broke org babel edit src functionality because it did not
correctly restore the window layout on exit. Now we just need to find
people willing to write the tests in addition to notifying the mailing list :D.

Best,
Tom

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Tim Cross <theophilusx@gmail.com> writes:

> At the same time, us users also need to take on some of the
> responsibility and recognise that major version upgrades may break or
> change their workflow. If you have a situation where stability of your
> environment is critical to your work and your strapped for time so that
> any change will be unacceptably disruptive, you need to adopt an upgrade
> workflow which mitigates that risk.

I had that on an OLPC where I had everything working and avoided any
changes that weren’t necessary, because I used it for writing. It was
perfect. There was a catch, though: It used a custom kernel and the
config did not work with newer versions. And I did not manage to change
that with some 20 hours of trying. But that did not hurt me, I had my
emacs and could play music for writing and roleplaying games.

Then the config for the new Emacs version on the desktop and the version
on the OLPC became incompatible, so I upgraded the OLPC to be able to
transfer the changes (I needed them so I could use the config in the
repository to be able to run the exporter for the writing — I also had a
full texlive on there). That was right around the time udev got
introduced as mandatory dependency. And that needed a newer kernel to
avoid breaking the audio.

I have not been able to restore sound output to the OLPC in the past
half decade. And all ways I tried to fix the problem — including other
distros — failed in some ways.

Sad story short: Having to update is a fact of life. Stuff that breaks
                 on update is a liability. Most of the times org-mode
                 has been pretty good at it, but the few breakages it
                 had did actually cost me quite some time (one example
                 is that lecture-slides did not export cleanly anymore
                 after the exporter updates).

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Stefan Nobis]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> Sad story short:...

I'm with you - last weekend I upgrade my OS and had quite some trouble
to get everything working again and still have some nasty hoops to
jump through.

But on the other side: What are we talking about?

Org had a given default configuration for quite some time. To be
clear: THIS DID NOT CHANGE!

But some people are upset now. Why? Because the emergent behaviour
changed. Not the underlying default configuration, but in the context
and details of how each individual uses Org for some users the default
configuration was emergent and evident, but some other users did not
perceive this default configuration.

Now a simple setting, syncing Org with the defaults of Emacs and other
modes with respect to RET and electric-indent-mode, make the OLD,
UNCHANGED default configuration emergent for almost all users.

These are very subtle effects inside a very complex environment.

How should maintainers be able to foresee all possible environments
and use cases and the resulting emergent behaviour?

I'm really surprised that such a simple and insignificant breaking
change results in such a uproar. If a new Org version make all old
files completely unusable or a bunch of important features is totally
broken, say nothing of babel works anymore - yes, is such a case I
would understand the uproar.

But ranting so loudly and insistent and continuously over such a minor
details is really beyond me.

And nobody has to read all NEWS and Changelogs for every single peace
of software they are using. If nothing breaks maybe there is nothing
to worry about. If some minor detail like the new emergent indentation
behaviour annoys you - just have a quick look in the NEWS file of the
new version. Is this really that hard?

On the other hand: What's the alternative? Never change anything
again? Maybe some users rely on the emergent behaviour of some bad
bug (that has bad consequences for some other users). Should it never
be changed, because it may annoy some users and they could be forced
to read the NEWS file?

You cannot have the cookie and eat it!

So, everyone, please calm down and try not to overreact over really
simple, negligible details.

-- 
Until the next mail...,
Stefan.

Re: Changed list indentation behavior: how to revert?

[Loris Bennett]

Stefan Nobis <stefan-ml@snobis.de> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> Sad story short:...
>
> I'm with you - last weekend I upgrade my OS and had quite some trouble
> to get everything working again and still have some nasty hoops to
> jump through.
>
> But on the other side: What are we talking about?
>
> Org had a given default configuration for quite some time. To be
> clear: THIS DID NOT CHANGE!
>
> But some people are upset now. Why? Because the emergent behaviour
> changed. Not the underlying default configuration, but in the context
> and details of how each individual uses Org for some users the default
> configuration was emergent and evident, but some other users did not
> perceive this default configuration.
>
> Now a simple setting, syncing Org with the defaults of Emacs and other
> modes with respect to RET and electric-indent-mode, make the OLD,
> UNCHANGED default configuration emergent for almost all users.
>
> These are very subtle effects inside a very complex environment.
>
> How should maintainers be able to foresee all possible environments
> and use cases and the resulting emergent behaviour?
>
> I'm really surprised that such a simple and insignificant breaking
> change results in such a uproar. If a new Org version make all old
> files completely unusable or a bunch of important features is totally
> broken, say nothing of babel works anymore - yes, is such a case I
> would understand the uproar.
>
> But ranting so loudly and insistent and continuously over such a minor
> details is really beyond me.
>
> And nobody has to read all NEWS and Changelogs for every single peace
> of software they are using. If nothing breaks maybe there is nothing
> to worry about. If some minor detail like the new emergent indentation
> behaviour annoys you - just have a quick look in the NEWS file of the
> new version. Is this really that hard?
>
> On the other hand: What's the alternative? Never change anything
> again? Maybe some users rely on the emergent behaviour of some bad
> bug (that has bad consequences for some other users). Should it never
> be changed, because it may annoy some users and they could be forced
> to read the NEWS file?
>
> You cannot have the cookie and eat it!
>
> So, everyone, please calm down and try not to overreact over really
> simple, negligible details.

To quote Randall Munroe:

"Every change breaks someone's workflow"[1]

Footnotes: 
[1]  https://xkcd.com/1172/

-- 
This signature is currently under construction.

Re: Changed list indentation behavior: how to revert?

[Diego Zamboni]

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

On Tue, Nov 17, 2020 at 10:06 AM Stefan Nobis <stefan-ml@snobis.de> wrote:

> But on the other side: What are we talking about?
> ...
> But ranting so loudly and insistent and continuously over such a minor
> details is really beyond me.
> ...
> So, everyone, please calm down and try not to overreact over really
> simple, negligible details.
>

+1000000 - nicely put Stefan. This extremely long thread really puzzles me.

--Diego

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

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Stefan Nobis <stefan-ml@snobis.de> writes:

> "Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:
>
>> Sad story short:...
>
> I'm with you - last weekend I upgrade my OS and had quite some trouble
> to get everything working again and still have some nasty hoops to
> jump through.
>
> But on the other side: …
…
> I'm really surprised that such a simple and insignificant breaking
> change results in such a uproar.

I have seen no uproar here. Discussions here were friendly and
constructive. The discusssions are long, because there aren’t easy
solutions to managing changes in UX in central places.

And a significant share of the discussion was about the question whether
the new interaction is better or worse and whether this actually is
insignificant.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Robert Pluim]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> I have seen no uproar here. Discussions here were friendly and
> constructive. The discusssions are long, because there aren’t easy
> solutions to managing changes in UX in central places.
>
> And a significant share of the discussion was about the question whether
> the new interaction is better or worse and whether this actually is
> insignificant.

Iʼll add my 0.02€ and say that I donʼt know if this change affected
me, since Iʼm lazy enough that I always do C-RET to start a new
headline, as it frees me from having to worry about the number of
stars to add.

Robert

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Tom Gillespie <tgbugs@gmail.com> writes:

> Would it help if major releases maintained a mini-config that if added
> to init.el would allow users to retain old behavior? That way they
> wouldn't have to read the NEWS but could just add the relevant lines,
> or maybe even just call the org-old-default-behavior-9.1 or
> org-old-default-behavior-9.4. The workflow during development would be
> to account for any change to defaults in those functions. Thoughts?
> Tom

This would ease the pain temporarily but not fix the problem.

The next time you sit down with a colleague to show org-mode you’ll be
searching in your config for the change to go back to the old default.

The problem is that you have to do stuff after an update to undo
breakage. This is a conservative stance — I have gotten more
conservative in what I want from my software over the years. I want to
learn tools that just keep working because I can only become really good
in those. It’s only there that investing much time into learning them
actually pays off.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Tim Cross]

Dr. Arne Babenhauserheide <arne_bab@web.de> writes:

> Tim Cross <theophilusx@gmail.com> writes:
>> I can completely understand your position. However, I wanted to point
>> out that this change was documented in the org NEWS file, where all
>> version changes are documented. When upgrading to a new version of org,
>> everyone should look there, ideally before the upgrade or soon
>> afterwards and definitely when you notice some changed behaviour. It
>> will save hours of trouble shooting and often tells you how to restore
>> previous behaviour. A very under appreciated piece of valuable
>> documentation.
>
> I would like to agree, because I wish people would also read NEWS for my
> projects, but since I use at least 10-20 programs daily which depend on
> hundreds of libraries that might change their behavior, that’s
> unrealistic.
>
> I cannot read NEWS entries whenever my distro updates org-mode,
> therefore I depend on org-mode not breaking during updates.
>
> If an update changes behavior in a way that requires people to read up
> on stuff to find out how to continue working, that means that the
> program breaks with that update.
>
> I’ve been more liberal on that point before I saw the problems that
> arose from the Python2->Python3 transition. Many changes that each seem
> small on their own can cause significant damage, because there will
> always be some people that get hit by them during a period in their life
> when they cannot follow them, because they are fully occupied by work
> (mentally or because of little time) so the tools they trained with must
> just keep working.
>

I understand where your coming from, but feel you are over stating the
problem. The Python version change is an extreme example. The
maintainers of Python made the decision that such a fundamental change
was critically important for the long-term viability of the language and
there was no way to implement that change which was not going to be
extremely disruptive. I don't know enough about the internals of Python
to have an opinion on whether it was a good or bad decision.

There are only two mechanisms by which org-mode is upgraded and as far
as I know, both require that the user either initiates the update or
turns on automatic updates. Your argument would be more compelling for
me if we were talking about updates which occur without user
intervention or control.

Org is only updated if you update your OS distribution to a new major
version and the version of Emacs is updated (or you manually update
Emacs) or you use the MELPA or org repositories and request an upgrade.
The ELPA system also includes the ability to 'pin' a package to a
specific version to prevent upgrades.

Change is inevitable and such changes will from time to time, break
things. If stability in an environment is the priority, then it is up to
the user who maintains that environment to manage things in such a way
as to preserve that stability. Developers of tools and libraries cannot
bare that responsibility because they cannot accurately assess how
change will impact all users in all environments. Their responsibility
is to effectively communicate what has changed to enable the
user/maintainer to make the appropriate decisions regarding what to
upgrade and when and to not introduce arbitrary changes that are not
justified. To expect things to never change is unrealistic.

With respect to the current issue about line indentation. I think the
key question here is was communication of this change sufficient and if
not, what can be done to make such communication more effective. It
would seem, for whatever reason, few people read the NEWS file, so
perhaps other mechanisms need to be introduced. I have mentioned in
another message that semantic versioning might be one way to help users
manage updates, but I'm sure there are other and likely more effective
ideas out there that could help. Perhaps some documentation on what
people can do to improve stability in their environments e.g. pinning
ELPA packages to specific versions, implementing package rollback
functionality, etc.

Tim

--
Tim Cross

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Tim Cross <theophilusx@gmail.com> writes:
> There are only two mechanisms by which org-mode is upgraded and as far
> as I know, both require that the user either initiates the update or
> turns on automatic updates. Your argument would be more compelling for
> me if we were talking about updates which occur without user
> intervention or control.

In my case org is updated automatically. I use rolling release distros.
There’s never a time when I say “now I get all the new versions, let’s
look for breakage”.

> Change is inevitable and such changes will from time to time, break
> things.

Is breakage truly inevitable? Do fundamentals of org have to change?

If some small detail changes in a convoluted setup I have, that’s
something I can cope with.

That there are packages that almost never break and packages that almost
always break on update, but little in-between sounds like most breakage
isn’t inevitable.

Here’s the source for the statement:
https://stevelosh.com/blog/2012/04/volatile-software/

It makes my point much more succintly:
------ ------ ------ ------ ------ ------
When I'm updating a piece of software there's a good chance it's not
because I'm specifically updating that program. I might be:

- Moving to a new computer.
- Running a "$PACKAGE_MANAGER update" command.
- Moving a website to a bigger VPS and reinstalling all the libraries.

In those cases (and many others) I'm not reading the release notes for a
specific program or library. I'm not going to find out about the
brokenness until I try to use the program the next time.
------ ------ ------ ------ ------ ------ 

and a second point:

------ ------ ------ ------ ------ ------ 
This may just be an artifact of how my brain is wired, but I actually
get a sense of satisfaction from writing code that bridges the gap
between older versions and new.

I can almost hear a little voice in my head saying:

    "Mwahaha, I'll slip this refactoring past them and they'll never
    even know it happened!"

Maybe it's just me, but I think that "glue" code can be clever and
beautiful in its own right.

It may not bring a smile to anyone's face like a shiny new feature, but
it prevents many frowns instead, and preventing a frown makes the world
a happier place just as much as creating a smile!
------ ------ ------ ------ ------ ------ 

> With respect to the current issue about line indentation. I think the
> key question here is was communication of this change sufficient and if
> not, what can be done to make such communication more effective.

It cannot be made effective enough. If you make it effective enough, the
other gazillion packages on the system will use the same mechanism and
that will make it ineffective again.

The only way that works is to avoid breakage on update — except for the
few cases where it is truly unavoidable.

We have the discussion here, because many people disagree with the
notion that the current breakage was unavoidable.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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

Re: Changed list indentation behavior: how to revert?

[Detlef Steuer]

Am Tue, 17 Nov 2020 01:11:38 +0100
schrieb "Dr. Arne Babenhauserheide" <arne_bab@web.de>:

> The only way that works is to avoid breakage on update — except for
> the few cases where it is truly unavoidable.

Well, and as long as the change can be reverted when the community
has a thoughtful discussion with those who did the work, the world is
wonderful. Even if the devels insist they did the right thing, but the 
discussion brought up way to mitigate the fallout, all is fine. 

I even get the feeling of being part of a great community through
this very discussion! So ...civilized. A warm fire in the wild net.

It is *impossible* to force users to be informed. Think about us: We
all hang around on this list and missed the information. What would
reasonably be expected from a casual user? Often it is not even clear
what the consequences are, even if you read the NEWS. "Org now uses
electric-indent" only is meaningful to very few people who can guess
what that will mean for their workflow. 

It *seems* impossible to me to be backward compatible forever via code
snippets or any other mechanism. You can maybe skip one or two update
cycles, but then it will be like pinning a specific git version. One
can do that already, but it should not increase
the burden of the devels. If those don't have fun anymore, we are lost
:-)

So we have to live with a breakage from time to time, I guess, but org
has very few of those. And it always comes out of these breakages
better!

Detlef

Re: Changed list indentation behavior: how to revert?

[Jean Louis]

* Detlef Steuer <steuer@hsu-hh.de> [2020-11-17 11:47]:
:PROPERTIES:
:CREATED:  [2020-11-17 Tue 12:41]
:ID:       2bc18302-d009-4751-b062-b3cf2aa44d18
:END:
> It is *impossible* to force users to be informed. Think about us: We
> all hang around on this list and missed the information. What would
> reasonably be expected from a casual user? Often it is not even clear
> what the consequences are, even if you read the NEWS. "Org now uses
> electric-indent" only is meaningful to very few people who can guess
> what that will mean for their workflow.

News in Org mode is already very prominent, but I never read it. It is
in the Org Menu documentation sub menu that leads to the website. But
I would say it is much better having NEWS locally as not everybody has
Internet with Org mode.

News for specific user should refer to changes from previous version
of that user. Not every user will have same Org version. They will not
understand news if it refers to higher version which they may not
have. Org is distributed over many communication channels together
with Emacs. Users of many GNU/Linux distributions and FreeBSD and
other BSD derivatives are getting it packaged, there are many
different versions.

NEWS could be made more prominent by adding NEWS links to Org Info
file. I could not find any. So it is not hyperlinks. Logically the Org
documentation should link to Org news and hereby I do not mean to link
to the website but to link to the relevant news pertaining to specific
version of Org, and such file should be together with the Org distribution.

It is on my side in:
/package/text/emacs-2020-11-14/share/emacs/28.0.50/etc/ORG-NEWS

But does ANYTHING within Org mode points there to that file? I do not
think user will find the relevant news.

How is user to find the reference if reference is not given?

I am using Emacs development version from 2020-11-14, 3 days ago. The
ORG-NEWS is explaining about Org version 9.3 as that is what I wish to
read as I am on that version (probably).

Org menu, submenu Documentation is pointing to Browse News that is
showing me Org news for version 9.4. That is not consistent as version
9.3 should not show me news for version 9.4.

But then if I look into newer Org package installed I can even see
news for version 9.5 and it says there "not yet released".

From my personal view point this is all fine. I am speaking from
interface design and consistency.

The link from Org menu could maybe point to the specific local file
ORG-NEWS for the specific version installed. That way users on version
9.2 would see news for version 9.2. Those for version 9.3 see for 9.3
and so on. It makes things consistent.

Users on this mailing list are power users. There are thousands of
users who may not have neither power nor Internet to install new
packages or update packages. They get it delivered through Emacs and
use Emacs on the multi user system.

Emacs is part of GNU system. That means somebody as administrator
installs the OS and OS is used for example in multi user
environment. Such environment need not have Internet access neither
would install new versions of Org as the version of Emacs from GNU
Linux distribution "just works". We have to think of all those users
and design should drive itself for developers or power users only.

Emacs version on GNU Hyperbola/Linux-libre is 25.3-3.hyperbola2 and I
do not know which Org version is inside. This version I have installed
in multi user environment. Why should a staff member using that
version, which is functional, be looking into news pertaining to
version 9.4 on the website which does not relate to version on the
system? It is not consistent. And such member would not be even able
to see the news on the website because computer is not connected to
Internet.

NEWS could be made more prominent to system administrators who install
the package by placing some notices in commentary of the package, or
where exactly? When I install the package or in package description
there could be link to the news or notice that NEWS shall be read.

Re: Changed list indentation behavior: how to revert?

[Maxim Nikulin]

2020-11-16 Dr. Arne Babenhauserheide wrote:
> 
> I would like to agree, because I wish people would also read NEWS for my
> projects, but since I use at least 10-20 programs daily which depend on
> hundreds of libraries that might change their behavior, that’s
> unrealistic.
> 
> I cannot read NEWS entries whenever my distro updates org-mode,
> therefore I depend on org-mode not breaking during updates.

The problem is partially with absence of convenient interface for 
reviewing of updates. E.g. apt-listchanges from debian extracts news 
(major changes) or both news and debian changelog entries from 
downloaded packages before installing them. Similar GUI from ubuntu is 
less convenient due to it fetches changes after selecting particular 
entry causing delays and grouping of packages built from the same source 
works not well enough.

P.S. Maybe I missed that, but it seems org-indent-mode (#+STARTUP: 
indent) has not mentioned in this long thread.

There is a footnote in the manual related to hard indentation:

This works, but requires extra effort. Org Indent mode is more 
convenient for most applications.

Re: Changed list indentation behavior: how to revert?

[Uwe Brauer]

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


> PS: I started to donate to org-mode a few weeks ago when I realized just
>     how central it is to my workflows. If it’s the same for you, please
>     join up: https://liberapay.com/bzg
>     Creating reliable funding for development of essential Free Software
>     tools is one of the critical tasks for spreading Free Software.

Done. You are right!

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5673 bytes --]

Re: Changed list indentation behavior: how to revert?

[Dr. Arne Babenhauserheide]

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


Uwe Brauer <oub@mat.ucm.es> writes:

>> PS: I started to donate to org-mode a few weeks ago when I realized just
>>     how central it is to my workflows. If it’s the same for you, please
>>     join up: https://liberapay.com/bzg
>>     Creating reliable funding for development of essential Free Software
>>     tools is one of the critical tasks for spreading Free Software.
>
> Done. You are right!

\o/

:-)

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

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