From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18105 invoked from network); 6 Jun 1999 13:36:25 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 6 Jun 1999 13:36:25 -0000 Received: (qmail 3211 invoked by alias); 6 Jun 1999 13:36:10 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 2357 Received: (qmail 3204 invoked from network); 6 Jun 1999 13:36:10 -0000 Date: Sun, 6 Jun 1999 14:36:05 +0100 From: Adam Spiers To: zsh-users@sunsite.auc.dk Subject: Re: Call for opinions on a couple of prospective zsh patches Message-ID: <19990606143605.B23915@thelonious.new.ox.ac.uk> Reply-To: Adam Spiers Mail-Followup-To: zsh-users@sunsite.auc.dk References: <990606065150.ZM9165@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <990606065150.ZM9165@candle.brasslantern.com>; from Bart Schaefer on Sun, Jun 06, 1999 at 06:51:50AM +0000 Bart Schaefer (schaefer@candle.brasslantern.com) wrote: > Greg Badros 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