Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Updating the Xterm title with every execution?

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: Reverse Date, Date, Thread, Author