Re: wish for a colored completion system

Re: wish for a colored completion system

[Matthias Kopfermann]

Okay, after having heard the answer that there is the possibility
to have colored completion, has anybody used it to create useful
completions with colors in them to share with us all?
There is not one example but the very easy to handle 
ZLS_COLOURS case for completing different kinds of files.
To me it still seems to be quite complex to say the least.

Okay, I try to be not so polite: :)
Should'nt there be an easier way than that approach?

Re: wish for a colored completion system

[Sven Wischnowsky]

Matthias Kopfermann wrote:

> Okay, after having heard the answer that there is the possibility
> to have colored completion, has anybody used it to create useful
> completions with colors in them to share with us all?
> There is not one example but the very easy to handle 
> ZLS_COLOURS case for completing different kinds of files.
> To me it still seems to be quite complex to say the least.
> 
> Okay, I try to be not so polite: :)
> Should'nt there be an easier way than that approach?

It's the normal way of configuring things for the new completion
system and I definitely think colouring should be done like all other
setup for it. The `=pat=col' syntax was partly chosen because we
(well, some people here) wanted the possibility to use their $LS_COLOR
for zsh, too. That left us not too many syntax extensions to use.

Hm, how should we supply good examples for something depending so much 
on personal preference. One thing you can try is using similarities in 
the completion lists, like the ` -- ' thing used for descriptions:

  zstyle ':completion:*:(jobs|directory-stack|indexes|option|values)' list-colors \
      '=(#b)(*) -- (*)=35;1=31=33'

More examples? These show another problem: the patterns often depend
on the output format of certain system commands like ps(1) and lpq(1):

  zstyle ':completion:*:processes' list-colors \
      '=(#b)( #[0-9]#) ??????[^0-9]##([0-9]##:[0-9][0-9][.:][0-9][0-9])(*)=35=31;1=32=33'
  zstyle ':completion:*::lp*:jobs' list-colors \
      '=(#b)* [0-9] ##([^ 	]##) ##([^ 	]##) ##([^ 	]##) ##(*)=35=32=31;1=33=32'

And we can't do anything about that...

Other things one might want to highlight are the descriptions (see the 
`format' style) and probably `special' types of matches, like
`warnings', `all-expansions', `original' etc. Oh, and, of course, the
`ma' capability when using menu-selection.

Bye
 Sven

P.S.: You'll certainly get other colours because I don't use a
      colour-xterm.

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

Re: wish for a colored completion system

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 2625 bytes --]

On Thu, Jun 08, 2000 at 04:34:37PM +0200,
Matthias Kopfermann <kopfermann@trio-hittfeld.de> wrote:
> 
> Okay, after having heard the answer that there is the possibility
> to have colored completion, has anybody used it to create useful
> completions with colors in them to share with us all?
> There is not one example but the very easy to handle 
> ZLS_COLOURS case for completing different kinds of files.
> To me it still seems to be quite complex to say the least.

Well... I have a bit of stuff for ssh, but not too much else:

setopt autolist
ZLS_COLOURS="no=36;40:fi=36;40:di=32;40:ln=36;40:pi=31;40:so=22;40:bd=44;37:cd=44;37:ex=35;40:mi=36;40:lc=\e[:rc=m:ec=:mi=37;41"
export ZLS_COLOURS
LS_COLORS=$ZLS_COLOURS
export LS_COLORS
ZLS_COLOURS="$ZLS_COLOURS:(hosts)=(#b)(*).(mayn.de)=36;40=31;40" # real fun
ZLS_COLOURS="$ZLS_COLOURS:(hosts)=*=33;40" # hostnames in yellow
ZLS_COLOURS="$ZLS_COLOURS:(users)=*=32;40" # users in green
export ZLS_COLOURS

#       no 0   for normal text  (i.e.  when  displaying  something
#              other than a matched file)
#       fi 0   for regular files
#       di 32  for directories
#       ln 36  for symbolic links
#       pi 31  for named pipes (FIFOs)
#       so 33  for sockets
#       bd 44;37
#              for block devices
#       cd 44;37
#              for character devices
#       ex 35  for executable files
#       mi none
#              for non-existent file (default is the value defined
#              for fi)
#       lc \e[ for the left code (see below)
#       rc m   for the right code
#       ec none
#              for the end code
autoload -U compinit
compinit
zstyle ':completion:*' completer '_complete' '_correct' '_approximate'

zmodload complist
# ( in my .zshrc, there are more hosts ;-)
zstyle '*'  hosts 'imbus.mayn.de' 'datenbus.mayn.de' 'willkuere.informatik.uni-wuerzburg.de' 'picard.franken.de'
zstyle '*'  users thomas tkoehler koehlert jean-luc root captain
zstyle ':completion:*' group-name ''


> Okay, I try to be not so polite: :)
> Should'nt there be an easier way than that approach?

Well - at first, it seems not too obvious that there are predefined
names for "normal file", "directory", "symbolic link" etc, but none for
things like "hostnames", "usernames" etc...

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

RE: wish for a colored completion system

[Matthias Kopfermann]

i guess, my problem is that `ZLS_COLORS' reminds me too much on
`ls'. It's perhaps only a matter of getting used to it.

have to get used to the new zstyle thingy!

[Matthias Kopfermann]

Ah, i guess, i thought, that ZLS_COLOURS had to have
all the entries for the new color completion to be avaiable.
That was my mistake. Okay, until yesterday i was a
3.1.6 user so i have to get used to many new things now that 
i have the 3.1.9.
So it is no design-error. It's just my difficulty to learn 
more in less time :)

Sorry for that!

Matthias, a very happy ZSH-user just lost in the world of
information.

Re: wish for a colored completion system

[Bart Schaefer]

Gee, it's hard to have these discussions when the rest of you are all
seven to nine hours ahead of me.

On Jun 8, 12:41pm, Sven Wischnowsky wrote:
} Subject: Re: wish for a colored completion system
}
} Bart Schaefer wrote:
} 
} > The tricky bit is figuring out what string goes at the tail of the style
} > pattern, e.g. `zsh-options' in this case.  The place to look is the
} > "Standard Tags" subsection in the "Completion System Configuration"
} > chapter.
} 
} Or hit ^Xh (control-x h) and it will tell you (the `tags').

Specifically, type the thing you want to complete after, then hit <C-x h>.

For some reason I was thinking the tags only showed up in the verbose
output, but it's the _styles_ that you can get with <ESC 2 C-x h>.

On Jun 8,  2:44pm, Matthias Kopfermann wrote:
}
}  the only problem with it, it is not simple nor is it obvious :(

You want simple, or you want programmable?

On Jun 8,  4:31pm, Matthias Kopfermann wrote:
}
} Okay, I try to be not so polite: :)
} Should'nt there be an easier way than that approach?

That approach was designed to make it easy to use your existing GNU "ls"
color options for coloring files in zsh.  Easy for one thing, hard for
some others.

On Jun 8,  4:49pm, Sven Wischnowsky wrote:
} 
} It's the normal way of configuring things for the new completion
} system and I definitely think colouring should be done like all other
} setup for it.

I think Matthias was referring to the colon-separated-list of attr=val
pairs where the val is a series of semicolon-seprated numbers, rather
than to the entire zstyle mechanism.  Though I admit contexts can look
a little daunting as well.

On Jun 8,  4:50pm, Thomas Köhler wrote:
}
} Well - at first, it seems not too obvious that there are predefined
} names for "normal file", "directory", "symbolic link" etc, but none for
} things like "hostnames", "usernames" etc...

That's just because GNU "ls" predefined the tokens for file types ahead
of us, and we borrowed them.  We wanted to use something less cryptic
(i.e., the group names in parens) for zsh competion "types."

On Jun 8,  5:11pm, Matthias Kopfermann wrote:
}
} i guess, my problem is that `ZLS_COLORS' reminds me too much on
} `ls'. It's perhaps only a matter of getting used to it.

I think you can see why it reminds you of "ls".

On Jun 8,  5:32pm, Matthias Kopfermann wrote:
}
} So it is no design-error. It's just my difficulty to learn 
} more in less time :)

Dogbert once said:
 Information is gushing toward your brain like a firehose aimed at a
 teacup.  Even the smartest among you has become "functionally stupid."

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wish for a colored completion system

[Fletch]

>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:

[...]

    Bart> Specifically, type the thing you want to complete after,
    Bart> then hit <C-x h>.

    Bart> For some reason I was thinking the tags only showed up in
    Bart> the verbose output, but it's the _styles_ that you can get
    Bart> with <ESC 2 C-x h>.

        OK, I'm trying to colourize hostnames for ssh.  So I type:

ssh l<Cx-h>

        And I get:

tags in context :completion::complete:ssh::
    argument-1 options  (_arguments _ssh _ssh)
tags in context :completion::complete:ssh:argument-1:
    hosts users  (_alternative _ssh _ssh) 
    hosts        (_hosts _combination _ssh_hosts _alternative _ssh _ssh) 
    users        (_users _combination _ssh_users _alternative _ssh _ssh)


        What tag should I use?  I've tried the following with no
success: 

zstyle ':completion:*:*:ssh:*:hosts' list-colors '=lemur*=01;32'
zstyle ':completion::complete:ssh:*:hosts' list-colors '=lemur*=01;32'
zstyle '*:hosts' list-colors '=lemur*=01;32'


        If I set something in ':completion:*' list-colors it works,
but I'm betting I'm just not understanding how styles are being
matched.

-- 
Fletch                | "If you find my answers frightening,       __`'/|
fletch@phydeaux.org   |  Vincent, you should cease askin'          \ o.O'
678 443-6239(w)       |  scary questions." -- Jules                =(___)=
                      |                                               U

Re: wish for a colored completion system

[Bart Schaefer]

On Jun 8,  3:39pm, Fletch wrote:
> 
>         If I add '=lemur*=01;32' to ':completion:*' list-colors it
> works fine (ssh l<C-d> produces three highighted lemur* and plain
> localhost and lp).  

Aha!  You have host names and user names listed simultaneously.

Add this:

zstyle ':completion:*' group-name ''

That will make two sub-lists, one of host names and one of user names,
and then you'll get the colors in the host names.

I'm not sure why ':completion:*:ssh:*' doesn't work for the combined
listing; perhaps it's a bug.  Sven?

Re: wish for a colored completion system

[Fletch]

>>>>> "Bart" == Bart Schaefer <schaefer@candle.brasslantern.com> writes:

    Bart> On Jun 8, 3:39pm, Fletch wrote:
    >>  If I add '=lemur*=01;32' to ':completion:*' list-colors it
    >> works fine (ssh l<C-d> produces three highighted lemur* and
    >> plain localhost and lp).

    Bart> Aha!  You have host names and user names listed
    Bart> simultaneously.

    Bart> Add this:

    Bart> zstyle ':completion:*' group-name ''

    Bart> That will make two sub-lists, one of host names and one of
    Bart> user names, and then you'll get the colors in the host
    Bart> names.

        That indeed fixes it.  Perhaps there should be a compinstall
option under `display and insertion options' to toggle this behavior
(or maybe make it set by default)?

-- 
Fletch                | "If you find my answers frightening,       __`'/|
fletch@phydeaux.org   |  Vincent, you should cease askin'          \ o.O'
678 443-6239(w)       |  scary questions." -- Jules                =(___)=
                      |                                               U

Re: wish for a colored completion system

[Peter Stephenson]

Fletch wrote:
>     Bart> zstyle ':completion:*' group-name ''
> 
>         That indeed fixes it.  Perhaps there should be a compinstall
> option under `display and insertion options' to toggle this behavior
> (or maybe make it set by default)?

There is, pick the first item,

1.  Change appearance of completion lists:  allows descriptions of
    completions to appear, sorting of different types of completions,
    and scrolling of completion lists.

and the second option the next menu,

2.  Make different types of completion appear in separate lists.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>
Work: pws@CambridgeSiliconRadio.com
Web: http://www.pwstephenson.fsnet.co.uk

Re: wish for a colored completion system

[Matthias Kopfermann]

> On Jun 8,  2:44pm, Matthias Kopfermann wrote:
> }
> }  the only problem with it, it is not simple nor is it obvious :(
> 
> You want simple, or you want programmable?
hmm, that is one of the more difficult questions to ask.
I guess, I would like medium programmability. :)
Reminds me on something:
i love vim but i had to get used to the color-programming, in
elvis (another vi-clone) it was much, much simpler but not at all
powerful.
I guess: I would very much like the shell to train me in doing it
manually so when i know i can do the programming much quicker.
Something like a interactive tutorial.
You know , like for vi or emacs.
(" Now try to get the colors right.
First: What command do you want to be completed? ...")
Or: What about a nice Gui-Interface (tcsh has it for
completion) or a dialog-script that helps me do a whole set of
completion-algorithms? I would be very satisfied, because it
would reduce my steep learning curve.
reading -> translating ( in my case ) -> understanding ->
programming.
Sometimes i think the
getting-used-to-it takes longer than the whole effect of
usibility  (but that may be my problem only because i -hate to
say it - i am slooow!.)
> 
> That approach was designed to make it easy to use your existing GNU "ls"
> color options for coloring files in zsh.  Easy for one thing,
and that IS easy, right!
> hard for
> some others.
At first I thought, the approach was not general enough. but then again:
The more general the more complicated , it seems.
Handcoding is great if knowledge is there. But in my case it
would dramatically increase my knowledge if there was a tool to
help me get it right and be trained and then i could study the whole output and
do the whole thing manually much quicker.
I love to be able to do it manually. And i really love to be able
to work with unix ( linux in my happy case ) 
_without_ using graphical interfaces, really. 
But normally all these powerful tools don't come with easy to
follow instructions how to make it work.
Peter Stephenson has done many very good attempts to change that
with his userguide and I said before that i consider this to be
very, very important and applauded him.

To make a long explanation of my state short:
I would love to have a training tool (software) for many of the wonderful
free software-products and almost nothing is available.
So it takes time. In my case much time that i love to spent but
sometimes i just get frustrated because it takes soo long.

okay, I revealed myself. Many things are personal but i know many
people that feel the same. 
And , because Bart asked , i took the chance to explain it.
Of course this is not at all ZSH-specifig. 
Is it off-topic?

Matthias

Re: Fun zsh trick for today

[Matthias Kopfermann]

On Sat, Jun 10, 2000 at 10:50:51PM +0000, Bart Schaefer wrote:
>[ ... amazing information deleted ]

i think, this would be a great feature of the mailinglist, if
bart or sven or some other guru would give such nice tricks once
a week or something.
it makes happy user, at least it made me happy :)

Matthias

Re: Fun zsh trick for today

[Clint Adams]

> i think, this would be a great feature of the mailinglist, if
> bart or sven or some other guru would give such nice tricks once
> a week or something.
> it makes happy user, at least it made me happy :)

I'm no Bart-guru, but here's an application of his trick that I find useful
for the new completion system:

zmodload -i zsh/mapfile
hosts=(${(@)${(@)${(M)${(f)mapfile[$HOME/.ssh/known_hosts]}:#[^0-9]*}%%\ *}%%,*})
zstyle ':completion:*:hosts' hosts $hosts

Re: Fun zsh trick for today

[Ollivier Robert]

According to Clint Adams:
> zmodload -i zsh/mapfile
> hosts=(${(@)${(@)${(M)${(f)mapfile[$HOME/.ssh/known_hosts]}:#[^0-9]*}%%\ *}%%,*})

<humour>
I'm beginning to see zsh turning up into perl-sh... :-)
</humour>
-- 
Ollivier ROBERT -=- Eurocontrol EEC/TEC -=- roberto@eurocontrol.fr
The Postman hits! The Postman hits! You have new mail.

Re: Fun zsh trick for today

[Fletch]

>>>>> "Ollivier" == Ollivier Robert <roberto@eurocontrol.fr> writes:

    Ollivier> According to Clint Adams:
    >> zmodload -i zsh/mapfile
    >> hosts=(${(@)${(@)${(M)${(f)mapfile[$HOME/.ssh/known_hosts]}:#[^0-9]*}%%\
    >> *}%%,*})

    Ollivier> <humour> I'm beginning to see zsh turning up into
    Ollivier> perl-sh... :-) </humour> 


        Well, I've got a patch off of 3.1.6 that embeds a perl
interpreter as a loadable module and let's you call perl subroutines
as zsh functions . . . :)

        I really need to update it work with 3.1.9, though.

-- 
Fletch                | "If you find my answers frightening,       __`'/|
fletch@phydeaux.org   |  Vincent, you should cease askin'          \ o.O'
678 443-6239(w)       |  scary questions." -- Jules                =(___)=
                      |                                               U

Re: Fun zsh trick for today

[Peter Stephenson]

> I'm no Bart-guru, but here's an application of his trick that I find useful
> for the new completion system:
> 
> zmodload -i zsh/mapfile
> hosts=(${(@)${(@)${(M)${(f)mapfile[$HOME/.ssh/known_hosts]}:#[^0-9]*}%%\ *}%%
> ,*})
> zstyle ':completion:*:hosts' hosts $hosts

In something like this there's really no gain over doing it using more
ordinary zsh methods, i.e. with $(<...), which doesn't require a module.
Plus you don't need all those (@)'s once parameter substitution already has
arrays, which (f) provides.  The only trick here is using double quotes to
get whole lines for splitting.  I think the following should work in 3.0.8
(can't quite remember if the trick of putting double quotes in the middle
made its way back --- if not, put quotes around the lot and put (@)'s at
the front of all the parameter substitutions).

hosts=(${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%,*
})

or

hosts=("${(@)${(@)${(@M)${(@f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%,*
}")

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Fun zsh trick for today

[Peter Stephenson]

I wrote:
> or
> 
> hosts=("${(@)${(@)${(@M)${(@f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%
> ,*
> }")
                                ^                          ^
erk, sorry, remove the double quotes in the middle in this case.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Fun zsh trick for today

[Clint Adams]

> hosts=(${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%,*})

This has the opposite effect as desired (i.e., it returns an array
containing only those entries beginning with digits).  This does what I
want (except for omitting things like 3stop.com):

hosts=(${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[0-9]*}%%\ *}%%,*})

Re: Fun zsh trick for today

[Bart Schaefer]

On Jun 14,  3:15pm, Peter Stephenson wrote:
} Subject: Re: Fun zsh trick for today
}
} Plus you don't need all those (@)'s once parameter substitution already has
} arrays, which (f) provides.  The only trick here is using double quotes to
} get whole lines for splitting.  I think the following should work in 3.0.8
} (can't quite remember if the trick of putting double quotes in the middle
} made its way back

The quotes in the middle is in 3.0.7, as part of the "minimal forwards
compatibility" effort.

There is a small bug with them in both versions, though; you can't take
the length of the quoted part:

zagzig[57] echo ${#"${(f)$(<file)}"}
zsh: bad substitution
zagzig[60] echo ${#${"${(f)$(<ChangeLog)}"}}
8017

It works with ${=...} and ${~...}, but not with ${#...}.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: Fun zsh trick for today

[Matthias Kopfermann]

> 
> hosts=(${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%,*
> })
hu %) Could someone explain these hieroglyphs for a simple soul
like me? %%)

Re: Fun zsh trick for today

[Peter Stephenson]

> > 
> > hosts=(${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[^0-9]*}%%\ *}%%,*
> > })
> hu %) Could someone explain these hieroglyphs for a simple soul
> like me? %%)

that's why this is deferred till (the unwritten) chapter 5 of the user
guide, instead of the chapter on basic syntax...

$(<$HOME/.ssh/known_hosts)

is a standard substitution: it simply takes the file and sticks it onto the
command line at that point.

"$(<$HOME/.ssh/known_hosts)"

Now it's quoted, it doesn't do word splitting; we have the complete file as
one word.  From now on, we do nested substitutions: you just have to
remember that ${${...}}, or ${${...}}, essentially does nothing but an
ordinary parameter expansion --- the whole point is the extra bits tacked
on with each extra set of braces.  For example, we're now going to do

${(f)"$(<$HOME/.ssh/known_hosts)"}

so we get the same answer, but with the effect of putting the (f) flag at
the start, which splits the result of that into lines.  So we now have the
entire file as an array, one line per element.

${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[0-9]*}

(Clint says the ^ shouldn't be there) says take the array elements (= lines
of the original file) which completely match [0-9]*, i.e. elements
beginning with a digit, and remove them, which is what ${...:#...} is for.

${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[0-9]*}%%\ *}

takes the result of that, and strips off from the end the largest pattern
matching ' *', i.e. a space followed by anything else, in other words it
leaves the largest initial string with no whitespace, which is a hostname
(this is a standard ${...%%...} which even ordinary shells do, although not
nested).

${${${${(f)"$(<$HOME/.ssh/known_hosts)"}:#[0-9]*}%%\ *}%%,*}

does another strip at the end, this time for everything from the first
comma on.  If there wasn't a comma, nothing changes.  You could have
combined the last two as ${...%%[[:blank:],]*}, or something.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: Fun zsh trick for today

[Matthias Kopfermann]

On Wed, Jun 14, 2000 at 04:52:10PM +0100, Peter Stephenson wrote:
>  [ ..] #deleted for saving space 

Thanks, peter! That's what i needed to follow.
Nesting makes me quite dizzy but that may be better after some
decades :)

Re: (forw) --help able programs and completion

[Matthias Kopfermann]

On Mon, Jun 26, 2000 at 11:20:20AM +0100, Peter Stephenson wrote:
> not quite sure who's forwarding what to whom here...
I am sorry, I was blind so I made the mistake of sending to the
wrong address :)

Matthias

Re: (forw) --help able programs and completion

[Matthias Kopfermann]

On Mon, Jun 26, 2000 at 11:20:20AM +0100, Peter Stephenson wrote:
> Use compinstall.  I would like feedback, but the format is restricted by
> the fact that it will be written in zsh, so there are menus but no dialogue
> boxes.
Which is really an approach in the right direction. Now my
question is: Where do i find the `--help' completion here?

-- 
And in the end the love you take 
is equal to the love you make
THE BEATLES

Re: is the reference card for zsh still 3.0 ?

[Matthias Kopfermann]

On Thu, Jun 29, 2000 at 12:27:02PM +0100, Peter Stephenson wrote:
> 
> I haven't updated it because it was a lot of work (mostly doing the
> formatting, assembling the info wasn't so hard) and I didn't get a lot of
> messages like this one; it's going back a long time now.  This has at least
> prompted me to recover it in case the old web site goes; I should move it
> to sunsite.auc.dk.
it is at least better than nothing. I took the `mpage -dp'
approach and so was able to reduce the size so it nearly was a
card again. A big one, but what does one expect of a ZSH
reference card ? :)
> Calling it a `card' is probably a breach of the Trades Desriptions Act.
> It's six pages as it is and it's not going to get any shorter.
But consider your marvelous user guide and it's _hundreds_ of pages
when it will be finished. THATS the difference. 
When I consider that and the big, big manual pages which have
20878 lines I guess there is no other chance for an overview.
Okay they have lots of "\n" inside.
 `man zshall | col -b | tr -s "\n" | wc -l' gets me : 14576
 (Is there anybody that loves to do tr -s "\n" in this case? :) )

So i guess it remains to be _necessary_ even if it is no guide.

Matthias

-- 
And in the end the love you take 
is equal to the love you make
THE BEATLES

Re: Matthias Kopfermann: Re: coloring of --help completion possible?

[Matthias Kopfermann]

On Wed, Jul 05, 2000 at 04:52:17AM +0000, Bart Schaefer wrote:
> On Jul 4,  6:17pm, Peter Stephenson wrote:
> }
> } I'm sure Someone knows about this.
oops, me in the subject? what an honor :)
> 
> A second problem is that `l*' and `v*' won't match the name of any
> option.  Options all start with `-', and only options that start with
> `--' are completed by _use_lo, so you probably meant to say
> 
>     zstyle '*:options' list-colors '=--l*=34:=--v*=35'
> 
> Do either of those answers fix things up?
instantly :) hurra, that is what makes free software-use such a
pleasure. it works :) fine, over and out :)

Matthias

Re: wanted: viins-mode and digit argument with a,i,A and such

[Matthias Kopfermann]

On Mon, Jul 17, 2000 at 02:02:21PM +0100, Peter Stephenson wrote:
> I just couldn't be bothered to do
> it the long-winded way.
Yes, that is why i stopped doing it. It is not that important, on
the other hand this really is typical vi-behavior, so it would be
cool, if it was with the standard ZSH.
"Look here, ZSH alone does it right, bash and tcsh can't " :)

Matthias

Re: wanted: viins-mode and digit argument with a,i,A and such

[Peter Stephenson]

> On Mon, Jul 17, 2000 at 02:02:21PM +0100, Peter Stephenson wrote:
> > I just couldn't be bothered to do
> > it the long-winded way.
> Yes, that is why i stopped doing it.

If it can be done in a widget, it probably should be.  The function
interface in 3.1 is now powerful enough that you need a very good reason
for adding something to the basic shell.  We can easily add new zle widget
functions to the distribution which are essentially indistinguishable from
hard-coded functions but don't add to the shell and can be modified.  One
day they may be made more easily configurable along the lines of the new
completion system.

By the way, I said you couldn't do a minibuffer read, but using `zle -R
string...' you can make it look as if you can.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: completion for GNU color ls, anyone?

[Matthias Kopfermann]

On Fri, Jul 21, 2000 at 11:18:11AM +0200, Francis Galiegue wrote:
> On Thu, 20 Jul 2000, Matthias Kopfermann wrote:
> 
> 
> You can just export ZLS_COLORS=$LS_COLORS in your .zshrc or anywhere else, or
> did I completely misunderstand your question?
yes, completely :)
I really want the gnu-linux versions of as many commands as i can
get. This ZLS_COLORS trick is known to me :)
as zsh is not for GNU only (which is good), it does not provide
enough completions for GNU commands.
ls , screen , perl (well sort of GNU :)), emacs completions, vim
and many others are missing. (of course, no ZSH distribution can
have all these commands, that would take 1000's of hours to do
them all, i guess.)

Do we have a place to collect the completions of GNU commands?
That would be cool, I am quite sure.

Re: completion for GNU color ls, anyone?

[Adam Spiers]

Matthias Kopfermann (kopfermann@trio-hittfeld.de) wrote:
> I really want the gnu-linux versions of as many commands as i can
> get. This ZLS_COLORS trick is known to me :)
> as zsh is not for GNU only (which is good), it does not provide
> enough completions for GNU commands.
> ls , screen , perl (well sort of GNU :)), emacs completions, vim
> and many others are missing.

Completions for perl are not missing.  Have you tried a recent
development release?

I might get round to doing screen and emacs soon.  I'm not a vim user
so I won't do that.  ls ... well, that's a different issue.  The
options for ls vary massively over the different systems, so we
probably will need to have a restructuring of the Completion subtree
before this gets completion code.

> (of course, no ZSH distribution can have all these commands, that
> would take 1000's of hours to do them all, i guess.)

Don't underestimate us :-)   We have a completion set which is pretty
impressive complete already ...

Re: completion for GNU color ls, anyone?

[Matthias Kopfermann]

On Fri, Jul 21, 2000 at 12:55:39PM +0200, Sven Wischnowsky wrote:
> But seriously, we already have completion functions for GNU commands
> and if people write new ones and send them to us they will be reviewed 
> and shipped with future versions.
 i know and i am quite happy with many completions. And don't get
 me wrong. I am trying to learn how to do them myself. Perhaps i
 should send my versions and ask questions to understand the
 completion system better. But i am feeling like a Silliest
 Possible User already :)
> The same for non-GNU commands,
> obviously.
I hope so, too.
> So, if anyone has anything interesting...
And what about the ability to have a special site for fg. Linux.
Would that make some sense? I mean i guess that many people would
love a site like that. And that should not be the goal of a
ZSH-distribution to ship with as many completions for Linux as
possible. So perhaps a site dedicated would be cool.
The gurus could then judge what should be included with ZSH
itself. Just an idea for discussion.

Matthias

Re: completion for GNU color ls, anyone?

[Bart Schaefer]

I've created a patch category on the sourceforge.net zsh project for the
submission of new completion functions.

    http://sourceforge.net/patch/?group_id=4068&_category=10305

Subscribers to zsh-workers of course can continue to send new functions
to the list, but we can use sourceforge as a "drop zone" for other new
completions and direct people there (via the FAQ and META-FAQ, perhaps,
but more likely via link on zsh.org) to obtain functions that either are
not in the distribution yet or are too system-specific for inclusion in
the general distribution.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: completion for GNU color ls, anyone?

[Matthias Kopfermann]

setterm would be cool, too. there are 100 's. xterm would be cool
but i guess, i should look into a dev-version. it might already
be there :)

Re: how can one let completion work *inside* zsh scripts?

[Matthias Kopfermann]

On Wed, Jul 26, 2000 at 02:00:11PM +0200, Sven Wischnowsky wrote:
> 
> Then... do you really need a *script*? Or would a function do?
no, as long as it is interactive i don't care. But i was not
thinking of filename completion, more of the ability to let users
easily choose options whatever. Another way is select of course
but i always wanted to know how to be able to do it with little
zsh scripts, too. 
>. If you need something else
> than filename completion, the `offical' way to do that is to (locally)
> define the parameter compcontex and set it to the name of the
> completion context that should be used for completion.
this was new to me. Thanx for explaining!

Matthias

Re: how can one let completion work *inside* zsh scripts?

[Matthias Kopfermann]

> To zsh-workers (and everyone else interested): hm, is this becoming
> FAQish enough to make is simplify it? For example we could allow
> compcontext to be set to `foo()' to make it just call function
> `foo'. And we could allow it to be set to an array and then make
> completion offer its elements as possible completions.
I am for it ! The easier the better. At least normally I
tend to think that way.

Matthias

Re: how can one let completion work *inside* zsh scripts?

[Matthias Kopfermann]

On Thu, Jul 27, 2000 at 03:21:07PM +0200, Sven Wischnowsky wrote:
> 
> But that almost suggest (at least to me, striving for consistency) to
> put everything into a string of the form `<descr>:<action>', where
> <action> is as in _arguments, i.e.:
> 
>   {...}               = evaluate `...'
>   (1 2)               = complete `1' and `2'
>   (( 1\:foo 2\:bar )) = complete `1' and `2' and describe them as
>                         `foo' and `bar' in the list
> 
> Hm, is this going too far? Or should we use the array-based solution
> and allow to give the description with another parameter?
it could be me alone, but i guess that arrays for one and then
parameters with another description would be nice.
perhaps because it is easier for the eye. have problems to have a
series of ::: after each other. (my biggest problem with the new
completion system. thats like using FPATH instead of fpath, i
like the new way that ZSH solves the problem of pathes with an
array. it's not the same here but it still is full of words.)
> Or should we just support compcontext-as-array without (a)
> description(s) (and the `func()' form) and let user's use functions if 
> they need descriptions?
hmm, what do the others think?

wanted: viins-mode and digit argument with a,i,A and such

[Matthias Kopfermann]

hi all!

when i use bindkey -e, i can insert one character 10 times with
ESC 10 <character>.

With vi one normally uses something like 10i<character>.
This is not possible with ZSH ( bindkey -v set ).
One real advantage of bindkey -e here.
Has someone thought about inventing something like it?

(BTW: the bash cannot do it, too. nor can tcsh.)
Until now i just switch to EMACS-mode but of course it would be
something, if this usual vi-behavior was possible.

Matthias

Re: wanted: viins-mode and digit argument with a,i,A and such

[Peter Stephenson]

> hi all!
> 
> when i use bindkey -e, i can insert one character 10 times with
> ESC 10 <character>.
> 
> With vi one normally uses something like 10i<character>.
> This is not possible with ZSH ( bindkey -v set ).
> One real advantage of bindkey -e here.
> Has someone thought about inventing something like it?

If you are using 3.1, try a widget like

read-and-insert-char () {
  local char i bound
  read -k char
  # Use padding trickery to add character multiple times.
  # Expands to something like ${(l.10..j.):-}
  # which means pad to ten characters using the fill character j, but
  # with no parameter, so we end up with pure padding.
  if [[ $char = . ]]; then bound=:; else bound=.; fi
  eval LBUFFER="\"\${LBUFFER}\${(l.${NUMERIC:-1}.${bound}$char${bound}):-}\""
}
zle -N read-and-insert-char
bindkey -M vicmd '^xi' read-and-insert-char

Go to vi command mode, type a number, the key sequence bound to the widget,
then a character, and it will be inserted that many times.

If you want to insert a longer string that many times, you will need to
expand the `read -k char' to a loop which reads a lot of characters until
you get an escape.  (It would be nice to have a minibuffer read for this
sort of thing.)  Then you will need to turn the bit which adds to LBUFFER
into a proper loop --- straightforward, I just couldn't be bothered to do
it the long-winded way.

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: wanted: viins-mode and digit argument with a,i,A and such

[Bart Schaefer]

On Jul 17,  2:02pm, Peter Stephenson wrote:
} Subject: Re: wanted: viins-mode and digit argument with a,i,A and such
}
} > hi all!
} > 
} > when i use bindkey -e, i can insert one character 10 times with
} > ESC 10 <character>.
} > 
} > With vi one normally uses something like 10i<character>.
} > This is not possible with ZSH ( bindkey -v set ).
} 
} If you are using 3.1, try a widget like [...]

I generally agree with the new philosophy of not adding things as builtins
that can be done as widgets, but this is so unbelievably trivial and so
completely general that I have no idea why we shouldn't do it:

Index: Src/Zle/zle_vi.c
===================================================================
@@ -82,6 +82,8 @@
 	vichgbufptr = 1;
 	vichgrepeat = 0;
     }
+    if (zmod.flags & MOD_MULT)
+	prefixflag = 1;
 }
 
 /**/

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wanted: viins-mode and digit argument with a,i,A and such

[Peter Stephenson]

> } > when i use bindkey -e, i can insert one character 10 times with
> } > ESC 10 <character>.
> } > 
> } > With vi one normally uses something like 10i<character>.
> } > This is not possible with ZSH ( bindkey -v set ).
> } 
> } If you are using 3.1, try a widget like [...]
> 
> I generally agree with the new philosophy of not adding things as builtins
> that can be done as widgets, but this is so unbelievably trivial and so
> completely general that I have no idea why we shouldn't do it:

This isn't quite how vi handles it, however.  It would wait till you hit
escape, then insert everything you typed that many times.  That would need
more work.  Plus in zsh there are other ways of exiting insert mode than
returning to command mode --- what should happen on `return'?

-- 
Peter Stephenson <pws@cambridgesiliconradio.com>
Cambridge Silicon Radio, Unit 300, Science Park, Milton Road,
Cambridge, CB4 0XL, UK                          Tel: +44 (0)1223 392070

Re: wanted: viins-mode and digit argument with a,i,A and such

[Bart Schaefer]

On Jul 17,  6:33pm, Peter Stephenson wrote:
} Subject: Re: wanted: viins-mode and digit argument with a,i,A and such
}
} > } > when i use bindkey -e, i can insert one character 10 times with
} > } > ESC 10 <character>.
} > } > 
} > } > With vi one normally uses something like 10i<character>.
} > } > This is not possible with ZSH ( bindkey -v set ).
} > } 
} > } If you are using 3.1, try a widget like [...]
} > 
} > I generally agree with the new philosophy of not adding things as builtins
} > that can be done as widgets, but this is so unbelievably trivial and so
} > completely general that I have no idea why we shouldn't do it:
} 
} This isn't quite how vi handles it, however.

True, but it is how your read-and-insert-char widget handles it.

} It would wait till you hit escape, then insert everything you typed
} that many times. That would need more work.

Yes; I have a vague idea that it could be done by stashing away a copy
of the zmod structure, and then upon ESC you restore it, decrement the
zmult field, and invoke virepeatchange() ... the tricky bit could be
interaction with the `lastmod' copy of zmod that startvichange() uses.
Or maybe lastmod already contains almost everything we need ...

} Plus in zsh there are other ways of exiting insert mode than
} returning to command mode --- what should happen on `return'?

The same thing that happens now when you type e.g. `8 d RET' -- it just
accepts the buffer as it stands, aborting the repeat.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: wanted: viins-mode and digit argument with a,i,A and such

[Thomas Köhler]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]

On Mon, Jul 17, 2000 at 07:34:43PM +0200,
Peter Stephenson <pws@cambridgesiliconradio.com> wrote:
> 
> > } > when i use bindkey -e, i can insert one character 10 times with
> > } > ESC 10 <character>.
> > } > 
> > } > With vi one normally uses something like 10i<character>.
> > } > This is not possible with ZSH ( bindkey -v set ).
> > } 
> > } If you are using 3.1, try a widget like [...]
> > 
> > I generally agree with the new philosophy of not adding things as builtins
> > that can be done as widgets, but this is so unbelievably trivial and so
> > completely general that I have no idea why we shouldn't do it:
> 
> This isn't quite how vi handles it, however.  It would wait till you hit
> escape, then insert everything you typed that many times.  That would need
> more work.  Plus in zsh there are other ways of exiting insert mode than
> returning to command mode --- what should happen on `return'?

the usual thing, plus the characters last inserted being the new
$LBUFFER  - hey, this would be cool (:-)

CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: wish for a colored completion system

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> So for example one can do
> 
> zstyle ':completion:*:zsh-options' \
> 	list-colors '=csh*=31:=*hist*=32:=list*=34:=*glob*=35'
> 
> ...
> 
> The tricky bit is figuring out what string goes at the tail of the style
> pattern, e.g. `zsh-options' in this case.  The place to look is the
> "Standard Tags" subsection in the "Completion System Configuration"
> chapter.

Or hit ^Xh (control-x h) and it will tell you (the `tags').


Bye
 Sven


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