From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7627 invoked by alias); 14 Sep 2014 20:56:08 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 33170 Received: (qmail 28225 invoked from network); 14 Sep 2014 20:55:57 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140914135552.ZM31608@torch.brasslantern.com> Date: Sun, 14 Sep 2014 13:55:52 -0700 In-reply-to: <140914113029.ZM31296@torch.brasslantern.com> Comments: In reply to Bart Schaefer "Re: _expand_alias does not expand aliases that contain an "!"" (Sep 14, 11:30am) References: <140830133206.ZM13172@torch.brasslantern.com> <140831135017.ZM739@torch.brasslantern.com> <140914113029.ZM31296@torch.brasslantern.com> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: _expand_alias does not expand aliases that contain an "!" MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Please ignore the patch in 33169, it's insufficient in light of the below. On Sep 14, 11:30am, Bart Schaefer wrote: } } Eventually callcompfunc() invokes multiquote() on the lexed word, which } calls quotestring(), which does not re-quote the tokenized characters } but does quote the history characters. (compcore.c:706) } } I think that means the fix is [adding NO_banghist to _comp_options]. } } There's a remaining, probably autoloading-related, weirdness, which is } that _expand_alias doesn't work the first time you try it unless the } completion system has already been invoked some other way (including } by having tried _expand_alias at least once already). Tracing with } _complete_debug shows that the first time through, a backslash is } being inserted before '!' even though NO_banghist is in effect; but } on the second and later attempts, there's no backslash. Puzzling. This really had me confused. Adding NO_banghist to _comp_options *ought* to be "too late" to affect the behavior of callcompfunc(), and yet somehow it does so -- but only on the second and subsequent completion attempts. So I put watchpoints on opts[17] (BANGHIST) and typtab[33] ('!') and went through the completion twice. On the first pass: Hardware watchpoint 1: typtab[33 '!'] Old value = 3072 New value = 0 inittyptab () at ../../zsh-5.0/Src/utils.c:3443 3443 for (t0 = 0; t0 != 256; t0++) Hardware watchpoint 1: typtab[33 '!'] Old value = 0 New value = 1024 inittyptab () at ../../zsh-5.0/Src/utils.c:3494 It then flips back and forth between 0 and 1024 several times, but never gets back to the value 3072. On the second pass it starts out at 1024, and so quotestring() treats it as ordinary. What's happening is that the ISPECIAL bit is never restored in the event that BANGHIST is toggled off and back on again "in the background"; it is only set if BANGHIST is toggled interactively, e.g., from an init file or the command line. Src/utils.c: 3519 if (isset(BANGHIST) && bangchar && interact && isset(SHINSTDIN)) 3520 typtab[bangchar] |= ISPECIAL; There's something wrong with that test. Either we don't need the ISPECIAL bit on the first character of histchars -- history still seems to work as long as the BANGHIST option is set, even if '!' is not marked special, but there may be cases I didn't try -- or we need to fix the conditions in which ISPECIAL-ness is restored. And then in turn, I think, have the completion internals disable BANGHIST during lexing, unless somebody has a better suggestion.