PATCHlet: was: Re: Questions (and PATCH: small change to _complete)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx