Re: Call for opinions on a couple of prospective zsh patches

[Adam Spiers <adam@xxxxxxxxxxxxxxxxxxxxxxx>]

Bart Schaefer (schaefer@xxxxxxxxxxxxxxxxxxxxxxx) wrote:
> Greg Badros <gjb@@cs.washington.edu> has submitted patches for three new
> features that could appear in zsh 3.0.6.  I'm undecided whether to add
> any or all of them.  They are:
> 
> * Completion using "dynamic abbreviations" after the manner of the emacs
>   dabbrev package.  This includes adding a special `dabbrev-complete' ZLE
>   action, along the lines of expand-or-complete, complete-word, etc.

I submitted a patch to zsh-workers in Feb 1998 (see threads 'tcsh-like
history-based dabbrev-expand patch' and 'PATCH: complete-history')
which added history-dabbrev-expand and history-reverse-dabbrev-expand
actions, but it didn't get included because Peter had already written
a patch for zle -C, which allowed you to do something like

  zle -C complete-history -H '' 0
  bindkey "\M-/" complete-history

There were a few differences in functionality between the two (mine
had a reverse action, and with Peter's, the sequence M-/ TAB was
equivalent to M-/ M-/), but they were essentially the same thing.

Personally I find this feature so useful that I can't stand being
without it, and still use that version with my patch hacked in to this
day, which is unfortunate, because it's prevented me from regularly
trying out the newer development versions.

Which versions is zle -C (or similar) available in these days?

>   I find the effects of `dabbrev-complete' to be -very- similar to
> 	setopt menu_complete
> 	compctl -D -s '${=$(history -nr 1)}'
>   except that it can be bound to a different key than regular completion,
>   it always uses menu-completion behavior regardless of the option, and
>   the menu is sorted in reverse time order rather than alphabetically.

I really do relish it being bound to a different key.  I think I'd
prefer not to have it if it was the choice between being bound to TAB
as a fallback completion and not having it.

Also, I don't like the idea of menu-completion behaviour, because I
tend to keep a huge history (precisely for the reason that it makes a
dabbrev-expand action so useful), so I'd end up with huge menus (or a
"do you want a huge menu" prompt) most times I hit the key.  Ugh.

>   The next 3.1 release will include commands to bind special user-defined
>   completions to separate keystrokes (in the way that expand-or-complete
>   can be bound to a different key than complete-word, in 3.0) and also to
>   associate menu behavior with individual completions and to custom-sort
>   the menus; so a new builtin complete action is not likely to be added in
>   3.1.6.  I'm thus reluctant to have 3.0 branch off in a direction that
>   the development version won't follow.

Fair point.

>   And I think that most of the
>   benefits of `dabbrev-complete' can be had in plain 3.0.5 by adding the
>   above -s ... to a few compctls, so a builtin is not strictly necessary.

I'd say that if this next 3.1 release is coming soon then maybe don't
bother.  However, I would really love to see support for this
functionality ASAP.  Apart from anything else, tcsh already has it,
and we can't let tcsh have features zsh doesn't have, can we? :-)

> * Partial word motions in the face of mixed case, i.e. move the cursor to
>   the next/previous capital letter InMixedCaseWordsLikeThisOne, including
>   deletions that treat words this way.  This is also handled by adding a
>   few new ZLE builtins, and relies on isupper() to detect upper case, so
>   it may behave differently in different language locales.
> 
>   My first inclination was to think that this should be handled with the
>   WORDCHARS variable, but of course WORDCHARS adds other characters that
>   are treated as alphanumeric; there's no way to say that upper case
>   letters should -not- be treated as alphanumeric.  I guess I'd prefer a
>   patch that handled wordchar-exlusions more generically (without adding
>   builtins) and I may even look at adding such a thing.
> 
>   For this patch to go into 3.0.6, I'd want PWS to agree that the new ZLE
>   builtins would appear in 3.1.6, too.

I would like to see a lot more flexibility with the WORDCHARS stuff.
I'm constantly finding that M-f and M-b don't do what I want them to,
and I can't get them to behave how I want either.  How about the
option of an emacs-like {forward,backward}-word, which jumps to a
different place depending on which direction you're heading, for
example?

> * Support for the LS_COLORS environment string, to colorize file names in
>   the same contexts where the LIST_TYPES option presently appends various
>   markers ('/' for directories, '@' for symlinks, etc.).  Depends on the
>   terminal having color capability, obviously.
> 
>   The only issue about this one is that it's borrowed from GNU copylefted
>   source.  I don't want to include it without an exemption from the GPL,
>   and Greg doesn't want to pester the FSF about an exemption unless I'm
>   certain to include it; so we're temporarily at an impasse.  If several
>   zsh users say they'd like to see this included, I'll tell Greg to go
>   ahead and request the exemption.

I would /love/ to see this feature.  I've been missing having that in
all the shells I've used.

Adam