zsh-users
 help / color / mirror / code / Atom feed
From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-users@sunsite.auc.dk
Subject: Re: Updating the Xterm title with every execution?
Date: Wed, 31 Mar 1999 13:35:50 +0200 (MET DST)	[thread overview]
Message-ID: <199903311135.NAA08267@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: Greg Badros's message of 30 Mar 1999 02:27:53 -0800


Greg Badros wrote:

> "Bart Schaefer" <schaefer@brasslantern.com> writes:
> 
> > } Please correct me if I'm wrong, but I don't think 'preexec' exists in
> > } Zsh 3.0.5
> > 
> > It's in 3.0.5-ext-2, available from ftp.brasslantern.com:/pub/zsh/, which
> > will be the basis of 3.0.6 appearing (I hope, if I get the archive scripts
> > learned soon) sometime this month.
> 
> 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
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?).

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
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).

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...

Bye
 Sven

P.S.: Module-defined options may also be an argument for moving to a
      assoc array based option system.

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de


             reply	other threads:[~1999-03-31 11:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-03-31 11:35 Sven Wischnowsky [this message]
1999-03-31 23:12 ` Greg Badros
  -- strict thread matches above, loose matches on Subject: below --
1999-04-12  8:08 Sven Wischnowsky
1999-04-01  7:19 Sven Wischnowsky
1999-04-02  1:57 ` 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=199903311135.NAA08267@beta.informatik.hu-berlin.de \
    --to=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).