Zsh Mailing List Archive
Messages sorted by:
Re: Updating the Xterm title with every execution?
- X-seq: zsh-users 2272
- From: Greg Badros <gjb@xxxxxxxxxxxxxxxxx>
- To: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- Subject: Re: Updating the Xterm title with every execution?
- Date: 31 Mar 1999 15:12:48 -0800
- Cc: zsh-users@xxxxxxxxxxxxxx
- In-reply-to: Sven Wischnowsky's message of "Wed, 31 Mar 1999 13:35:50 +0200 (MET DST)"
- Mailing-list: contact zsh-users-help@xxxxxxxxxxxxxx; run by ezmlm
- References: <199903311135.NAA08267@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Sender: gjb@xxxxxxxxxxxxxxxxx
Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> writes:
> > That's great-- any chance of getting my colorized completion patch in
> > there? It's plenty clean, has it's own option, and is pretty small --
> > it could be a compile-time switch if you're *really* concerned about
> > memory footprint (zsh 3.0.x still does not have any dynamic loading
> > capabilities, does it?). Since 3.0.6 is the end of the road for 3.0,
> > the maintenance headache of another compile-time flag is not an issue.
> The problem I have with this is that it uses an option. In 3.1. I
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.).
> would like to make the code in `zle_tricky.c' use a pointer variable to
> call `listmatches()' to allow stuff like this to be put in a different
> module that may be loaded on top of `compctl'. We can then also add a
> different colourisation module which is a bit more zsh-ish. Probably
> using a assoc array to map patterns/descriptions to strings like
> `%B%n%b' where the `%n' gets replaced by the string (of course, the
> best way would be to allow different maps for different completions,
> but we could already use group names for that). Or something like
> that. This should be easy to use because I think that sometime we will
> be able to make modules autoloaded on parameter names (haven't really
> looked for that in the code yet, but every parameter name lookup goes
> through the paramtab-hashtable functions, right?).
Making it more zsh-ish defeats one of the goals which is transparent
interoperability with colorized GNU ls output-- my Zsh patch uses the
same configuration mechanism as that (and the same code, largely).
> Of course, if we add a way to allow modules to define options and make
> modules autoloaded on them, nothing could be said against using a option
Sure, but that's for 3.1, not 3.0.6.
> for it (well, something could be said against it: it's superfluous --
> even in your patch making it use only `ZLS_COLOR' (or turning it into
> an array and giving it a better name) and testing if that is set would
> be enough).
I do not know what you mean use only "ZLS_COLOR". Why is that better
than setopt listcolors?
> Anyway, I don't think that I'll ever use a feature like this and so
> would be against putting it into the zsh core itself. But it's not my
> duty to decide this...
Sure, and it'd be great if 3.0.x had dynamic module support so everyone
could be happy, but for very little space, you get a feature that is
pretty darn useful, and helps zsh interroperate better with one of the
most used commands (ls).
P.S., here's the size difference on an x86 compiled with egcs-1.1.x.
397 -rwxrwxr-x 1 gjb contrib 402882 Feb 9 16:46 zsh-3.0.5*
402 -rwxr-xr-x 2 gjb visitors 407740 Mar 19 18:18 zsh-gjb*
(zsh-gjb includes my patch for both post-prompts and colorized-completion)
Messages sorted by: