emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thibaut Verron
Subject: Re: Default setting for sh-maybe-here-document-mode
Date: Fri, 20 Feb 2015 16:49:27 +0100

2015-02-20 14:58 GMT+01:00 Stefan Monnier <address@hidden>:
> 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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]