From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: _diff (new), _prcs (upgrade)
Date: Fri, 28 Jan 2000 11:25:22 +0100 (MET) [thread overview]
Message-ID: <200001281025.LAA20330@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Alexandre Duret-Lutz's message of 28 Jan 2000 10:49:54 +0100
Alexandre Duret-Lutz wrote:
> ...
>
> I rethought about it this morning, and while I have not changed my idea, I
> can describe it differently. My opinion is: we should write $(XXX) if
> we are in the completion function for XXX, and $(command XXX) otherwise.
> In the former case, we really need to see what the user is actually running,
> in order to not complete for the wrong command (that's the case in _diff,
> I think); in the later case we need to call a command directly in order
> to get unaltered result (case of the call to ps in _pids).
But then a hackishly written function may still break everything (if
you have a function for diff that actually does something if invoked
with zero or only one argument, for example).
> Sven> Actually, I wasn't too sure about _pids either... the problem is that
> Sven> some users may have functions for ps, diff, and so on that may give
> Sven> completely different results when invoked in the way we invoke them.
>
> Sven> Hm. maybe we should try to solve this in a generic manner by writing a
> Sven> function that is called in such cases, like:
>
> Sven> _call <name> [ <how> ]
>
> Sven> (i.e. we use `$(_diff ps)', `$(_call ps list)' and so on).
>
> $(_call diff version)?
No, I wasn't clear enough. I meant that any arguments one normally
wants to give to the command would come after the <how>:
$(_call diff -v </dev/null)
or
$(_call diff -- -v </dev/null)
The <how> was meant for cases where we want to invoke the command more
than once, for different purposes (e.g. we call ps to get the pids and to
get the lines to display).
So the style would only be used to get the command (including: how it
should be invoked, i.e. with `command' or not) and any options the
user wants to give to it. If the style is not set we use some standard
way, so we don't have to set up default styles for this.
> ...
>
> Another point about the $+functions[<name>] test: what if I am writting a
> completion function for a shell function? say I need to call it, how do I
> do?
Good point. Also testing $+commands and $+builtins might help here,
but could still be wrong. Hm, I just wanted to make this cleverer but
since the style would allow one to override it anyway, we should
probably just call it without any pre-command modifier in the default
case. Or let _call accept options like -c and -b to say that the
default should use `command' or `builtin'. Maybe the <how> should be
given with a option, too.
So we would have:
_call -h pids -c ps -> command ps
_call -h list -c ps -> command ps
_call diff -- -v < /dev/null -> diff -v (the <... is in the caller)
and the user can set
zstyle '...:ps-pids' command-line ps -e -o pid
zstyle '...:ps-list command-line ps -e -o pid,command
zstyle '...:diff' command-line command diff
(in the last case _call would stick the -v after the diff)
Does this sound sensible?
Bye
Sven
--
Sven Wischnowsky wischnow@informatik.hu-berlin.de
next reply other threads:[~2000-01-28 10:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-01-28 10:25 Sven Wischnowsky [this message]
2000-01-28 15:04 ` Alexandre Duret-Lutz
-- strict thread matches above, loose matches on Subject: below --
2000-01-31 9:09 Sven Wischnowsky
2000-01-28 15:11 Sven Wischnowsky
2000-01-28 16:24 ` Alexandre Duret-Lutz
2000-01-28 8:26 Sven Wischnowsky
2000-01-28 9:49 ` Alexandre Duret-Lutz
2000-01-27 16:08 Sven Wischnowsky
2000-01-27 17:21 ` Alexandre Duret-Lutz
2000-01-29 8:49 ` Alexandre Duret-Lutz
2000-01-27 14:52 Alexandre Duret-Lutz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200001281025.LAA20330@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).