From: Greg Badros <gjb@cs.washington.edu>
To: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
Cc: zsh-users@sunsite.auc.dk
Subject: Re: Updating the Xterm title with every execution?
Date: 01 Apr 1999 17:57:57 -0800 [thread overview]
Message-ID: <qrrzp4rpyvu.fsf@elwha.cs.washington.edu> (raw)
In-Reply-To: Sven Wischnowsky's message of "Thu, 1 Apr 1999 09:19:51 +0200 (MET DST)"
Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:
> Greg Badros wrote:
>
> > Why is an option a problem? It's cleaner to use an option then to have
> > it be only a compile-time flag. There are plenty of other options
> > affecting completion (listambiguous, listtypes, menucomplete, etc.).
>
> Obviously I wasn't clear enough... I have no objections to put that
> into 3.0.6. But I wouldn't like to see an option to be used for it
> because people would then expect this option to be in 3.1x, too. And
> since I wouldn't like to see a feature as specific as this to be in
> the standard completion module and because modules currently can't
> define their own options, we would have to put it into the core.
> With the modules in 3.1. it would be easy to put enhancements like
> this one into separate modules, which, as I hope you agree, is much
> cleaner.
Ah, yes... now this makes much more sense to me. Though why can't
executing a setopt load a module (as invoking a function loads that
function)? Similarly, I've wanted this for completion controls, too --
scanning all my completion stuff takes forever at startup-- it'd be nice
to have them autoloaded when I first try to complete (ignorance warning:
I've not been following the 3.1.x discussion on completion stuff so
maybe people are working on this or something similar).
<snip>
>
> I hope this is clear now -- backward-compatibility. And you don't need
> the option if you make your patch alwasy use the parameter
> `ZLS_COLOUR' (or whatever) and turn on colours only if that parameter
> is set. The name should be seldom enough to not interfere with any
> existing parameter name.
This seems reasonable, and I'd be glad to make the colorized completion
stuff work as you suggest so as to not burden the 3.1 implementation
unnecessarily.
Thanks for your clarification.
Greg
next prev parent reply other threads:[~1999-04-02 1:58 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-04-01 7:19 Sven Wischnowsky
1999-04-02 1:57 ` Greg Badros [this message]
-- strict thread matches above, loose matches on Subject: below --
1999-04-12 8:08 Sven Wischnowsky
1999-03-31 11:35 Sven Wischnowsky
1999-03-31 23:12 ` Greg Badros
1999-03-25 20:15 Ryan Tennant
1999-03-25 21:29 ` Larry P . Schrof
1999-03-25 21:40 ` Matthew Lovell
1999-03-25 21:55 ` Greg Badros
1999-03-25 22:09 ` Larry P . Schrof
1999-03-25 22:47 ` Greg Badros
1999-03-30 4:25 ` Bart Schaefer
1999-03-30 7:56 ` Andrej Borsenkow
1999-03-30 10:27 ` Greg Badros
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=qrrzp4rpyvu.fsf@elwha.cs.washington.edu \
--to=gjb@cs.washington.edu \
--cc=wischnow@informatik.hu-berlin.de \
--cc=zsh-users@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).