Default setting for sh-maybe-here-document-mode

Default setting for sh-maybe-here-document-mode

[Thibaut Verron]

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

Hello,

I was wondering why is `sh-electric-here-document-mode` activated by
default for new documents in `sh-mode`? In my opinion, it is confusing to
beginners, and working around it is difficult.

I was under the impression that in most cases, this kind of commands,
inserting text beyond what the user types, without requiring anything
besides text input, are disabled by default. AUCTeX's electric backslash,
for example, require a specific option to be set, even though in most cases
it can be transparent input-wise (just visually confusing). Another example
is dabbrev, which needs to be activated by the user.

And why is it so hard to disable it once you find out where the annoying
behavior comes from? (Just see how many articles deal with this specific
issue; and having changed the name of the mode in 24.3 doesn't help)

I understand that changing defaults is sensible, but in this case, wouldn't
it be worth it? In my opinion, the only people who may appreciate this
setting are people who know how to use C-q to work around it, and these
people will know how to reactivate it.

Regards,

Thibaut Verron

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

Re: Default setting for sh-maybe-here-document-mode

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 20 Feb 2015 09:19:22 +0100
> 
> I was wondering why is `sh-electric-here-document-mode` activated by default
> for new documents in `sh-mode`? In my opinion, it is confusing to beginners,
> and working around it is difficult. 
> 
> I was under the impression that in most cases, this kind of commands, inserting
> text beyond what the user types, without requiring anything besides text input,
> are disabled by default. AUCTeX's electric backslash, for example, require a
> specific option to be set, even though in most cases it can be transparent
> input-wise (just visually confusing). Another example is dabbrev, which needs
> to be activated by the user. 
> 
> And why is it so hard to disable it once you find out where the annoying
> behavior comes from? (Just see how many articles deal with this specific issue;
> and having changed the name of the mode in 24.3 doesn't help) 

What you say is generally applicable to any electric behavior in any
Emacs mode, not just to sh-electric-here-document-mode, right?  Or is
that mode somehow special (and if so, how)?

Re: Default setting for sh-maybe-here-document-mode

[Thibaut Verron]

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

Most of them are not activated by default.

2015-02-20 9:31 GMT+01:00 Eli Zaretskii <eliz@gnu.org>:

> > From: Thibaut Verron <thibaut.verron@gmail.com>
> > Date: Fri, 20 Feb 2015 09:19:22 +0100
> >
> > I was wondering why is `sh-electric-here-document-mode` activated by
> default
> > for new documents in `sh-mode`? In my opinion, it is confusing to
> beginners,
> > and working around it is difficult.
> >
> > I was under the impression that in most cases, this kind of commands,
> inserting
> > text beyond what the user types, without requiring anything besides text
> input,
> > are disabled by default. AUCTeX's electric backslash, for example,
> require a
> > specific option to be set, even though in most cases it can be
> transparent
> > input-wise (just visually confusing). Another example is dabbrev, which
> needs
> > to be activated by the user.
> >
> > And why is it so hard to disable it once you find out where the annoying
> > behavior comes from? (Just see how many articles deal with this specific
> issue;
> > and having changed the name of the mode in 24.3 doesn't help)
>
> What you say is generally applicable to any electric behavior in any
> Emacs mode, not just to sh-electric-here-document-mode, right?  Or is
> that mode somehow special (and if so, how)?
>

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

Re: Default setting for sh-maybe-here-document-mode

[Stefan Monnier]

> I was wondering why is `sh-electric-here-document-mode` activated by
> default for new documents in `sh-mode`?

IIRC I turned it into a minor mode and made it "enabled by default"
because the corresponding functionality was active by default before
(i.e. I just tried to preserve the previous behavior).

> I was under the impression that in most cases, this kind of commands,
> inserting text beyond what the user types, without requiring anything
> besides text input, are disabled by default.

We don't really have a clear policy on this.  I generally tend to prefer
keeping those things disabled, indeed, but OTOH electric-indent-mode is
now enabled by default (which is a pretty major counter example).

> And why is it so hard to disable it once you find out where the annoying
> behavior comes from?

Hmm... indeed, maybe it should be a global minor mode?

> (Just see how many articles deal with this specific
> issue; and having changed the name of the mode in 24.3 doesn't help)

I haven't noticed this, no.  Neither on gnu.emacs.help nor on stackoverflow.

> I understand that changing defaults is sensible, but in this case, wouldn't
> it be worth it? In my opinion, the only people who may appreciate this
> setting are people who know how to use C-q to work around it, and these
> people will know how to reactivate it.

It should (supposedly) be very rare that it triggers by accident.

If you have some sample scenarios where it triggers when it's undesired,
maybe we can fine-tune it to avoid those,


        Stefan

Re: Default setting for sh-maybe-here-document-mode

[Thibaut Verron]

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

2015-02-20 14:58 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:

> > I was wondering why is `sh-electric-here-document-mode` activated by
> > default for new documents in `sh-mode`?
>
> IIRC I turned it into a minor mode and made it "enabled by default"
> because the corresponding functionality was active by default before
> (i.e. I just tried to preserve the previous behavior).
>
> > I was under the impression that in most cases, this kind of commands,
> > inserting text beyond what the user types, without requiring anything
> > besides text input, are disabled by default.
>
> We don't really have a clear policy on this.  I generally tend to prefer
> keeping those things disabled, indeed, but OTOH electric-indent-mode is
> now enabled by default (which is a pretty major counter example).
>

Imo electric-indent-mode is way less intrusive than the electric here
document, but maybe that's only because I'm used to it. At least, a lot of
other editors implement a similar feature, so emacs won't stand out as an
annoyance for auto-indenting.


>
> > And why is it so hard to disable it once you find out where the annoying
> > behavior comes from?
>
> Hmm... indeed, maybe it should be a global minor mode?
>

And auto-loaded? This could work. Another option would be to reenable the
binding on '<' (see just below), and let users who do not want the behavior
use self-insert-command.


>
> > (Just see how many articles deal with this specific
> > issue; and having changed the name of the mode in 24.3 doesn't help)
>
> I haven't noticed this, no.  Neither on gnu.emacs.help nor on
> stackoverflow.
>

See for example http://unix.stackexchange.com/q/20121/47331

Notice the number of different answers/workarounds! And the accepted answer
(probably the most natural) does not even work anymore: on 24.3, < is bound
to self-insert-command by default, yet it does trigger the behavior. Side
note: this is the only case I can think of where self-insert-command does
something else than inserting the character. It is probably a bug by itself.

As another metric, you can google "sh-electric-here-document-mode" : I
don't see a single link which is not either completely unrelated or asking
how to disable it. (Sorry for biasing the measure with the present thread)



> > I understand that changing defaults is sensible, but in this case,
> wouldn't
> > it be worth it? In my opinion, the only people who may appreciate this
> > setting are people who know how to use C-q to work around it, and these
> > people will know how to reactivate it.
>
> It should (supposedly) be very rare that it triggers by accident.
>
> If you have some sample scenarios where it triggers when it's undesired,
> maybe we can fine-tune it to avoid those,
>

It is very easy: try to feed a single line to a command, using a
here-string. In other words, try to enter

    command <<< "line of text"

As an anecdote, I am TA in a course where students learn about emacs and
shell scripting, and I have seen mainly two reactions to this feature:
"I got back to gedit because it didn't have the issue"
"I use 'echo ... | ... ' instead of here-line because it is easier to type
on emacs" (And this work-around will lead to different problems, for
example if command is supposed to change the environment)

This use-case can be accommodated with this piece of code:
http://emacs.stackexchange.com/a/5338/184
It still fails in case the here-document is supposed to start with a <,
which is reasonable, but would probably be even more confusing as a default.

Another use-case, even if you never use here-strings, is that you want to
enter a single <, but enter << instead. You would expect this mistake to be
corrected with a single backspace, but it's not.

By the way, we could design it so that the feature is still accessible, but
through more conventional entry points, for example by pressing TAB with
point after << .

Thibaut Verron

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

Re: Default setting for sh-maybe-here-document-mode

[Stefan Monnier]

>> Hmm... indeed, maybe it should be a global minor mode?
> And auto-loaded?

I think we could make it so that (setq sh-electric-here-document-mode
nil) in your ~/.emacs would be sufficient.

Autoloading it and having users put (sh-electric-here-document-mode -1)
in their ~/.emacs means that those users end up loading
sh-script.el eagerly.

> This could work. Another option would be to reenable the binding on
> '<' (see just below), and let users who do not want the behavior use
> self-insert-command.

No, using post-self-insert-hook instead of a key-binding was the main
motivation behind the change.  Reverting this is not an option.

> It is very easy: try to feed a single line to a command, using a
> here-string. In other words, try to enter
>     command <<< "line of text"

Ah, right, I remember this now (obviously, I never use it myself).

Could you file a bug report for it?  I think the feature was developed
at a time where <<< didn't exist, and accommodating <<< will require
some rethinking.

> This use-case can be accommodated with this piece of code:
> http://emacs.stackexchange.com/a/5338/184
> It still fails in case the here-document is supposed to start with a <,
> which is reasonable, but would probably be even more confusing as a default.

It's also rather jarring to have a "big" chunk of text be inserted
there, and it may not occur to the user than hitting a third < will get
her what she wanted.

> Another use-case, even if you never use here-strings, is that you want to
> enter a single <, but enter << instead.  You would expect this mistake to be
> corrected with a single backspace, but it's not.

We could special case this, potentially, but at the same time `undo' is
your friend.

> By the way, we could design it so that the feature is still accessible, but
> through more conventional entry points, for example by pressing TAB with
> point after << .

Right, or we could trigger the heredoc template after `< < SPC' rather
than just after '< <'.  In any case, given the use of <<< I agree that
the current moment at which heredoc is triggered is inappropriate.


        Stefan

Re: Default setting for sh-maybe-here-document-mode

[Thibaut Verron]

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

2015-02-20 18:08 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:

> >> Hmm... indeed, maybe it should be a global minor mode?
> > And auto-loaded?
>
> I think we could make it so that (setq sh-electric-here-document-mode
> nil) in your ~/.emacs would be sufficient.
>
> Autoloading it and having users put (sh-electric-here-document-mode -1)
> in their ~/.emacs means that those users end up loading
> sh-script.el eagerly.
>
> > This could work. Another option would be to reenable the binding on
> > '<' (see just below), and let users who do not want the behavior use
> > self-insert-command.
>
> No, using post-self-insert-hook instead of a key-binding was the main
> motivation behind the change.  Reverting this is not an option.
>

Now I am curious, I'll probably dive in the mailing list history to find
out more about this motivation.


>
> > It is very easy: try to feed a single line to a command, using a
> > here-string. In other words, try to enter
> >     command <<< "line of text"
>
> Ah, right, I remember this now (obviously, I never use it myself).
>
> Could you file a bug report for it?  I think the feature was developed
> at a time where <<< didn't exist, and accommodating <<< will require
> some rethinking.
>

Sure thing.


>
> > This use-case can be accommodated with this piece of code:
> > http://emacs.stackexchange.com/a/5338/184
> > It still fails in case the here-document is supposed to start with a <,
> > which is reasonable, but would probably be even more confusing as a
> default.
>
> It's also rather jarring to have a "big" chunk of text be inserted
> there, and it may not occur to the user than hitting a third < will get
> her what she wanted.
>
> > Another use-case, even if you never use here-strings, is that you want to
> > enter a single <, but enter << instead.  You would expect this mistake
> to be
> > corrected with a single backspace, but it's not.
>
> We could special case this, potentially, but at the same time `undo' is
> your friend.


I know, but for some reason I can't get the hang of using undo in the flow
of writing text.


>
> > By the way, we could design it so that the feature is still accessible,
> but
> > through more conventional entry points, for example by pressing TAB with
> > point after << .
>
> Right, or we could trigger the heredoc template after `< < SPC' rather
> than just after '< <'.  In any case, given the use of <<< I agree that
> the current moment at which heredoc is triggered is inappropriate.
>

This is a good idea, but in this case you also need to include < < - as a
trigger.

Thibaut

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

Re: Default setting for sh-maybe-here-document-mode

[Stefan Monnier]

> Now I am curious, I'll probably dive in the mailing list history to find
> out more about this motivation.

I don't think there's much history about it in the mailing-list.
Using post-self-insert-hook has the advantage of being more modular than
a key-binding: you can make it do heredoc expansion in sh-script without
affecting whether it does automatic reindent (via electric-indent-mode)
or automatic pairing (via electric-pair-mode), or ...

>> > Another use-case, even if you never use here-strings, is that you
>> > want to enter a single <, but enter << instead.  You would expect
>> > this mistake to be corrected with a single backspace, but it's not.
>> We could special case this, potentially, but at the same time `undo' is
>> your friend.
> I know, but for some reason I can't get the hang of using undo in the flow
> of writing text.

It's definitely more intrusive, admittedly.  I'd welcome a patch which
makes backspace actually undo the expansion.

> This is a good idea, but in this case you also need to include < < -
> as a trigger.

Indeed, and probably < < ' as well.


        Stefan

Re: Default setting for sh-maybe-here-document-mode

[Thibaut Verron]

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

2015-02-23 0:24 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:

> > Now I am curious, I'll probably dive in the mailing list history to find
> > out more about this motivation.
>
> I don't think there's much history about it in the mailing-list.
> Using post-self-insert-hook has the advantage of being more modular than
> a key-binding: you can make it do heredoc expansion in sh-script without
> affecting whether it does automatic reindent (via electric-indent-mode)
> or automatic pairing (via electric-pair-mode), or ...
>

Oh I see, too many modes abusing key rebinding have lead me to believe it
was the idiom for this kind of behavior.


>
> >> > Another use-case, even if you never use here-strings, is that you
> >> > want to enter a single <, but enter << instead.  You would expect
> >> > this mistake to be corrected with a single backspace, but it's not.
> >> We could special case this, potentially, but at the same time `undo' is
> >> your friend.
> > I know, but for some reason I can't get the hang of using undo in the
> flow
> > of writing text.
>
> It's definitely more intrusive, admittedly.  I'd welcome a patch which
> makes backspace actually undo the expansion.
>

With your solution of requiring an additional (printed) character after the
<, I think accidental expansion would get much rarer already.


>
> > This is a good idea, but in this case you also need to include < < -
> > as a trigger.
>
> Indeed, and probably < < ' as well.
>

By the way, the bug report is sent now, sorry for the delay, I was without
an internet connection for the week-end.

Thibaut

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

Re: Default setting for sh-maybe-here-document-mode

[Philipp Stephani]

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

Thibaut Verron <thibaut.verron@gmail.com> schrieb am Fri Feb 20 2015 at
16:50:02:

> 2015-02-20 14:58 GMT+01:00 Stefan Monnier <monnier@iro.umontreal.ca>:
>
>> > I was wondering why is `sh-electric-here-document-mode` activated by
>> > default for new documents in `sh-mode`?
>>
>> IIRC I turned it into a minor mode and made it "enabled by default"
>> because the corresponding functionality was active by default before
>> (i.e. I just tried to preserve the previous behavior).
>>
>> > I was under the impression that in most cases, this kind of commands,
>> > inserting text beyond what the user types, without requiring anything
>> > besides text input, are disabled by default.
>>
>> We don't really have a clear policy on this.  I generally tend to prefer
>> keeping those things disabled, indeed, but OTOH electric-indent-mode is
>> now enabled by default (which is a pretty major counter example).
>>
>
> Imo electric-indent-mode is way less intrusive than the electric here
> document, but maybe that's only because I'm used to it. At least, a lot of
> other editors implement a similar feature, so emacs won't stand out as an
> annoyance for auto-indenting.
>
>
>>
>> > And why is it so hard to disable it once you find out where the annoying
>> > behavior comes from?
>>
>> Hmm... indeed, maybe it should be a global minor mode?
>>
>
> And auto-loaded? This could work. Another option would be to reenable the
> binding on '<' (see just below), and let users who do not want the behavior
> use self-insert-command.
>
>
>>
>> > (Just see how many articles deal with this specific
>> > issue; and having changed the name of the mode in 24.3 doesn't help)
>>
>> I haven't noticed this, no.  Neither on gnu.emacs.help nor on
>> stackoverflow.
>>
>
> See for example http://unix.stackexchange.com/q/20121/47331
>
> Notice the number of different answers/workarounds! And the accepted
> answer (probably the most natural) does not even work anymore: on 24.3, <
> is bound to self-insert-command by default, yet it does trigger the
> behavior. Side note: this is the only case I can think of where
> self-insert-command does something else than inserting the character. It is
> probably a bug by itself.
>
> As another metric, you can google "sh-electric-here-document-mode" : I
> don't see a single link which is not either completely unrelated or asking
> how to disable it. (Sorry for biasing the measure with the present thread)
>
>
>
>> > I understand that changing defaults is sensible, but in this case,
>> wouldn't
>> > it be worth it? In my opinion, the only people who may appreciate this
>> > setting are people who know how to use C-q to work around it, and these
>> > people will know how to reactivate it.
>>
>> It should (supposedly) be very rare that it triggers by accident.
>>
>> If you have some sample scenarios where it triggers when it's undesired,
>> maybe we can fine-tune it to avoid those,
>>
>
> It is very easy: try to feed a single line to a command, using a
> here-string. In other words, try to enter
>
>     command <<< "line of text"
>
> As an anecdote, I am TA in a course where students learn about emacs and
> shell scripting, and I have seen mainly two reactions to this feature:
> "I got back to gedit because it didn't have the issue"
> "I use 'echo ... | ... ' instead of here-line because it is easier to type
> on emacs" (And this work-around will lead to different problems, for
> example if command is supposed to change the environment)
>
> This use-case can be accommodated with this piece of code:
> http://emacs.stackexchange.com/a/5338/184
> It still fails in case the here-document is supposed to start with a <,
> which is reasonable, but would probably be even more confusing as a default.
>
> Another use-case, even if you never use here-strings, is that you want to
> enter a single <, but enter << instead. You would expect this mistake to be
> corrected with a single backspace, but it's not.
>
> By the way, we could design it so that the feature is still accessible,
> but through more conventional entry points, for example by pressing TAB
> with point after << .
>
> Thibaut Verron
>

+1 to disabling this feature by default. It's easily the most annoying
part of shell scripting in Emacs for me (I use herestrings at least as
often as heredocs). I agree that this is way more intrusive and confusing
than electric indentation.

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