From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22750 invoked from network); 19 Sep 2004 17:00:37 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 19 Sep 2004 17:00:37 -0000 Received: (qmail 34265 invoked from network); 19 Sep 2004 17:00:28 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 19 Sep 2004 17:00:28 -0000 Received: (qmail 5991 invoked by alias); 19 Sep 2004 17:00:25 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20385 Received: (qmail 5960 invoked from network); 19 Sep 2004 17:00:23 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 19 Sep 2004 17:00:23 -0000 Received: (qmail 34028 invoked from network); 19 Sep 2004 17:00:23 -0000 Received: from moonbase.zanshin.com (64.84.47.139) by a.mx.sunsite.dk with SMTP; 19 Sep 2004 17:00:21 -0000 Received: from toltec.zanshin.com (toltec.zanshin.com [64.84.47.166]) by moonbase.zanshin.com (8.13.1/8.13.1) with ESMTP id i8JH0LIU025947 for ; Sun, 19 Sep 2004 10:00:21 -0700 Date: Sun, 19 Sep 2004 10:00:20 -0700 (PDT) From: Bart Schaefer Reply-To: zsh-workers@sunsite.dk To: zsh-workers@sunsite.dk Subject: Re: PATCH: exit after 10 EOF's In-Reply-To: <20040919115312.C9A40863A@pwstephenson.fsnet.co.uk> Message-ID: References: <200409131118.i8DBIM5B005245@news01.csr.com> <20040919115312.C9A40863A@pwstephenson.fsnet.co.uk> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 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.