zsh-workers
 help / color / mirror / code / Atom feed
* Re: compctl -Tx 'w[0,...] ...' ...
@ 1997-09-30  6:44 Sven Wischnowsky
  0 siblings, 0 replies; 3+ messages in thread
From: Sven Wischnowsky @ 1997-09-30  6:44 UTC (permalink / raw)
  To: zsh-workers


"Bart Schaefer" wrote:

> ...
> 
> What I want is a completion that applies to *all* commands, as do -D and
> -T, but that is triggered *after* any other completion provided for any
> specific command.  I guess I could get the effect by altering every other
> completion I ever define to end with the "continue using default" switch;
> but that means keeping my own edited copies of all the examples from the
> zsh dist, etc.
> 

(That's what I meant.)

After implementing the `+' style completion and using it for some time
I was thinking about adding a option for automatically using `-D'
completion if everything failed. But then Bas described how he got
used to using `+' at the end of almost all his compctls and noone
really complained about missing such a feature. It was quite easy to
implement (and I even had it in one of my private version), but it was
the time when many people were saying things like `let's keep zsh
small, no more options, ...', so I hesitated to suggest it.

>
> ... (using pattern matching to select a compctl) ...
> 
> I'm pretty sure I requested it myself ... an example would be to set up a
> compctl so that every command matching `x*' would accept the standard X
> toolkit completions (-display, -xrm, etc.).  The reason it might be hard
> is because you could end up with multiple different compctl lines that
> match the same command:
> 
> compctl -k '(-display -geometry -xrm)' x*
> compctl -k hosts xhosts
> 
> How would the ambiguity be resolved?
> 

(Maybe your request just failed to wake me up...)

Still I think it wouldn't be too hard to implement. The code already
has some `if no matches found, try again with...' in it. So the above
would turn into: try to find the command name in the compctl
hashtable, if it can't be found, just look at all hashtable entries
(optimised to use only entries with patterns, determined at definition
time), see if they match the current command name and if they do, try
them to produce matches. This could also be used to try multiple
pattern-compctls until one produces matches, whereas the `-Tx W[..]'
thing would only use the flags of the first matching `W[...]'.
One problem may be that the compctls are (of course) in no particular
order...


Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: compctl -Tx 'w[0,...] ...' ...
  1997-09-29  6:29 Sven Wischnowsky
@ 1997-09-30  4:57 ` Bart Schaefer
  0 siblings, 0 replies; 3+ messages in thread
From: Bart Schaefer @ 1997-09-30  4:57 UTC (permalink / raw)
  To: Sven Wischnowsky, zsh-workers

On Sep 29,  8:29am, Sven Wischnowsky wrote:
} Subject: Re:  compctl -Tx 'w[0,...] ...' ...
}
} "Bart Schaefer" wrote:
} > 
} > Now you may be wondering, what's the point of all this?  Well, at first it
} > was just a desire to have something like compctl -T but that kicked in only
} > after everything else failed.  (You can almost get this with -D, but only
} > for commands that don't already have some other completion.)
} 
} Hm, using flags before a `-x' or `+' with no flags following it
} (continue with default completion) aren't enough?

I don't completely understand the question, I'm afraid.

What I want is a completion that applies to *all* commands, as do -D and
-T, but that is triggered *after* any other completion provided for any
specific command.  I guess I could get the effect by altering every other
completion I ever define to end with the "continue using default" switch;
but that means keeping my own edited copies of all the examples from the
zsh dist, etc.

} Could I get an example, please?

The example I was thinking of was

compctl -Tx 'n[1,=]' -f

That says to complete file names after the first `=' in any word, for any
command.  Because it's a -T, it gets used *before* something like this:

compctl -x 'C[0,conv=*,*] n[-1,,], s[conv=]' \
        -k '(ascii ebcdic ibm block unblock lcase ucase swap noerror sync)' \
        -q -S ',' -- dd

so then you can't complete conv= in a dd-specific way.  I want 'n[1,=]' -f
to apply to every command, but *after* the specific completions are tried.

} But I admit that I didn't think of using `-T' with `w[0,...]'...
} 
} > Also, if you convert all your compctls to one big -T like that, then you
} > can replace 'w[0,string]' with 'W[0,pattern]' and get an effect that a few
} > persistent zsh-users have been requesting for some years: pattern matching
} > on the command name when defining a completion.
} > 
} 
} Huh? That wouldn't be that difficult to implement (I think) and I
} don't remember a request for it...

I'm pretty sure I requested it myself ... an example would be to set up a
compctl so that every command matching `x*' would accept the standard X
toolkit completions (-display, -xrm, etc.).  The reason it might be hard
is because you could end up with multiple different compctl lines that
match the same command:

compctl -k '(-display -geometry -xrm)' x*
compctl -k hosts xhosts

How would the ambiguity be resolved?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com


^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re:  compctl -Tx 'w[0,...] ...' ...
@ 1997-09-29  6:29 Sven Wischnowsky
  1997-09-30  4:57 ` Bart Schaefer
  0 siblings, 1 reply; 3+ messages in thread
From: Sven Wischnowsky @ 1997-09-29  6:29 UTC (permalink / raw)
  To: zsh-workers


"Bart Schaefer" wrote:

> 
> What's the difference between
> 
> 	compctl ... -- foo
> 
> and
> 
> 	compctl -Tx 'w[0,foo]' ...
> 
> ??  Aside from the obvious fact that you can use multiple `compctl ...`
> commands but only one `compctl -Tx ...`.
> 
> Take a look at this:
> 
> ...
> 
> The above turns every compctl that doesn't use -x (because -x completions
> can't be nested) into a single huge compctl -T.  (It could probably be
> cleaned up a lot, especially the `stuff' loop for unfolding compctls that
> happen to have embedded newlines e.g. in -k '(...)' lists.)
> 
> With some finagling, it ought to be possible to rewrite all the compctls
> that use -x in a similar manner, eventually reducing the entire collection
> of compctls (except for -C and -D) to one `compctl -T`.
> 
> Now you may be wondering, what's the point of all this?  Well, at first it
> was just a desire to have something like compctl -T but that kicked in only
> after everything else failed.  (You can almost get this with -D, but only
> for commands that don't already have some other completion.)

Hm, using flags before a `-x' or `+' with no flags following it
(continue with default completion) aren't enough? Could I get an
example, please?

> Beyond that,
> though, it suggests that there may be a lot of redundant functionality in
> the completion code, which could without much effort be folded together.
> 

Not that much, only the following lines could be removed:

       else if (linredir ||
                !(cmd &&
                  (((ccp = (Compctlp) compctltab->getnode(compctltab, cmd)) &&
                    (compc = ret = ccp->cc)) ||
                   ((s = dupstring(cmd)) && remlpaths(&s) &&
                    (ccp = (Compctlp) compctltab->getnode(compctltab, s)) &&
                    (compc = ret = ccp->cc)))))

And doing it that way should be faster than the all in one `-T' version.

But I admit that I didn't think of using `-T' with `w[0,...]'...

> Also, if you convert all your compctls to one big -T like that, then you
> can replace 'w[0,string]' with 'W[0,pattern]' and get an effect that a few
> persistent zsh-users have been requesting for some years: pattern matching
> on the command name when defining a completion.
> 

Huh? That wouldn't be that difficult to implement (I think) and I
don't remember a request for it...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1997-09-30  6:57 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1997-09-30  6:44 compctl -Tx 'w[0,...] ...' Sven Wischnowsky
  -- strict thread matches above, loose matches on Subject: below --
1997-09-29  6:29 Sven Wischnowsky
1997-09-30  4:57 ` Bart Schaefer

Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).