Questioning the new behavior of `open-line'.

Questioning the new behavior of `open-line'.

[Karl Fogel]

Recently, `open-line' has started behaving in a new way due to Arthur Malabarba's recent commits [1].  Here is how `open-line' behaves before and after the changes.

Suppose you have this text in a buffer, in just about any mode (i.e., not necessarily a programming language mode), and it is indented by two spaces as below:

  A lovely haiku
  An example for this bug
  For Emacs Devel

Now place point where the imaginary "X" is below and do C-o (`open-line'):

X A lovely haiku
  An example for this bug
  For Emacs Devel

Formerly, that would literally insert a newline, but not remove the the two spaces of indendation that come *after* the new newline (the two spaces right before "A lovely haiku").  So this would be the result:

[...this is the new line; imagine it's blank...]
  A lovely haiku
  An example for this bug
  For Emacs Devel

But after the recent commits, those two spaces are removed:

[...this is the new line; imagine it's blank...]
A lovely haiku
  An example for this bug
  For Emacs Devel

So now one can no longer just put point in column 0 and type C-o to open a line right before a block of indented text while preserving the block's indentation.

This is just a result of `electric-indent-mode' being on by default and `open-line' now being sensitive to `electric-indent-mode', I think.  But one of the things I always thought was good about `open-line' was that it *wasn't* sensitive that way -- that you could just put point in a column of your choice and insert a newline, and everything to the right of that column would be preserved after the newline.

Arthur was well aware of this change, and even asked about it in his first post in the thread "A few questions about open-line" [2]:

> 3. I think, when electric-indent-mode is on, open-line should indent
> the line that was created below if it isn't empty. May I go ahead?

Had I seen that question at the time, I would have answered "Oh, please don't" :-).  But maybe mine is a minority opinion?  I encounter the new behavior several times a day, and don't like it; turning off `electric-indent-mode' seems like a drastic solution.  But if people generally like this new behavior, I'll certainly live with being in the minority and figure out the appropritae local customization.

So do we think this new behavior is the right one?

(If it stays, then I'll add an item to NEWS about it.)

Best regards,
-Karl

[1] These two commits (note you have to take them together, as the earlier one accidentally leaves open-line in a syntactically invalid state, and the later one corrects that):

  commit bd4f04f86cea893e3369decdda074a4898491518
  Author: Artur Malabarba <bruce.connor.am@gmail.com>
  Date:   Sat Oct 24 22:26:27 2015 +0100
  
      * lisp/simple.el (open-line): Integrate with electric-indent-mode
      
      Also run `post-self-insert-hook' when called interactively.
  
  M	lisp/simple.el
  
  commit 6939896e2ffe2e742954c14bba6129af456f0857
  Author: Artur Malabarba <bruce.connor.am@gmail.com>
  Date:   Sat Oct 24 22:24:09 2015 +0100
  
      * lisp/simple.el (open-line): Fix docstring
      
      Also explain apparently redundant line.
  
  M	lisp/simple.el

[2] https://lists.gnu.org/archive/html/emacs-devel/2015-10/threads.html#02107

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Karl Fogel <kfogel@red-bean.com> writes:

>> 3. I think, when electric-indent-mode is on, open-line should indent the
>> line that was created below if it isn't empty. May I go ahead?

> Had I seen that question at the time, I would have answered "Oh, please
> don't" :-). But maybe mine is a minority opinion? I encounter the new
> behavior several times a day, and don't like it; turning off
> `electric-indent-mode' seems like a drastic solution. But if people
> generally like this new behavior, I'll certainly live with being in the
> minority and figure out the appropritae local customization.

I too would want the original C-o behavior. If you're using it an column 0,
then the action of C-o is to create a new line, not to adjust indentation of
the line you were on before the command.

Now, you *could* have the new behavior using `electric-indent-functions',
checking if the current command is `open-line'. So we're not making it
impossible to do. But we shouldn't change long-standing behavior like this, in
a subtle way that many users wouldn't know how to undo.

John

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

John Wiegley <jwiegley@gmail.com> writes:
>>>>>> Karl Fogel <kfogel@red-bean.com> writes:
>
>>> 3. I think, when electric-indent-mode is on, open-line should indent the
>>> line that was created below if it isn't empty. May I go ahead?
>
>> Had I seen that question at the time, I would have answered "Oh, please
>> don't" :-). But maybe mine is a minority opinion? I encounter the new
>> behavior several times a day, and don't like it; turning off
>> `electric-indent-mode' seems like a drastic solution. But if people
>> generally like this new behavior, I'll certainly live with being in the
>> minority and figure out the appropritae local customization.
>
>I too would want the original C-o behavior. If you're using it an column 0,
>then the action of C-o is to create a new line, not to adjust indentation of
>the line you were on before the command.
>
>Now, you *could* have the new behavior using `electric-indent-functions',
>checking if the current command is `open-line'. So we're not making it
>impossible to do. But we shouldn't change long-standing behavior like this, in
>a subtle way that many users wouldn't know how to undo.

Yeah, my feelings too.  If `electric-indent-mode' does anything here, it should move point to the appropriate indentation column *on the new, blank line*, while leaving existing text however it was.

Best,
-K

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Date: Wed, 11 Nov 2015 12:58:15 -0600
> Cc: Artur Malabarba <bruce.connor.am@gmail.com>
> 
> John Wiegley <jwiegley@gmail.com> writes:
> >>>>>> Karl Fogel <kfogel@red-bean.com> writes:
> >
> >>> 3. I think, when electric-indent-mode is on, open-line should indent the
> >>> line that was created below if it isn't empty. May I go ahead?
> >
> >> Had I seen that question at the time, I would have answered "Oh, please
> >> don't" :-). But maybe mine is a minority opinion? I encounter the new
> >> behavior several times a day, and don't like it; turning off
> >> `electric-indent-mode' seems like a drastic solution. But if people
> >> generally like this new behavior, I'll certainly live with being in the
> >> minority and figure out the appropritae local customization.
> >
> >I too would want the original C-o behavior. If you're using it an column 0,
> >then the action of C-o is to create a new line, not to adjust indentation of
> >the line you were on before the command.
> >
> >Now, you *could* have the new behavior using `electric-indent-functions',
> >checking if the current command is `open-line'. So we're not making it
> >impossible to do. But we shouldn't change long-standing behavior like this, in
> >a subtle way that many users wouldn't know how to undo.
> 
> Yeah, my feelings too.  If `electric-indent-mode' does anything here, it should move point to the appropriate indentation column *on the new, blank line*, while leaving existing text however it was.

People who don't like electric-indent-mode can just turn it off, can't
they?  Why argue about defaults when they can be so easily changed?

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> People who don't like electric-indent-mode can just turn it off, can't they?
> Why argue about defaults when they can be so easily changed?

This is more about people who want to use electric-indent-mode, but don't want
it changing previous defaults in a way that doesn't seem to be related to
electric-indent-mode.

I can imagine a new user experiencing this and having no clue that
electric-indent-mode is the reason: Because it is enabled by default for them
in 25.1 -- they never consciously turned it on to notice the difference in
behavior -- so they wouldn't know it's coming from that source.

Why is something like this being enabled by default, again? Or did I misread?
I would expect any kind of automated behavior like this to be opt-in.

John

Re: Questioning the new behavior of `open-line'.

[Paul Eggert]

Eli Zaretskii wrote:
> People who don't like electric-indent-mode can just turn it off, can't
> they?  Why argue about defaults when they can be so easily changed?

I think we're discussing the default behavior when electric-indent-mode is on, 
which it often is by default.

I too was taken aback and annoyed by the new behavior of C-o.  For example, I 
visited src/lisp.h and typed this:

C-s xnmalloc C-a C-o

The resulting buffer looked like this:

   extern void *xrealloc (void *, size_t) ATTRIBUTE_ALLOC_SIZE ((2));
   extern void xfree (void *);
   X
                                 extern void *xnmalloc (ptrdiff_t, ptrdiff_t) 
ATTRIBUTE_MALLOC_SIZE ((1,2));
   extern void *xnrealloc (void *, ptrdiff_t, ptrdiff_t)
     ATTRIBUTE_ALLOC_SIZE ((2,3));

(where the cursor is marked with "X"), i.e., the "xnmalloc" line was greatly 
indented, which is not what I wanted.  With old Emacs it would look like this:

   extern void *xrealloc (void *, size_t) ATTRIBUTE_ALLOC_SIZE ((2));
   extern void xfree (void *);
   X
   extern void *xnmalloc (ptrdiff_t, ptrdiff_t) ATTRIBUTE_MALLOC_SIZE ((1,2));
   extern void *xnrealloc (void *, ptrdiff_t, ptrdiff_t)
     ATTRIBUTE_ALLOC_SIZE ((2,3));

which is what I wanted: a new blank line with the cursor at the start, and with 
no change to the next line.

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Paul Eggert <eggert@cs.ucla.edu> writes:

> which is what I wanted: a new blank line with the cursor at the start, and
> with no change to the next line.

I often use C-o and C-j exactly because I *know* they'll never auto-indent
anything, in buffers where I do use that sort of behavior. They are pretty
reliable at doing nothing but what they suggest.

The one case where this is when C-o inserts a fill-prefix, which I find rather
annoying, even.

John

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

John Wiegley <jwiegley@gmail.com> writes:
> Eli Zaretskii <eliz@gnu.org> writes:
>> People who don't like electric-indent-mode can just turn it off, can't they?
>> Why argue about defaults when they can be so easily changed?
>
>This is more about people who want to use electric-indent-mode, but don't want
>it changing previous defaults in a way that doesn't seem to be related to
>electric-indent-mode.
>
>I can imagine a new user experiencing this and having no clue that
>electric-indent-mode is the reason: Because it is enabled by default for them
>in 25.1 -- they never consciously turned it on to notice the difference in
>behavior -- so they wouldn't know it's coming from that source.

That's exactly what happened to me, yes.

>Why is something like this being enabled by default, again? Or did I misread?
>I would expect any kind of automated behavior like this to be opt-in.

You didn't misread -- the new behavior is (currently) the default.  I'm proposing we revert to the old behavior.

Even people who use electric indent all the time would probably be surprised by the new default behavior.  And there's no real advantage to this new default, since one can achieve the same effect just by putting point in column 0 before running `open-line'.

So Eli, I think what John said is right: this isn't about `electric-indent-mode'.  It's about `open-line', and a new behavior of `open-line' that isn't what most users would expect even if they are conscious of & like `electric-indent-mode'.

Best regards,
-Karl

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: Karl Fogel <kfogel@red-bean.com>
> Cc: bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2015 13:39:11 -0600
> 
> John Wiegley <jwiegley@gmail.com> writes:
> > Eli Zaretskii <eliz@gnu.org> writes:
> >> People who don't like electric-indent-mode can just turn it off, can't they?
> >> Why argue about defaults when they can be so easily changed?
> >
> >This is more about people who want to use electric-indent-mode, but don't want
> >it changing previous defaults in a way that doesn't seem to be related to
> >electric-indent-mode.
> >
> >I can imagine a new user experiencing this and having no clue that
> >electric-indent-mode is the reason: Because it is enabled by default for them
> >in 25.1 -- they never consciously turned it on to notice the difference in
> >behavior -- so they wouldn't know it's coming from that source.
> 
> That's exactly what happened to me, yes.
> 
> >Why is something like this being enabled by default, again? Or did I misread?
> >I would expect any kind of automated behavior like this to be opt-in.
> 
> You didn't misread -- the new behavior is (currently) the default.  I'm proposing we revert to the old behavior.

Which old behavior?  The old behavior was that electric-indent-mode
was not turned on by default.  Is that what you mean?

> Even people who use electric indent all the time would probably be surprised by the new default behavior.  And there's no real advantage to this new default, since one can achieve the same effect just by putting point in column 0 before running `open-line'.
> 
> So Eli, I think what John said is right: this isn't about `electric-indent-mode'.  It's about `open-line', and a new behavior of `open-line' that isn't what most users would expect even if they are conscious of & like `electric-indent-mode'.

Maybe I'm missing something, but I think this behavior doesn't happen
when electric-indent-mode is off, which it was in previous versions of
Emacs.  Isn't that true?

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> Cc: bruce.connor.am@gmail.com, emacs-devel@gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Wed, 11 Nov 2015 11:20:58 -0800
> 
> Eli Zaretskii wrote:
> > People who don't like electric-indent-mode can just turn it off, can't
> > they?  Why argue about defaults when they can be so easily changed?
> 
> I think we're discussing the default behavior when electric-indent-mode is on, 
> which it often is by default.

Yes, and I'm saying turn it off if you don't like it.

We had endless discussions of these and other similar effects, back
when electric-indent-mode was made the default.  I'd rather not go
through all those discussions again.  Just turn it off in your .emacs
and live happily ever after.

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Karl Fogel <kfogel@red-bean.com>,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2015 11:13:34 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > People who don't like electric-indent-mode can just turn it off, can't they?
> > Why argue about defaults when they can be so easily changed?
> 
> This is more about people who want to use electric-indent-mode, but don't want
> it changing previous defaults in a way that doesn't seem to be related to
> electric-indent-mode.

Having the cake and eating it, too?  I'd love that!  But it isn't
always possible.

> I can imagine a new user experiencing this and having no clue that
> electric-indent-mode is the reason: Because it is enabled by default for them
> in 25.1 -- they never consciously turned it on to notice the difference in
> behavior -- so they wouldn't know it's coming from that source.

New users don't have past experience with Emacs, so they won't know
there's something here that wasn't so before.

> Why is something like this being enabled by default, again? Or did I misread?
> I would expect any kind of automated behavior like this to be opt-in.

You are welcome to re-reading the past discussions about
electric-indent-mode.  Good luck keeping your sanity while at that ;-)

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> Maybe I'm missing something, but I think this behavior doesn't happen when
> electric-indent-mode is off, which it was in previous versions of Emacs.
> Isn't that true?

Correct. We have several things in play here:

  1. When electric-indent-mode is off, everything is fine.

  2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.

  3. We should fix C-o when electric-indent-mode is on, so its behavior is not
     affected by electric-indent-mode.

  4. We should disable electric-indent-mode by default.

Since I wasn't present for the discussion when electric-indent-mode was
enabled by default, I'd like to reopen that discussion with regard to 25.1.
Probably on a separate thread from this one.

John

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

> You are welcome to re-reading the past discussions about
> electric-indent-mode.  Good luck keeping your sanity while at that ;-)

Looking at electric-indent-mode, the defaults are actually quite sane: The
only thing that engages electric indentation by default is insertion of a
newline. The user can also manually engage it using C-j.

I'm all for this, since swapping the meaning of C-m and C-j is something I
used to have to do in nearly every mode I use. I never understood why hitting
return in a programming mode should always take me to column 0. However, C-o
at column 0 is something many of us have come to depend on.

One way to fix this is to set a default for `electric-indent-functions' that
pays attention to this particular scenario, and suppresses electric indent in
that case. This leaves it open to users to customize away the suppression.

This keeps the electric default, and C-o-at-0 users are not surprised. Does
that sound reasonable?

John

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

John Wiegley <jwiegley@gmail.com> writes:
>Correct. We have several things in play here:
>
>  1. When electric-indent-mode is off, everything is fine.
>
>  2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.
>
>  3. We should fix C-o when electric-indent-mode is on, so its behavior is not
>     affected by electric-indent-mode.

I was only arguing for (3), FWIW.  I have no opinion on whether electric-indent-mode should be on or off by default.  When it is on, however, I don't think it should affect open-line's behavior anyway.  The old open-line behavior is a better way for open-line to behave, and a less surprising behavior, even when electric-indent-mode is on.

Was this specific effect on `open-line' even contemplated in the prior discussion about turning on electric-indent-mode by default?  I didn't follow that thread, but unless the topic was specifically raised, I don't think that "electric-indent-mode is now the default" equates to "open-line should have this new behavior".

Let me put it this way: if electric-indent-mode being *off* were still the default, and someone changed open-line to be sensitive to electric-indent-mode in this way, I'd still raise the same question: should open-line behave this way when electric-indent-mode is on?

So electric-indent-mode being on or off *by default* is unrelated to the open-line question.  The question is, should open-line behave in this new way when electric-indent-mode is on?  (And I think the answer is "no".)

>  4. We should disable electric-indent-mode by default.
>
> Since I wasn't present for the discussion when electric-indent-mode
> was enabled by default, I'd like to reopen that discussion with regard
> to 25.1.  Probably on a separate thread from this one.

Neither for nor against, personally, but agree it is a separate thread anyway.

Best,
-Karl

Re: Questioning the new behavior of `open-line'.

[Alan Mackenzie]

Hello, John.

On Wed, Nov 11, 2015 at 12:17:44PM -0800, John Wiegley wrote:
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:

> > Maybe I'm missing something, but I think this behavior doesn't happen when
> > electric-indent-mode is off, which it was in previous versions of Emacs.
> > Isn't that true?

> Correct. We have several things in play here:

>   1. When electric-indent-mode is off, everything is fine.

>   2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.

>   3. We should fix C-o when electric-indent-mode is on, so its behavior is not
>      affected by electric-indent-mode.

Agreed.

>   4. We should disable electric-indent-mode by default.

> Since I wasn't present for the discussion when electric-indent-mode was
> enabled by default, I'd like to reopen that discussion with regard to 25.1.

Just a tip from somebody who was involved in that discussion - you might
come to regret that wish.  Could I suggest you pore over the archives
before reopening this discussion?

My feeling was and is that enabling e-i-m was the right decision, even
though I was unhappy about certain aspects of it.  I'm not sure I want
to enlarge on that.

> Probably on a separate thread from this one.

> John

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: Karl Fogel <kfogel@red-bean.com>,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2015 12:17:44 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Maybe I'm missing something, but I think this behavior doesn't happen when
> > electric-indent-mode is off, which it was in previous versions of Emacs.
> > Isn't that true?
> 
> Correct. We have several things in play here:
> 
>   1. When electric-indent-mode is off, everything is fine.
> 
>   2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.

Then what is it that electric-indent-mode gives you that prevents you
personally from turning it off?

> Since I wasn't present for the discussion when electric-indent-mode was
> enabled by default, I'd like to reopen that discussion with regard to 25.1.
> Probably on a separate thread from this one.

Please read the past discussions about that, before you decide to
start another one.  If you still think it's a good idea after you've
read that, I guess we will, but at least we could then try to avoid
saying again what has been already beaten to death.

Personally, I find arguments about Emacs defaults one of the most
futile kind of arguments.  They tend to drag on and on, when all you
need to do to solve the problem is a few lines in your ~/.emacs, many
times just one line.  But that's me.

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: kfogel@red-bean.com,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2015 12:28:05 -0800
> 
> > You are welcome to re-reading the past discussions about
> > electric-indent-mode.  Good luck keeping your sanity while at that ;-)
> 
> Looking at electric-indent-mode, the defaults are actually quite sane: The
> only thing that engages electric indentation by default is insertion of a
> newline. The user can also manually engage it using C-j.

It looks sane, yes, but it has some surprising consequences.  E.g.,
this:

   http://debbugs.gnu.org/cgi/bugreport.cgi?bug=19093

> One way to fix this is to set a default for `electric-indent-functions' that
> pays attention to this particular scenario, and suppresses electric indent in
> that case. This leaves it open to users to customize away the suppression.
> 
> This keeps the electric default, and C-o-at-0 users are not surprised. Does
> that sound reasonable?

To me, nothing about electric-indent-mode is reasonable.  I don't mind
swapping C-m and C-j, if that's what will keep me sane.  If
electric-indent-mode did just that, perhaps I'd be fine with it.

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

>> 2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.
> Then what is it that electric-indent-mode gives you that prevents you
> personally from turning it off?

I want electric-indent-mode; I don't want C-o at column zero to be affected by
it. I think that by default, it shouldn't be affected by it either. See my
proposed solution in another e-mail.

John

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:

> To me, nothing about electric-indent-mode is reasonable. I don't mind
> swapping C-m and C-j, if that's what will keep me sane. If
> electric-indent-mode did just that, perhaps I'd be fine with it.

Out of interest, who has a passionate feeling that it should be the default?
If very few think so, perhaps we can disable it and revisit that decision
after 25.1 is out. I don't want to wade through past history unless it is
really important to several people that it be in the next release.

John

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

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

On Wed, Nov 11, 2015 at 2:58 PM, John Wiegley <jwiegley@gmail.com> wrote:

> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> 2. When electric-indent-mode is on, C-o behaves in an unexpected
> fashion.
> > Then what is it that electric-indent-mode gives you that prevents you
> > personally from turning it off?
>
> I want electric-indent-mode; I don't want C-o at column zero to be
> affected by
> it. I think that by default, it shouldn't be affected by it either. See my
> proposed solution in another e-mail.
>

So electric-indent-mode would still affect open-line, but not when
open-line is run with point at column zero.

Hmm.  I think that's a good solution.  I think that's pretty much the
entire use case here.  (I'd also be happy with open-line just having *no*
electric indent behaviors, but that's a more complex discussion and
probably wouldn't affect many use cases anyway.)

Emacs is famous for making the right exceptions to otherwise consistent
behaviors (the behavior of C-t at the end of a line is often held up as a
classic example of this).  This would be another instance of that, I
guess.

I'll happily make the change, but will wait to see if there's some
consensus.

-K



>
> John
>

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

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Karl Fogel <kfogel@red-bean.com> writes:

> I'll happily make the change, but will wait to see if there's some
> consensus.

Could you open a bug to track this, so we don't forget? It should be addressed
in the release, if electric-indent-mode is indeed to be on by default.

John

Re: Questioning the new behavior of `open-line'.

[Eli Zaretskii]

> From: John Wiegley <jwiegley@gmail.com>
> Cc: kfogel@red-bean.com,  bruce.connor.am@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 11 Nov 2015 13:00:44 -0800
> 
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > To me, nothing about electric-indent-mode is reasonable. I don't mind
> > swapping C-m and C-j, if that's what will keep me sane. If
> > electric-indent-mode did just that, perhaps I'd be fine with it.
> 
> Out of interest, who has a passionate feeling that it should be the default?

Sorry, I happily forgot.

Re: Questioning the new behavior of `open-line'.

[Alan Mackenzie]

Hello, John.

On Wed, Nov 11, 2015 at 01:00:44PM -0800, John Wiegley wrote:
> >>>>> Eli Zaretskii <eliz@gnu.org> writes:

> > To me, nothing about electric-indent-mode is reasonable. I don't mind
> > swapping C-m and C-j, if that's what will keep me sane. If
> > electric-indent-mode did just that, perhaps I'd be fine with it.

> Out of interest, who has a passionate feeling that it should be the default?

I think my feeling is more that the default shouldn't be changed.  It
would confuse and upset our users.

I also have an interest in CC Mode's electric indentation remaining
enabled by default (as it has been, literally, for decades), and since CC
Mode's EI has become entangled with Emacs's e-i-m, I can foresee pain.

> If very few think so, perhaps we can disable it and revisit that decision
> after 25.1 is out. I don't want to wade through past history unless it is
> really important to several people that it be in the next release.

If you were just an Emacs user, and a feature was enabled by default at
24.3, then disabled at 25.1, then re-enabled at 25.2, what would you
think?

> John

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Alan Mackenzie <acm@muc.de> writes:

> If you were just an Emacs user, and a feature was enabled by default at
> 24.3, then disabled at 25.1, then re-enabled at 25.2, what would you think?

Ah, never mind, this was enabled as the default in 24.4. I don't want to touch
it if it's already gone out the door. There are other battles to win.

John

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:

> I’ll fix your “C-o at start of line” problem right away, but, if noone
> opposes, I’d like to maintain the current behaviour when typing C-o in the
> middle of a line. Is that alright?

Sounds good to me.

John

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

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

On Nov 11, 2015 3:36 PM, "John Wiegley" <jwiegley@gmail.com> wrote:
>
> >>>>> Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
> > I’ll fix your “C-o at start of line” problem right away, but, if noone
> > opposes, I’d like to maintain the current behaviour when typing C-o in
the
> > middle of a line. Is that alright?
>
> Sounds good to me.

+1 here too.  You make the fix, Artur, and I'll be happy to add the note to
etc/NEWS (unless you beat me to it).

Best regards,
-K

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

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

Karl Fogel <kfogel@red-bean.com> writes:

> Arthur was well aware of this change, and even asked about it in his
> first post in the thread "A few questions about open-line" [2]:
>
>> 3. I think, when electric-indent-mode is on, open-line should indent
>> the line that was created below if it isn't empty. May I go ahead?
>
> Had I seen that question at the time, I would have answered "Oh,
> please don't" :-).  But maybe mine is a minority opinion?

Let's find out.  I'm with you on that one.  To me it defeats a major
point of C-o which, to me, is a tool similar to C-q C-j, namely used
exactly in situations where you want to sidestep any intelligence.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

John Wiegley <jwiegley@gmail.com> writes:

>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>
>> Maybe I'm missing something, but I think this behavior doesn't happen when
>> electric-indent-mode is off, which it was in previous versions of Emacs.
>> Isn't that true?
>
> Correct. We have several things in play here:
>
>   1. When electric-indent-mode is off, everything is fine.
>
>   2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.
>
>   3. We should fix C-o when electric-indent-mode is on, so its behavior is not
>      affected by electric-indent-mode.
>
>   4. We should disable electric-indent-mode by default.
>
> Since I wasn't present for the discussion when electric-indent-mode was
> enabled by default, I'd like to reopen that discussion with regard to 25.1.
> Probably on a separate thread from this one.

I'm reasonably fine with electric-indent-mode by default I think.  But
_exactly_ when electric-indent-mode is on, the need for a dumb C-o is
largest for me.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

Karl Fogel <kfogel@red-bean.com> writes:

> On Wed, Nov 11, 2015 at 2:58 PM, John Wiegley <jwiegley@gmail.com> wrote:
>
>> >>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> >> 2. When electric-indent-mode is on, C-o behaves in an unexpected
>> fashion.
>> > Then what is it that electric-indent-mode gives you that prevents you
>> > personally from turning it off?
>>
>> I want electric-indent-mode; I don't want C-o at column zero to be
>> affected by
>> it. I think that by default, it shouldn't be affected by it either. See my
>> proposed solution in another e-mail.
>>
>
> So electric-indent-mode would still affect open-line, but not when
> open-line is run with point at column zero.

Personally I want the dumb C-o regardless of the current column.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

I'm a little suprised at how quickly such a simple topic developed 4
whole branches (by counting on my mail client). :-)

Karl Fogel <kfogel@red-bean.com> writes:

> Recently, `open-line' has started behaving in a new way due to Arthur
> Malabarba's recent commits [1].  Here is how `open-line' behaves
> before and after the changes.
> [...]
> So now one can no longer just put point in column 0 and type C-o to
> open a line right before a block of indented text while preserving the
> block's indentation.

Thanks for bringing this up, Karl.
It was an accident. My goal was to fix C-o in the middle of a line. I
didn't realise I was breaking its behaviour at the start of a line.

For instance, take your example, and hit C-o with point at the first
‘h’. With the previous behaviour, you would get this (assuming
‘electric-indent-mode’ is on):

  A lovely
haiku
  An example for this bug
  For Emacs Devel

With the current “fix”, you get this (which I think is the right way).

  A lovely
  haiku
  An example for this bug
  For Emacs Devel

I’ll fix your “C-o at start of line” problem right away, but, if noone
opposes, I’d like to maintain the current behaviour when typing C-o in
the middle of a line.
Is that alright?

> (If it stays, then I'll add an item to NEWS about it.)

I would be very grateful for that. :-)

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

John Wiegley <jwiegley@gmail.com> writes:

> Out of interest, who has a passionate feeling that it should be the default?

I do.

I can summarize why later, if desired. But I’d _really_ rather
not, because I know it’ll start up one of those discussions that doesn’t
go anywhere.

Re: Questioning the new behavior of `open-line'.

[Rasmus]

David Kastrup <dak@gnu.org> writes:

> John Wiegley <jwiegley@gmail.com> writes:
>
>>>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> Maybe I'm missing something, but I think this behavior doesn't happen when
>>> electric-indent-mode is off, which it was in previous versions of Emacs.
>>> Isn't that true?
>>
>> Correct. We have several things in play here:
>>
>>   1. When electric-indent-mode is off, everything is fine.
>>
>>   2. When electric-indent-mode is on, C-o behaves in an unexpected fashion.
>>
>>   3. We should fix C-o when electric-indent-mode is on, so its behavior is not
>>      affected by electric-indent-mode.
>>
>>   4. We should disable electric-indent-mode by default.
>>
>> Since I wasn't present for the discussion when electric-indent-mode was
>> enabled by default, I'd like to reopen that discussion with regard to 25.1.
>> Probably on a separate thread from this one.
>
> I'm reasonably fine with electric-indent-mode by default I think.  But
> _exactly_ when electric-indent-mode is on, the need for a dumb C-o is
> largest for me.

I share this sentiment.  I love most of the electricity and it should be
on by default IMHO.

But the change to C-o is for the worse.  It should be "dumb" also at
columns greater than zero.

Rasmus

-- 
Warning: Everything saved will be lost

Re: Questioning the new behavior of `open-line'.

[Andreas Röhler]

  On 11.11.2015 19:08, Karl Fogel wrote:
> Recently, `open-line' has started behaving in a new way due to Arthur Malabarba's recent commits [1].  Here is how `open-line' behaves before and after the changes.
>
> Suppose you have this text in a buffer, in just about any mode (i.e., not necessarily a programming language mode), and it is indented by two spaces as below:
>
>    A lovely haiku
>    An example for this bug
>    For Emacs Devel
>
> Now place point where the imaginary "X" is below and do C-o (`open-line'):
>
> X A lovely haiku
>    An example for this bug
>    For Emacs Devel
>
> Formerly, that would literally insert a newline, but not remove the the two spaces of indendation that come *after* the new newline (the two spaces right before "A lovely haiku").  So this would be the result:
>
> [...this is the new line; imagine it's blank...]
>    A lovely haiku
>    An example for this bug
>    For Emacs Devel
>
> But after the recent commits, those two spaces are removed:
>
> [...this is the new line; imagine it's blank...]
> A lovely haiku
>    An example for this bug
>    For Emacs Devel
>
> So now one can no longer just put point in column 0 and type C-o to open a line right before a block of indented text while preserving the block's indentation.
>
> This is just a result of `electric-indent-mode' being on by default and `open-line' now being sensitive to `electric-indent-mode', I think.  But one of the things I always thought was good about `open-line' was that it *wasn't* sensitive that way -- that you could just put point in a column of your choice and insert a newline, and everything to the right of that column would be preserved after the newline.
>
> Arthur was well aware of this change, and even asked about it in his first post in the thread "A few questions about open-line" [2]:
>
>> 3. I think, when electric-indent-mode is on, open-line should indent
>> the line that was created below if it isn't empty. May I go ahead?
> Had I seen that question at the time, I would have answered "Oh, please don't" :-).  But maybe mine is a minority opinion?  I encounter the new behavior several times a day, and don't like it; turning off `electric-indent-mode' seems like a drastic solution.  But if people generally like this new behavior, I'll certainly live with being in the minority and figure out the appropritae local customization.
>
> So do we think this new behavior is the right one?
>
> (If it stays, then I'll add an item to NEWS about it.)
>
> Best regards,
> -Karl
>
> [1] These two commits (note you have to take them together, as the earlier one accidentally leaves open-line in a syntactically invalid state, and the later one corrects that):
>
>    commit bd4f04f86cea893e3369decdda074a4898491518
>    Author: Artur Malabarba<bruce.connor.am@gmail.com>
>    Date:   Sat Oct 24 22:26:27 2015 +0100
>
>        * lisp/simple.el (open-line): Integrate with electric-indent-mode
>
>        Also run `post-self-insert-hook' when called interactively.
>
>    M	lisp/simple.el
>
>    commit 6939896e2ffe2e742954c14bba6129af456f0857
>    Author: Artur Malabarba<bruce.connor.am@gmail.com>
>    Date:   Sat Oct 24 22:24:09 2015 +0100
>
>        * lisp/simple.el (open-line): Fix docstring
>
>        Also explain apparently redundant line.
>
>    M	lisp/simple.el
>
> [2] https://lists.gnu.org/archive/html/emacs-devel/2015-10/threads.html#02107
>

When registering with joy Emacs now takes course towards a test-backed 
development, may we have a change here too?

I.e, establishing a policy saying core-functions shouldn't be changed 
without prior notice/discussion?

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

John Wiegley <jwiegley@gmail.com> writes:
>>>>>> Karl Fogel <kfogel@red-bean.com> writes:
>
>> I'll happily make the change, but will wait to see if there's some
>> consensus.
>
>Could you open a bug to track this, so we don't forget? It should be addressed
>in the release, if electric-indent-mode is indeed to be on by default.

Sure: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21884

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

Rasmus <rasmus@gmx.us> writes:
>I share this sentiment.  I love most of the electricity and it should be
>on by default IMHO.
>
>But the change to C-o is for the worse.  It should be "dumb" also at
>columns greater than zero.

FWIW, sometimes I want that, as you and David do, and sometimes I don't.  It just depends on what I'm trying to do.  IMHO there's not an always-right answer in the non-column-zero case.

Did you see Artur's post [1] giving an example of how the non-dumb behavior can make sense in the non-column-zero case?  I found it pretty persuasive.  (Whereas in column zero, I *always* want the "dumb" behavior, 100% of the time -- and it seems that at least is a point of agreement for most people here.)

Best regards,
-Karl

[1] https://lists.gnu.org/archive/html/emacs-devel/2015-11/msg01100.html

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

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

On 12 Nov 2015 8:06 am, "Karl Fogel" <kfogel@red-bean.com> wrote:
>
> Rasmus <rasmus@gmx.us> writes:
> >I share this sentiment.  I love most of the electricity and it should be
> >on by default IMHO.
> >
> >But the change to C-o is for the worse.  It should be "dumb" also at
> >columns greater than zero.

Hi Rasmus and David.
Could you give an example (similar to what I did) illustrating why you
prefer the dumb behaviour on columns grater than 0?
i.e., when is it more convenient to break an indented line in half and have
the second half be unindented?

I'm willing to revert this change, but I'd really like to give a reasoning
on the commit message.

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

Re: Questioning the new behavior of `open-line'.

[Rasmus]

Hi Artur,

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> >I share this sentiment.  I love most of the electricity and it should be
>> >on by default IMHO.
>> >
>> >But the change to C-o is for the worse.  It should be "dumb" also at
>> >columns greater than zero.
>
> Hi Rasmus and David.
> Could you give an example (similar to what I did) illustrating why you
> prefer the dumb behaviour on columns grater than 0?
> i.e., when is it more convenient to break an indented line in half and have
> the second half be unindented?
>
> I'm willing to revert this change, but I'd really like to give a reasoning
> on the commit message.

For C-o I expect a newline to be inserted.  Nothing else.  If I want
indentation I already have RET.  If I want to return to point I have 
C-x C-x.

An example of when I use C-o is when I have to manually indent stuff,
e.g. if Emacs is not smart enough to do a good job /all of the time/.  A
case is d3.js code, where periods are typically aligned.

You may say that this is an example of separate bug (and indeed there
exists a bug report on JS mode alignment), but to the extend that
misbehaviors (even "subjective misbehaviors") exists, it’s very useful to
have dumb behavior available.  Here’s an example of d3.js.  I may want to
insert a new attribute before the width, without affecting the current
indentation.  I’d then use C-o.

    var svg = div.append("svg")
                 .attr("width", box_plot.w)
                 .attr("height", box_plot.h);

Rasmus

-- 
Need more coffee. . .

Re: Questioning the new behavior of `open-line'.

[Andreas Schwab]

Rasmus <rasmus@gmx.us> writes:

> You may say that this is an example of separate bug (and indeed there
> exists a bug report on JS mode alignment), but to the extend that
> misbehaviors (even "subjective misbehaviors") exists, it’s very useful to
> have dumb behavior available.  Here’s an example of d3.js.  I may want to
> insert a new attribute before the width, without affecting the current
> indentation.  I’d then use C-o.
>
>     var svg = div.append("svg")
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);

There is also C-M-o (split-line) which would keep the indentation intact.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

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

On 12 Nov 2015 11:08 am, "Rasmus" <rasmus@gmx.us> wrote:
> You may say that this is an example of separate bug, but to the extend
that
> misbehaviors exists, it’s very useful to
> have dumb behavior available.

I do agree. Would C-M-o or C-j C-b suffice in these situations?

> Here’s an example of d3.js.  I may want to
> insert a new attribute before the width, without affecting the current
> indentation.  I’d then use C-o.
>
>     var svg = div.append("svg")
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);

I'm sorry, I didn't understand. Could you explain (1) what you have before
typing C-o, (2) the location of the cursor, (3) what you want to see after
hitting C-o?

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

Re: Questioning the new behavior of `open-line'.

[Rasmus]

Hi Artur,

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> On 12 Nov 2015 11:08 am, "Rasmus" <rasmus@gmx.us> wrote:
>> You may say that this is an example of separate bug, but to the extend
>> that
>> misbehaviors exists, it’s very useful to
>> have dumb behavior available.
>
> I do agree. Would C-M-o or C-j C-b suffice in these situations?

Probably it.  C-M-o is slightly different, but perhaps it’s just a
question of getting used to it.  Truth be told, I was unaware of
split-line before this thread.


>> Here’s an example of d3.js.  I may want to
>> insert a new attribute before the width, without affecting the current
>> indentation.  I’d then use C-o.
>>
>>     var svg = div.append("svg")
>>                  .attr("width", box_plot.w)
>>                  .attr("height", box_plot.h);
>
> I'm sorry, I didn't understand. Could you explain (1) what you have before
> typing C-o, (2) the location of the cursor, (3) what you want to see after
> hitting C-o?

I realize that I would probably be mostly OK if special behavior is
adopted when point is a column zero.  I’m still not sure that M-o warrants
such complexity, but I don’t feel too strongly about it.

In any case, to address you question.

Picture 1; ’|’ is the cursor.

      var svg = div.append("svg")
      |            .attr("width", box_plot.w) 
                   .attr("height", box_plot.h);

      M-o result before

      var svg = div.append("svg")
      |
                   .attr("width", box_plot.w) 
                   .attr("height", box_plot.h);

      Now,

      var svg = div.append("svg")

          .attr("width", box_plot.w)
                   .attr("height", box_plot.h);


When wanting to push something down from within the line, results are poor
before and after patch

Picture 2; ’|’ is the cursor

    var svg = div.append("svg")|.classed("myclass", true)
                 .attr("width", box_plot.w)
                 .attr("height", box_plot.h);

    Before,

    var svg = div.append("svg")|
    .classed("myclass", true)
                 .attr("width", box_plot.w)
                 .attr("height", box_plot.h);


    Now,

    var svg = div.append("svg")|
        .classed("myclass", true)
                 .attr("width", box_plot.w)
                 .attr("height", box_plot.h);


Thanks,
Rasmus

-- 
⠠⠵

Re: Questioning the new behavior of `open-line'.

[Yuri Khan]

On Thu, Nov 12, 2015 at 8:16 PM, Rasmus <rasmus@gmx.us> wrote:

> Picture 1
>
>       var svg = div.append("svg")|
>
>           .attr("width", box_plot.w)
>                    .attr("height", box_plot.h);
>
> Picture 2
>
>     var svg = div.append("svg")|
>         .classed("myclass", true)
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);

Both cases demonstrate a bug caused by the lack of a suitable
Javascript indentation heuristic. Something along the lines of “_if_
the line starts with a dot _and_ the previous line ends with \(a
dot\), followed by an identifier, followed by balanced parentheses,
_and_ the previous line’s indentation does not contain any tab
characters, _then_ align to the position of \1”.

Arguably, they should be solved by adding that heuristic, not by
breaking open-line and/or newline-and-indent.

Re: Questioning the new behavior of `open-line'.

[Rasmus]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Thu, Nov 12, 2015 at 8:16 PM, Rasmus <rasmus@gmx.us> wrote:
>
>> Picture 1
>>
>>       var svg = div.append("svg")|
>>
>>           .attr("width", box_plot.w)
>>                    .attr("height", box_plot.h);
>>
>> Picture 2
>>
>>     var svg = div.append("svg")|
>>         .classed("myclass", true)
>>                  .attr("width", box_plot.w)
>>                  .attr("height", box_plot.h);
>
> Both cases demonstrate a bug caused by the lack of a suitable
> Javascript indentation heuristic. Something along the lines of “_if_
> the line starts with a dot _and_ the previous line ends with \(a
> dot\), followed by an identifier, followed by balanced parentheses,
> _and_ the previous line’s indentation does not contain any tab
> characters, _then_ align to the position of \1”.

Indeed, your observation corresponds to the disclaimer made when the
example was first raised.

> Arguably, they should be solved by adding that heuristic, not by
> breaking open-line and/or newline-and-indent.

Perhaps, until such a fix exists, to this and any similar problem, Emacs
can afford to offer "dumb" keys alongside indenting keys.

Rasmus

-- 
Warning: Everything saved will be lost

Re: Questioning the new behavior of `open-line'.

[Yuri Khan]

On Thu, Nov 12, 2015 at 8:52 PM, Rasmus <rasmus@gmx.us> wrote:
>> Arguably, they should be solved by adding that heuristic, not by
>> breaking open-line and/or newline-and-indent.
>
> Perhaps, until such a fix exists, to this and any similar problem, Emacs
> can afford to offer "dumb" keys alongside indenting keys.

Possibly, if Emacs offers “dumb” keys, no one will be sufficiently
annoyed to actually implement the fix.

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

Rasmus <rasmus@gmx.us> writes:

> Yuri Khan <yuri.v.khan@gmail.com> writes:
>
>> Arguably, they should be solved by adding that heuristic, not by
>> breaking open-line and/or newline-and-indent.
>
> Perhaps, until such a fix exists, to this and any similar problem,
> Emacs can afford to offer "dumb" keys alongside indenting keys.

In particular when using electric-indent-mode (whether or not it
defaults to on) there should be a minimal set of dumb keys for fixing
stuff manually.  C-q C-j is on the awkward side.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[Rasmus]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

>> I realize that I would probably be mostly OK if special behavior is
>> adopted when point is a column zero.  I’m still not sure that M-o warrants
>> such complexity, but I don’t feel too strongly about it.
>
> The complexity here is very manageable, and the function isn’t long.
> Besides, it’s a very frequently used command. It’s worth investing and
> extra 4 or 5 lines to make it more natural.

I was referring to the additional ’cognitive complexity’ given the
conditional behavior of M-o.  But it may indeed fall under DWIM.

Thanks for the effort, Artur.

Rasmus

-- 
Hvor meget poesi tror De kommer ud af et glas isvand?

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

Yuri Khan <yuri.v.khan@gmail.com> writes:

> On Thu, Nov 12, 2015 at 8:52 PM, Rasmus <rasmus@gmx.us> wrote:
>>> Arguably, they should be solved by adding that heuristic, not by
>>> breaking open-line and/or newline-and-indent.
>>
>> Perhaps, until such a fix exists, to this and any similar problem, Emacs
>> can afford to offer "dumb" keys alongside indenting keys.
>
> Possibly, if Emacs offers “dumb” keys, no one will be sufficiently
> annoyed to actually implement the fix.

Emacs will never be perfect in all respects, not least of all because
some indentations are motivated by aesthetic criteria and by judgment
calls on different criteria than Emacs uses.  To intentionally make it
annoying to work around bad decisions in order to make developers change
Emacs is just stupid because the fallout will hit first and foremost the
users rather than the developers even if we hypothesize that for every
code there is exactly one correct and desirable and machine-determinable
way to indent it.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

Rasmus <rasmus@gmx.us> writes:

> In any case, to address you question.
>
> Picture 1; ’|’ is the cursor.
>
>       var svg = div.append("svg")
>       |            .attr("width", box_plot.w) 
>                    .attr("height", box_plot.h);
>
>       M-o result before
>
>       var svg = div.append("svg")
>       |
>                    .attr("width", box_plot.w) 
>                    .attr("height", box_plot.h);
>
>       Now,
>
>       var svg = div.append("svg")
>
>           .attr("width", box_plot.w)
>                    .attr("height", box_plot.h);

Thank you, Rasmus, that's very helpful.
Indeed, what I plan to do now is revert to the old behaviour on col 0,
which should address this case as well as other cases mentioned here.
Regardless of anything else, I agree this is the right thing to do on
col 0.

> When wanting to push something down from within the line, results are poor
> before and after patch
>
> Picture 2; ’|’ is the cursor
>
>     var svg = div.append("svg")|.classed("myclass", true)
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);
>
>     Before,
>
>     var svg = div.append("svg")|
>     .classed("myclass", true)
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);
>
>
>     Now,
>
>     var svg = div.append("svg")|
>         .classed("myclass", true)
>                  .attr("width", box_plot.w)
>                  .attr("height", box_plot.h);

Thanks for this clarification too.

“C-o at the middle of the line” is what my patch was meant to address
(the above effect was an accident). In this situation, if the
indentation engine works correctly, the old behaviour is something I
don’t think would ever be useful. That’s what motivated the change.

When the indentation engine does not work correctly, then my patch
doesn’t make things better, but I guess it doesn’t make them worse
either.

> I realize that I would probably be mostly OK if special behavior is
> adopted when point is a column zero.  I’m still not sure that M-o warrants
> such complexity, but I don’t feel too strongly about it.

The complexity here is very manageable, and the function isn’t long.
Besides, it’s a very frequently used command. It’s worth investing and
extra 4 or 5 lines to make it more natural.

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

David Kastrup <dak@gnu.org> writes:
>Emacs will never be perfect in all respects, not least of all because
>some indentations are motivated by aesthetic criteria and by judgment
>calls on different criteria than Emacs uses.  To intentionally make it
>annoying to work around bad decisions in order to make developers change
>Emacs is just stupid because the fallout will hit first and foremost the
>users rather than the developers even if we hypothesize that for every
>code there is exactly one correct and desirable and machine-determinable
>way to indent it.

As a statement of general principle, that's certainly reasonable.

But in this situation, I don't think we face that particular tradeoff (and therefore Artur's proposed course of action makes the most sense).

There is consensus that in column zero, C-o should do what it used to do (i.e., no electric indent).  I think there's also consensus that in column >0, most of the time it makes sense for C-o to do electric indent even though there are sometimes cases where someone might want it to do no indentation.

There has been one example of a mode where from column >0, the indentation itself is broken, so that after doing C-o one would have to go down to the mis-indented line to fix it -- but that would be just as true if there had been *no* indentation (IOW, with C-o from column >0, doing no indentation is not more or less broken than any other mis-indentation, and costs about the same for the user to fix afterwards).

It's true that developers are more likely to fix that mode's indentation if the problem is less hidden from them, and in this case there isn't any compelling win for users if we mask the problem by making C-o completely indentation-insensitive, because for most users most of the time, "no indentation" would be just as broken a behavior as "indentation to the wrong place" (when doing C-o from column >0).

Best regards,
-Karl

Re: Questioning the new behavior of `open-line'.

[Pierpaolo Bernardi]

In case this change passes, could you please make it possible to get
the old behaviour easily?

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

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

On 12 Nov 2015 4:33 pm, "Pierpaolo Bernardi" <olopierpa@gmail.com> wrote:
>
> In case this change passes, could you please make it possible to get
> the old behaviour easily?

Hi Pierpaolo,

Could you clarify exactly what you mean by old behaviour? There are lots of
behaviours going around here, so I want to make sure I know what you're
referring to.

Give an example like Rasmus did, with text before, point position, and text
after (as you would want it).

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

Re: Questioning the new behavior of `open-line'.

[Pierpaolo Bernardi]

Hi,

On Fri, Nov 13, 2015 at 2:17 AM, Artur Malabarba
<bruce.connor.am@gmail.com> wrote:
>
> On 12 Nov 2015 4:33 pm, "Pierpaolo Bernardi" <olopierpa@gmail.com> wrote:
>>
>> In case this change passes, could you please make it possible to get
>> the old behaviour easily?
>
> Hi Pierpaolo,
>
> Could you clarify exactly what you mean by old behaviour? There are lots of
> behaviours going around here, so I want to make sure I know what you're
> referring to.

The old behaviour is: ctrl-o inserts a newline after the point,
nothing else is done.

If I want to reindent the next line, reindenting is only a mindless
keystroke away.  Fixing unwanted whitespace changes requires more
effort and full attention.

I'm sorry I couldn't follow the whole discussion from the start, so
I'm missing what prompted the change.

Cheers

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

2015-11-13 6:04 GMT+00:00 Pierpaolo Bernardi <olopierpa@gmail.com>:
> The old behaviour is: ctrl-o inserts a newline after the point,
> nothing else is done.

Ok, thanks for clarifying. Still can I ask for an example usage where
that behaviour is good and the current behaviour is bad.

I'm not trying to be annoying here. It's just that I want to clearly
list all relevant scenarios when I write the commit message (so that
future hackers will know about them before changing some behaviour).

Cheers

Re: Questioning the new behavior of `open-line'.

[David Kastrup]

Artur Malabarba <bruce.connor.am@gmail.com> writes:

> 2015-11-13 6:04 GMT+00:00 Pierpaolo Bernardi <olopierpa@gmail.com>:
>> The old behaviour is: ctrl-o inserts a newline after the point,
>> nothing else is done.
>
> Ok, thanks for clarifying. Still can I ask for an example usage where
> that behaviour is good and the current behaviour is bad.

I want to break a line before a line-ending comment (single ;) and
change that line-ending comment to a line comment (double ;;)
afterwards.  If Emacs gets a chance at indenting before I get a chance
at editing, it will even make a total mess of the comment line even when
it is doing everything "correctly" according to the current look of the
line.

More often than not, however, I use C-o when I know that Emacs'
indenting is going to be terminally wrong anyway.

But of course not having the material run away automatically before I
get a chance at editing it is also a valid consideration.

> I'm not trying to be annoying here. It's just that I want to clearly
> list all relevant scenarios when I write the commit message (so that
> future hackers will know about them before changing some behaviour).

Frankly, I cannot imagine your C-o behavior to be useful at all since
C-o is intentionally a dumb command to revert to for incremental
editing.  You use it either when you don't want automatic indentation,
or if you still have material to add on the current line.  And if you
still have material to add on the current line, it will likely be
relevant for indentation, so it's comparatively useless for C-o to
indent prematurely.

If not, there is still C-M-o bound to split-line rather than C-o bound
to open-line.

-- 
David Kastrup

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

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

On Sat, Nov 14, 2015 at 6:34 AM, Artur Malabarba <bruce.connor.am@gmail.com>
wrote:

> 2015-11-13 6:04 GMT+00:00 Pierpaolo Bernardi <olopierpa@gmail.com>:
> > The old behaviour is: ctrl-o inserts a newline after the point,
> > nothing else is done.
>
> Ok, thanks for clarifying. Still can I ask for an example usage where
> that behaviour is good and the current behaviour is bad.
>
> I'm not trying to be annoying here. It's just that I want to clearly
> list all relevant scenarios when I write the commit message (so that
> future hackers will know about them before changing some behaviour).
>

Even better, consider put the rationale(s) in a comment in `open-line'
itself, rather than in the commit message.  That way someone who is in the
code and thinking of changing it will see the reasoning right where they
are.

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

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

Artur, it sounds to me like there is not yet consensus on what C-o should do at column >0.  There have been plausible arguments both ways.

But since there wasn't really consensus on the original change either, and since there *is* consensus on what C-o should do in column 0 (namely, just insert a newline and do no indentation), maybe the best course for now is to revert the change, so we go back to the old behavior, and then continue this discussion so we can determine the right behavior for the next release of Emacs after this one?

By "old behavior", I mean "just inserts a newline".  This is correct for column 0, and is at least desired by some people in other positions; and it's the behavior we had for a long time, of course, so it's okay if it stays the same in this release too.  After all, the old behavior was not really considered an outright bug by most people, as far as I'm aware.

Thoughts?

This is assuming there's still time to make the reversion on the release branch (it would then get merged to master soon).  I'm not sure whether there is, and hope someone here who is tracking that more carefully can say for sure.  I'm happy to do the reversion, if you're pressed for time.

Best regards,
-Karl

David Kastrup <dak@gnu.org> writes:
>Artur Malabarba <bruce.connor.am@gmail.com> writes:
>
>> 2015-11-13 6:04 GMT+00:00 Pierpaolo Bernardi <olopierpa@gmail.com>:
>>> The old behaviour is: ctrl-o inserts a newline after the point,
>>> nothing else is done.
>>
>> Ok, thanks for clarifying. Still can I ask for an example usage where
>> that behaviour is good and the current behaviour is bad.
>
>I want to break a line before a line-ending comment (single ;) and
>change that line-ending comment to a line comment (double ;;)
>afterwards.  If Emacs gets a chance at indenting before I get a chance
>at editing, it will even make a total mess of the comment line even when
>it is doing everything "correctly" according to the current look of the
>line.
>
>More often than not, however, I use C-o when I know that Emacs'
>indenting is going to be terminally wrong anyway.
>
>But of course not having the material run away automatically before I
>get a chance at editing it is also a valid consideration.
>
>> I'm not trying to be annoying here. It's just that I want to clearly
>> list all relevant scenarios when I write the commit message (so that
>> future hackers will know about them before changing some behaviour).
>
>Frankly, I cannot imagine your C-o behavior to be useful at all since
>C-o is intentionally a dumb command to revert to for incremental
>editing.  You use it either when you don't want automatic indentation,
>or if you still have material to add on the current line.  And if you
>still have material to add on the current line, it will likely be
>relevant for indentation, so it's comparatively useless for C-o to
>indent prematurely.
>
>If not, there is still C-M-o bound to split-line rather than C-o bound
>to open-line.

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

>This is assuming there's still time to make the reversion on the
>release branch (it would then get merged to master soon).  I'm not sure
>whether there is, and hope someone here who is tracking that more
>carefully can say for sure.

Okay, based on checking other threads, it seems there is still time, as long as it's done on the release branch.

Best,
-Karl

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Karl Fogel <kfogel@red-bean.com> writes:

> This is assuming there's still time to make the reversion on the release
> branch (it would then get merged to master soon). I'm not sure whether there
> is, and hope someone here who is tracking that more carefully can say for
> sure. I'm happy to do the reversion, if you're pressed for time.

I would like C-o to not indent at column zero in the emacs-25 branch. There is
no pressing hurry.

John

Re: Questioning the new behavior of `open-line'.

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

This might be a good thing to poll the users about.

-- 
Dr Richard Stallman
President, Free Software Foundation (gnu.org, fsf.org)
Internet Hall-of-Famer (internethalloffame.org)
Skype: No way! See stallman.org/skype.html.

Re: Questioning the new behavior of `open-line'.

[John Wiegley]

>>>>> Richard Stallman <rms@gnu.org> writes:

> This might be a good thing to poll the users about.

Since we're discussing a change in behavior from past versions, and many of us
have come to rely on that behavior, I would rather we simply revert to
previous behavior for "C-o at 0" in 25.1.

John

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

2015-11-17 0:42 GMT+00:00 Karl Fogel <kfogel@red-bean.com>:
> Artur, it sounds to me like there is not yet consensus on what C-o should do at column >0.  There have been plausible arguments both ways.

I just want to say I haven't forgotten about this thread. I'm 1 week
away from the most important day of the last 3 years for me, so I'm
going to be absent for 7 more days. After that, this thread is one of
the first things on my list.

And don't worry about the timing of the release branch. I'm
considering this a bugfix, so I'll keep my change feature-freeze-safe
(there's a decent chance I'll just revert).

Re: Questioning the new behavior of `open-line'.

[Andreas Röhler]

  On 18.11.2015 00:16, John Wiegley wrote:
>>>>>> Richard Stallman<rms@gnu.org>  writes:
>> This might be a good thing to poll the users about.
> Since we're discussing a change in behavior from past versions, and many of us
> have come to rely on that behavior, I would rather we simply revert to
> previous behavior for "C-o at 0" in 25.1.
>
> John
>

+1

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

Artur Malabarba <bruce.connor.am@gmail.com> writes:
>2015-11-17 0:42 GMT+00:00 Karl Fogel <kfogel@red-bean.com>:
>> Artur, it sounds to me like there is not yet consensus on what C-o
>> should do at column >0.  There have been plausible arguments both
>> ways.
>
>I just want to say I haven't forgotten about this thread. I'm 1 week
>away from the most important day of the last 3 years for me, so I'm
>going to be absent for 7 more days. After that, this thread is one of
>the first things on my list.
>
>And don't worry about the timing of the release branch. I'm
>considering this a bugfix, so I'll keep my change feature-freeze-safe
>(there's a decent chance I'll just revert).

Thanks for letting us know, Artur.

If you're swamped, I'm happy to do the reversion (pretty easy for me, since I've been following the changes & the thread in detail), but I won't unless you say so.

(Can only guess that "most important day" is Ph.D. defense?  Break a leg!)

Best regards,
-Karl

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

2015-11-18 20:32 GMT+00:00 Karl Fogel <kfogel@red-bean.com>:
> Thanks for letting us know, Artur.
>
> If you're swamped, I'm happy to do the reversion (pretty easy for me, since I've been following the changes & the thread in detail), but I won't unless you say so.

Yes, you have my "OK" to revert this change completely. TBH, this
doesn't really affect me :-). Normally I just use
aggressive-indent-mode for all my indentation needs. I only realised I
wanted to change C-o while doing some edits from emacs -Q.

However, if you do revert, it would be nice if you kept the tests I
added (some of them will need to be fixed, of course).

> (Can only guess that "most important day" is Ph.D. defense?  Break a leg!)

Thanks. :-)
It is indeed.

Cheers

Re: Questioning the new behavior of `open-line'.

[Karl Fogel]

Artur Malabarba <bruce.connor.am@gmail.com> writes:
>2015-11-18 20:32 GMT+00:00 Karl Fogel <kfogel@red-bean.com>:
>> Thanks for letting us know, Artur.
>>
>> If you're swamped, I'm happy to do the reversion (pretty easy for
>> me, since I've been following the changes & the thread in detail),
>> but I won't unless you say so.
>
>Yes, you have my "OK" to revert this change completely. TBH, this
>doesn't really affect me :-). Normally I just use
>aggressive-indent-mode for all my indentation needs. I only realised I
>wanted to change C-o while doing some edits from emacs -Q.
>
>However, if you do revert, it would be nice if you kept the tests I
>added (some of them will need to be fixed, of course).

Done, in commit c593538968a on the 'emacs-25' branch.

(I think I don't need to do anything special to port this over to
'master', right?  It'll just happen automagically at some point?)

Best regards,
-Karl

Re: Questioning the new behavior of `open-line'.

[Artur Malabarba]

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

On 19 Nov 2015 11:34 pm, "Karl Fogel" <kfogel@red-bean.com> wrote:
> Done, in commit c593538968a on the 'emacs-25' branch.

Thank you, Karl.

> (I think I don't need to do anything special to port this over to
> 'master', right?  It'll just happen automagically at some point?)

Yes. At some point someone will merge these back.

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