Re: PATCH: configurability of pattern characters, part 1

[Peter Stephenson <p.w.stephenson@ntlworld.com>]

On Fri, 31 May 2013 23:22:23 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Jun 1, 12:29am, Peter Stephenson wrote:
> }
> } The second step, to follow: now we have the "zpc_special" array, it will
> } be possible (and fairly straightforward) to introduce a special variable
> } to indicate pattern characters that should be turned off
> 
> Possible alternative idea -- use the enable/disable builtins?
> 
>     disable -p '^' '(' '+('

That's quite reasonable, it makes it more natural to enforce particular
entries than in an array.

The simple meaning for enable -p is that it reverses a disable, it
doesn't explicitly enable something that's not allowed by the options.
I think I'll stick with that (though it needs clearly documenting).  If
you want to be able to enable or disable every pattern separetely, you
"setopt extendedglob kshglob noshglob" first.

> } We'll need to set the new shell variable(s) locally to empty for
> } completion.
> 
> Hmm, that's another problem with the enable/disable idea ... or is it?
> "emulate -R zsh -c 'autoload _main_complete'" should do the trick ...?

Yes, it should, but that's another story I haven't written yet, so we
probably need another way...

"disable -p" should output the current settings, which we could save.
We reenable anything associated with extendedglob, turning off kshglob
and shglob using the options as now, and use disable -p to redisable the
user's stuff at the end in an "always" block.

Or how about readonly zsh/parameter arrays corresponding to enabled and
disabled patterns?  Same idea, just slightly more efficient to save.
(Could even be read/write; since they'd be documented as a front end to
enable/disable rather than the basic syntax the scoping behaviour isn't
so much of an issue.)

> } I think also "emulate" should clear them (locally for "emulate -L") to
> } present a pristine pattern environment for emulation.
> 
> I agree ... which for me is an argument *against* using variables for
> this.  I know emulation modes already play with the special-ness of
> things like HISTCHARS and MANPATH, but it doesn't actually go so far
> as creating empty locals for them.

The trouble is this creates an additional form of scope that's not
options or parameters or traps for saving and restoring.  However,
there's nothing fundamentally difficult about that.

Logically, to get emulate -L to behave as it does for options and traps,
there should be an option "localpatterns" that causes the effects of
disable -p to be restored after the current scope: otherwise we don't
have a natural distinction between the behaviour of "emulate" and
"emulate -L" (they'd have some hidden different effect on scoping, which
I don't like).  We just need to save one bit per pattern, so this is
much more efficient than what we currently do for localoptions.  In
other words, "setopt localpatterns" would mean "restore the disabled
pattern state at the end of the current function scope"; emulate's only
contribution would be to set this if -L was given and in any case turn
off the current disables.  That's exactly parallel to localoptions
except there's only one emulation state in this case, i.e. the one where
the patterns are controlled only by the option settings.
 
> Speaking of HISTCHARS, do we agree that it'd be a bad idea to be able
> to swap around which characters have what glob semantics?  E.g., it's
> OK if * means only "*", but you can't make % mean "match any number of
> any character".

Yes, I really don't think there's any sense in allowing this.  It causes
confusion far beyond any convenience it produces.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/