From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Default setting for sh-maybe-here-document-mode Date: Sat, 21 Feb 2015 09:12:30 +0000 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e0158b79ca1678e050f95918c X-Trace: ger.gmane.org 1424509979 1112 80.91.229.3 (21 Feb 2015 09:12:59 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 21 Feb 2015 09:12:59 +0000 (UTC) Cc: emacs-devel To: thibaut.verron@gmail.com, Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Feb 21 10:12:52 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YP67H-00084n-Pe for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 10:12:52 +0100 Original-Received: from localhost ([::1]:35477 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YP67G-0004zh-OM for ged-emacs-devel@m.gmane.org; Sat, 21 Feb 2015 04:12:50 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49360) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YP671-0004zP-2n for emacs-devel@gnu.org; Sat, 21 Feb 2015 04:12:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YP66z-0005Y9-Do for emacs-devel@gnu.org; Sat, 21 Feb 2015 04:12:35 -0500 Original-Received: from mail-lb0-x235.google.com ([2a00:1450:4010:c04::235]:42936) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YP66z-0005Xt-0t for emacs-devel@gnu.org; Sat, 21 Feb 2015 04:12:33 -0500 Original-Received: by lbiw7 with SMTP id w7so10530896lbi.9 for ; Sat, 21 Feb 2015 01:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:from:date:message-id:subject:to:cc :content-type; bh=m75N7K6NErmko7N4jHn5fgqWiA3nQVZoIchVcgFWUFs=; b=ZYvqy44uPiO/El6Mi8swtwXaEnBuAXLnnTz9N9tRHU1YLNbE81Oq9Uz0pTFoeeCyDG rlxJ3PQJMjkBFOc41jdMLUoOVeUPiZ/IE5biH72U37XBZlKOg85oiXAv2j4D3J1Nl1Aa dz3suLn1AmASanw0WCYz/YB+HdJGmcJpYLUyixOITAtrVL+ec+pB12IjWmfDtxOro6Mv +qfFjD4LdxnEw7ITsnzFixv2HQ5iIEh6Yu27R4w4d4pQHimlDHuhgLIhMkcgTdv1Vtmv 2FlPZECam8v/W2hIPRKpMOUf6AszWf+NEEkFfNcS2gsz1biHApZGo8rpl0UOvEyySNFE 8h3w== X-Received: by 10.152.36.162 with SMTP id r2mr1398192laj.9.1424509951368; Sat, 21 Feb 2015 01:12:31 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c04::235 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183347 Archived-At: --089e0158b79ca1678e050f95918c Content-Type: text/plain; charset=UTF-8 Thibaut Verron schrieb am Fri Feb 20 2015 at 16:50:02: > 2015-02-20 14:58 GMT+01:00 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). >> > > 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. --089e0158b79ca1678e050f95918c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Thibaut Verron <thibaut.verron@gmail.com> sc= hrieb 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-electri= c-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 defa= ult"
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,<= br> > inserting text beyond what the user types, without requiring anything<= br> > besides text input, are disabled by default.

We don't really have a clear policy on this.=C2=A0 I generally t= end 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 le= ss intrusive than the electric here document, but maybe that's only bec= ause I'm used to it. At least, a lot of other editors implement a simil= ar feature, so emacs won't stand out as an annoyance for auto-indenting= .
=C2=A0

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

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

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

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

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


<= /div>
Notice the number of different answers/workarounds! And the accep= ted 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 b= ehavior. 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 &= quot;sh-electric-here-document-mode" : I don't see a single link w= hich is not either completely unrelated or asking how to disable it. (Sorry= for biasing the measure with the present thread)
<= br>


> I understand that changing defaults is sensible, but in this case, wou= ldn'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 thes= e
> 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, u= sing a here-string. In other words, try to enter

= =C2=A0 =C2=A0 command <<< "line of text"

<= /div>
As an anecdote, I am TA in a course where students learn about em= acs and shell scripting, and I have seen mainly two reactions to this featu= re:
"I got back to gedit because it didn't have the issu= e"
"I use 'echo ... | ... ' instead of here-lin= e because it is easier to type on emacs" (And this work-around will le= ad to different problems, for example if command is supposed to change the = environment)

This use-case can be accommodated wit= h this piece of code: http://emacs.stackexchange.com/a/5338/184=C2=A0
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 d= efault.

Another use-case, even if you never use he= re-strings, is that you want to enter a single <, but enter << ins= tead. You would expect this mistake to be corrected with a single backspace= , but it's not.=C2=A0

By the way, we could des= ign it so that the feature is still accessible, but through more convention= al entry points, for example by pressing TAB with point after << .=C2= =A0

Thibaut Verron
=

+1 to disabling this feature by defa= ult. It's easily the most annoying part=C2=A0of shell scripting in Emac= s for me (I use herestrings at least as often as heredocs). I agree that th= is is way more intrusive and confusing than electric indentation.
--089e0158b79ca1678e050f95918c--