Re: Updating the Xterm title with every execution?

[Greg Badros <gjb@xxxxxxxxxxxxxxxxx>]

Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx> 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