zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: zsh-workers@sunsite.dk
Subject: Re: PATCH: exit after 10 EOF's
Date: Sun, 19 Sep 2004 10:00:20 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.61.0409190941460.6971@toltec.zanshin.com> (raw)
In-Reply-To: <20040919115312.C9A40863A@pwstephenson.fsnet.co.uk>

On Sun, 19 Sep 2004, Peter Stephenson wrote:

> I think the key bits that need discussing are...
> 
> > Returning to your excerpt far above, you appear to object to the fact that 
> > the conditions of "not internal" and "not completion" are simultaneously 
> > required in order for a widget binding to override the default behavior of 
> > setopt ignoreeof.  Is that an accurate summation?
> 
> Yes, particularly since even calling a builtin widget from a zle -N
> widget doesn't override the behaviour.

That actually has to do with the implementation of "zle name-of-widget". 
It passes back through the code that tests for whether to emit the warning 
(though not back through the code that exits).  I suppose one could argue 
that this is also intentional, so that one can create transparent wrappers 
around internal widgets, but in this case I doubt anyone thought that far
ahead.

Of course there _is_ a workaround:  "setopt localoptions noignoreeof" in 
widgets that use "zle name-of-widget".  However, I agree this is not the 
ideal solution.

> My guess is that because of this problem very few people are relying on 
> (nor possibly even aware of, despite the documentation) the suppress- 
> message behaviour of widget binding, so the inconvenience is minimal.

I don't disagree -- in fact, I think it's more likely that people are
unknowingly relying on the unintentional transparency behavior.  Certainly
a lot of people are unknowingly relying on the "not a completion widget"
behavior.  Either way, though, it makes changing it problematic.

I'm going to drop the discussion of "10 EOF characters" at this point 
because I'm increasingly of the opinion that counting 10 warnings instead 
is an agreeable solution, leaving us only with the question of how best to 
allow suppression of the warning.


      reply	other threads:[~2004-09-19 17:00 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-13 11:18 Peter Stephenson
2004-09-13 17:51 ` Bart Schaefer
2004-09-15  9:46   ` Peter Stephenson
2004-09-15 15:43     ` Bart Schaefer
2004-09-15 16:02       ` Bart Schaefer
2004-09-15 16:14         ` Peter Stephenson
2004-09-16 14:57           ` Peter Stephenson
2004-09-16 16:12             ` Bart Schaefer
2004-09-16 16:28               ` Peter Stephenson
2004-09-19  6:50 ` Bart Schaefer
2004-09-19  7:45   ` Duncan Sinclair
2004-09-19 16:41     ` Bart Schaefer
2004-09-19 17:52       ` Peter Stephenson
2004-09-19 18:26         ` Bart Schaefer
2004-09-19 19:25           ` Bart Schaefer
2004-09-20 10:15             ` Peter Stephenson
2004-09-20 13:59             ` Peter Stephenson
2004-09-20 14:43               ` Bart Schaefer
2004-09-20 14:53                 ` Peter Stephenson
2004-09-19 19:11         ` Bart Schaefer
2004-09-19 11:53   ` Peter Stephenson
2004-09-19 17:00     ` Bart Schaefer [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.61.0409190941460.6971@toltec.zanshin.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).