From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11742 invoked from network); 26 Nov 1999 08:46:24 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 26 Nov 1999 08:46:24 -0000 Received: (qmail 25404 invoked by alias); 26 Nov 1999 08:46:16 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8787 Received: (qmail 25394 invoked from network); 26 Nov 1999 08:46:14 -0000 Date: Fri, 26 Nov 1999 09:46:13 +0100 (MET) Message-Id: <199911260846.JAA14199@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Thu, 25 Nov 1999 19:39:53 +0000 Subject: PATCHlet: was: Re: Questions (and PATCH: small change to _complete) The patch below just fixes three thinkos (avoid to prepend the completer name to the context if there is alredy a suitable setting and save/restore $curcontext in _main_complete) and one typo... Bart Schaefer wrote: > On Nov 25, 10:54am, Sven Wischnowsky wrote: > } Subject: Re: Questions (and PATCH: small change to _complete) > } > } I wrote: > } > } > When completing in command position, _normal appends `-complete-' to > } > the context name (e.g. `:complete:-command-'). This is fine. When > } > completing arguments of commands, however, it only appends the command > } > name (e.g. `:complete:dvips'). I'm a bit worried that someday we will > } > find out that we have used a tag name that is also the name of a > } > command and then it's non-trivial to write a compstyle-pattern that > } > correctly matches only the command name. > } > } Ouch ;-) There was already the cvs tag. > } > } For now this patch makes command names be preceded and followed by two > } colons. I.e. to unambiguously match the command name you can now do > } `*::cvs:*' and to test for a command/tag combination: `*::command:*:tag'. > > This only solves the problem in one direction, doesn't it? That is, now > you can tell that tag is not a command name, but how do you tell that a > command name is not a tag? > > What I mean is, if testing "*:cvs:*" to find the cvs tag, but the context > is "...::cvs::..." because the command name is "cvs", then the tag branch > is going to be taken because "*:cvs:*" matches both "::cvs::" and ":cvs:". > It's a pain to have to test "*[^:]:cvs:*" just to be sure, especially > since that won't match if "cvs" is the first thing in the context (or is > that impossible for a tag name?). The tag name is always the *last* component (and there is always only one). In fact, it isn't really part of the context name stored in $curcontext. It is only temporarily appended to that in _style to match the style patterns defined. And of course, in _sort_tags the tags are not appended at all, because that function decides which ones are to be used. Maybe I should try to make this clearer in the docs, although I already tried to do that in this double-colon patch. > } And I forgot to say that before the next release we should make sure > } that we set up good defaults for styles and probably improve the > } default _sort_tags. But I think this should really be done at the end. > > I still need some good examples of styles. As I mentioned before, I'd > never done much with compconf, so I didn't have anything for the "new" > compconf to convert into styles. Consequently, I'm now back almost to > the bottom of the learning curve in understanding exactly what I can or > might want to do, and how. compinit already sets up a few default styles, trying to make things behave almost in the same way as it did before (especially for people like you who had no or only few compconfig's). Well, otherwise, the docs are up-to-date. You can set prefered host, user, group and port names and combinations thereof, as in: compstyle '*::rlogin:*' users-hosts user1:host1 user2:host2 ... We have the new style that says if you complete job-names instead of job-numbers (this is a boolean style; and this uses a pattern that matches only the tag, btw.): compstyle '*:jobs' strings yes And there are the styles for the completers saying how many errors to accept (for correction), if the original string should be shown (for correction and exapnsion). And, of course, the completer style. This one also shows one nice difference to the config stuff. There we had a bunch of *_completer keys for normal completion, prediction, incremental completion. Now we have only one style, the rest is done using appropriate patterns: compstyle '*' completer _complete _correct _approximate compstyle ':incremental*' completer _complete _correct compstyle ':predict*' completer _complete The mechanism that `sorts' pattern (i.e. makes more specific patterns be tried first) automatically ensures that for these patterns the right completer setting will be chosen. A similar cleanup happened with all these correct_* vs. approximate_* vs correctword_* keys. Now there are only the styles (like `original') and the pattern determines which setting is used: compstyle ':correct' max-errors 2 numeric compstyle 'correct-word' max-errors 2 numeric (These styles are tested without appending a tag name. Mainly because I couldn't think of a good one.) The one that has changed most is `verbose', formerly known as `description'. It is now also used to decide if things like processes, jobs and dirstack-entries should be listed only as numbers or with the text that previously was the default (and because of that, setting this to true is one of the defaults I added to compinit). My favorite styles are probably: compstyle '*:descriptions' format '%B--------- %d:%b' compstyle '*:messages' format '%B%U--------- %d%u%b' compstyle '*:warnings' format '%B%U--------- no match for: %d%u%b' compstyle '*:matches' group 'yes' compstyle '*:options' auto-description 'specify %d' (`Favorite' in the sense that I `see' them more often then other styles.) If you don't like the output style this defines, then this probably proves that having this configuarable is good. Bye Sven diff -u -r oldcompletion/Core/_approximate Completion/Core/_approximate --- oldcompletion/Core/_approximate Wed Nov 24 17:06:53 1999 +++ Completion/Core/_approximate Fri Nov 26 09:36:05 1999 @@ -17,7 +17,7 @@ [[ "${#:-$PREFIX$SUFFIX}" -le 1 ]] && return 1 -[[ "$curcontext" != *:correct ]] && curcontext="${curcontext}:approximate" +[[ "$curcontext" != *:correct* ]] && curcontext="${curcontext}:approximate" oldcontext="$curcontext" diff -u -r oldcompletion/Core/_correct Completion/Core/_correct --- oldcompletion/Core/_correct Wed Nov 24 17:06:53 1999 +++ Completion/Core/_correct Fri Nov 26 09:36:33 1999 @@ -8,7 +8,9 @@ # Supported configuration keys are the same as for `_approximate', only # starting with `correct'. -local ret=1 opm="$compstate[pattern_match]" curcontext="${curcontext}:correct" +local ret=1 opm="$compstate[pattern_match]" curcontext="${curcontext}" + +[[ "$curcontext" != :correct* ]] && curcontext="${curcontext}:correct" compstate[pattern_match]='-' diff -u -r oldcompletion/Core/_expand Completion/Core/_expand --- oldcompletion/Core/_expand Wed Nov 24 17:06:53 1999 +++ Completion/Core/_expand Fri Nov 26 09:24:17 1999 @@ -8,7 +8,9 @@ # word from the line. local exp word="$PREFIX$SUFFIX" group=-V expl expl2 disp orig menu prompt -local curcontext="${curcontext}:expand" expr descr +local curcontext="${curcontext}" expr descr + +[[ "$curcontext" != :correct* ]] && curcontext="${curcontext}:correct" # First, see if we should insert all *completions*. diff -u -r oldcompletion/Core/_main_complete Completion/Core/_main_complete --- oldcompletion/Core/_main_complete Wed Nov 24 17:06:53 1999 +++ Completion/Core/_main_complete Fri Nov 26 09:32:35 1999 @@ -18,7 +18,7 @@ local comp post ret=1 _compskip _prio_num=1 _cur_context format -local context state line opt_args val_args curcontext +local context state line opt_args val_args curcontext="$curcontext" typeset -U _offered_tags _tried_tags _failed_tags _used_tags _unused_tags _offered_tags=() -- Sven Wischnowsky wischnow@informatik.hu-berlin.de