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

[Thibaut Verron <thibaut.verron@gmail.com>]

[-- 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 --]