Re: _expand_alias does not expand aliases that contain an "!"

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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.