* Completion lists @ 2011-09-13 12:54 Yuri DElia 2011-09-13 14:43 ` Bart Schaefer 2011-09-16 21:58 ` Tomasz Pala 0 siblings, 2 replies; 15+ messages in thread From: Yuri DElia @ 2011-09-13 12:54 UTC (permalink / raw) To: zsh-users Hi everyone, I would like to customize how the completion list is shown in zsh, I a way similar to how current emacs does it. I've looking around, but found nothing. Whenever I complete a file prefix which is ambiguous, I get a list of the form: $ cd prog<TAB> program1 progman progwhatever I would like to highlight (in bold) the trailing/ambiguous part (typed in caps here): $ cd prog<TAB> progRAM progMAN progWHATEVER This would be a *huge* time saver for me. Often I find myself completing over a long set of files with a very similar name, and I really don't know *where* to look at. Bonus points if this works with complete_in_word. Having the unambiguous part with ellipses would also be fine (if any simpler to implement): $ cd prog<TAB> ...ram ...man ...whatever Though I would prefer highlighting. Thanks for any info. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 12:54 Completion lists Yuri DElia @ 2011-09-13 14:43 ` Bart Schaefer 2011-09-13 15:16 ` Yuri DElia 2011-09-18 13:41 ` Yuri DElia 2011-09-16 21:58 ` Tomasz Pala 1 sibling, 2 replies; 15+ messages in thread From: Bart Schaefer @ 2011-09-13 14:43 UTC (permalink / raw) To: zsh-users On Sep 13, 12:54pm, Yuri DElia wrote: } } I would like to highlight (in bold) the trailing/ambiguous part (typed in caps } here): } } $ cd prog<TAB> } progRAM } progMAN } progWHATEVER You should be able to do this with something like: zstyle -e ':completion:*:default' list-colors \ 'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")' The -e option evaluates the style so you can use $words[CURRENT] to put the string from the line into the style. The highlight is controlled by the =0=3 part, where =0 means no highlight on the parts that are not matched by a pattern in parens and the =7 means use reverse video on the part matched by the first sub-pattern in parens (here "(*)"). See the doc for the complist module ZLS_COLORS variable. It won't work all the time because completion is a really complex beast. You probably need to do the above a few times replacing "default" with different tags. For example, above I've use the tail (:t) of the current word so that it'll do something useful when completing files in subdirectories, but that isn't really necessary when completing variable names or options. You might want to use one pattern for file completion and another for other contexts. If you've got matcher-list styles that do fancy completion in the middle of words, $words[CURRENT] is going to be inadequate to the task (and it is likely that nothing you can expand at the time the list-colors style is evaluated would be sufficient). You might specify case-insensitive globbing on to help with mixed-case matcher-lists: zstyle -e ':completion:*:default' list-colors \ 'reply=("=(#bi)${words[CURRENT]:t}(*)=0=7")' If someone builds up a useful set of these based on this example, please post back to the list. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 14:43 ` Bart Schaefer @ 2011-09-13 15:16 ` Yuri DElia 2011-09-13 16:07 ` Yuri DElia 2011-09-13 16:29 ` Bart Schaefer 2011-09-18 13:41 ` Yuri DElia 1 sibling, 2 replies; 15+ messages in thread From: Yuri DElia @ 2011-09-13 15:16 UTC (permalink / raw) To: zsh-users Bart Schaefer <schaefer <at> brasslantern.com> writes: > zstyle -e ':completion:*:default' list-colors \ > 'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")' > > The -e option evaluates the style so you can use $words[CURRENT] to put > the string from the line into the style. The highlight is controlled > by the =0=3 part, where =0 means no highlight on the parts that are > not matched by a pattern in parens and the =7 means use reverse video > on the part matched by the first sub-pattern in parens (here "(*)"). > See the doc for the complist module ZLS_COLORS variable. Your code seem to fail badly with directories. For instance, completing anything with "./" will incorrectly skip the first two characters of the files themselves. > If you've got matcher-list styles that do fancy completion in the middle > of words, $words[CURRENT] is going to be inadequate to the task (and it > is likely that nothing you can expand at the time the list-colors style > is evaluated would be sufficient). You might specify case-insensitive > globbing on to help with mixed-case matcher-lists: > > zstyle -e ':completion:*:default' list-colors \ > 'reply=("=(#bi)${words[CURRENT]:t}(*)=0=7")' While I was waiting I kept trying and came up with this: c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]' zstyle -e ':completion:*' list-colors "reply=(\"$c\")" The first part of the reply matches the first character after the prefix. The second matches the first character in a list (when completing directories). Seems to work fine for both files and parameters. Doesn't work for anything beyond prefix matching: $ ls ///list<TAB> (ambiguous) etc/ lib/ usr/ will simply put the cursor after the first / and highlight the third characters of the list (and I don't understand why). I'm wondering what variables could in the reply. I found $PREFIX in other examples, and now also $words[CURRENT]. Is there a list for these? Maybe I could make it work if I had SUFFIX/somethingelse. > If someone builds up a useful set of these based on this example, please > post back to the list. I would also be glad. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 15:16 ` Yuri DElia @ 2011-09-13 16:07 ` Yuri DElia 2011-09-13 17:40 ` Bart Schaefer 2011-09-13 16:29 ` Bart Schaefer 1 sibling, 1 reply; 15+ messages in thread From: Yuri DElia @ 2011-09-13 16:07 UTC (permalink / raw) To: zsh-users Yuri DElia <wavexx <at> users.sf.net> writes: > c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]' > zstyle -e ':completion:*' list-colors "reply=(\"$c\")" I think I've hit a zsh bug here :/. c='${PREFIX:+=(#b)${PREFIX:t}(?)*==1}':'=(#b)(?)*==1' zstyle -e ':completion:*' list-colors "reply=(\"$c\")" Try to complete a directory such as "./" first. The second expression will match, and the first character becomes bold. Now try: $ touch fileaa $ touch filebb $ ls file<TAB> (this will correctly highlight "a" and "b") suddenly: $ ls ./<TAB> will still match the second expression '=(#b)(?)*==1' but here (?) will capture the first 4 characters, not just the first one. The length is dependent on previous PREFIX ("file" here). Bug? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 16:07 ` Yuri DElia @ 2011-09-13 17:40 ` Bart Schaefer 2011-09-13 18:48 ` Yuri DElia 2011-09-16 21:04 ` Peter Stephenson 0 siblings, 2 replies; 15+ messages in thread From: Bart Schaefer @ 2011-09-13 17:40 UTC (permalink / raw) To: zsh-users On Sep 13, 4:07pm, Yuri DElia wrote: } } $ touch fileaa } $ touch filebb } $ ls file<TAB> } } (this will correctly highlight "a" and "b") } } suddenly: } } $ ls ./<TAB> } } will still match the second expression '=(#b)(?)*==1' but here (?) } will capture the first 4 characters, not just the first one. The behvior I see is that it *skips* the first 4 characters and highlights the fifth one, i.e., it continues to highlight "a" and "b" in those two files but highlights nothing in file names with fewer than 5 characters. Still wrong, but not in the way you said. } The length is dependent on previous PREFIX ("file" here). } } Bug? It would appear so. compstate[insert_positions]=5 at the end of the "ls ./<TAB>" although compstate[unambiguous_positions]=2. So the pattern is matched correctly, but incorrectly is compared to the string beginning at the 5th position. Some part of the internal state that should be getting cleared when the completion restarts, is not. This perists across ZLE restarts but not across different words in command position, e.g. if you complete for "ls" twice in a row it's broken, but if you complete for "ls" and then for "setopt" and then back to "ls" again it works correctly all three times (or at least did for me in a couple of quick trials). Unfortunately I'm not going to have an opportunity to run that down anytime soon. Peter? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 17:40 ` Bart Schaefer @ 2011-09-13 18:48 ` Yuri DElia 2011-09-16 21:04 ` Peter Stephenson 1 sibling, 0 replies; 15+ messages in thread From: Yuri DElia @ 2011-09-13 18:48 UTC (permalink / raw) To: zsh-users Bart Schaefer <schaefer <at> brasslantern.com> writes: > } will still match the second expression '=(#b)(?)*==1' but here (?) > } will capture the first 4 characters, not just the first one. > > The behvior I see is that it *skips* the first 4 characters and > highlights the fifth one, i.e., it continues to highlight "a" and > "b" in those two files but highlights nothing in file names with > fewer than 5 characters. Still wrong, but not in the way you said. On a related note, can I set a different list-colors when completing files, and a default for everything else? zstyle -e ':completion:complete-files:*' list-colors ... don't seem to work. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 17:40 ` Bart Schaefer 2011-09-13 18:48 ` Yuri DElia @ 2011-09-16 21:04 ` Peter Stephenson 2011-09-16 21:07 ` Peter Stephenson 1 sibling, 1 reply; 15+ messages in thread From: Peter Stephenson @ 2011-09-16 21:04 UTC (permalink / raw) To: zsh-users How about this? Index: Src/Zle/complist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v retrieving revision 1.127 diff -p -u -r1.127 complist.c --- Src/Zle/complist.c 19 Jun 2011 16:26:11 -0000 1.127 +++ Src/Zle/complist.c 16 Sep 2011 21:03:32 -0000 @@ -880,9 +880,9 @@ putfilecol(char *group, char *filename, Patcol pc; int len; - nrefs = MAX_POS - 1; + for (pc = mcolors.pats; pc; pc = pc->next) { + nrefs = MAX_POS - 1; - for (pc = mcolors.pats; pc; pc = pc->next) if ((!pc->prog || !group || pattry(pc->prog, group)) && pattryrefs(pc->pat, filename, -1, -1, 0, &nrefs, begpos, endpos)) { if (pc->cols[1]) { @@ -894,6 +894,7 @@ putfilecol(char *group, char *filename, return 0; } + } if (special != -1) { colour = special; -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-16 21:04 ` Peter Stephenson @ 2011-09-16 21:07 ` Peter Stephenson 0 siblings, 0 replies; 15+ messages in thread From: Peter Stephenson @ 2011-09-16 21:07 UTC (permalink / raw) To: zsh-users Or even this? Index: Src/Zle/complist.c =================================================================== RCS file: /cvsroot/zsh/zsh/Src/Zle/complist.c,v retrieving revision 1.127 diff -p -u -r1.127 complist.c --- Src/Zle/complist.c 19 Jun 2011 16:26:11 -0000 1.127 +++ Src/Zle/complist.c 16 Sep 2011 21:06:08 -0000 @@ -849,9 +849,9 @@ putmatchcol(char *group, char *n) { Patcol pc; - nrefs = MAX_POS - 1; + for (pc = mcolors.pats; pc; pc = pc->next) { + nrefs = MAX_POS - 1; - for (pc = mcolors.pats; pc; pc = pc->next) if ((!pc->prog || !group || pattry(pc->prog, group)) && pattryrefs(pc->pat, n, -1, -1, 0, &nrefs, begpos, endpos)) { if (pc->cols[1]) { @@ -863,6 +863,7 @@ putmatchcol(char *group, char *n) return 0; } + } zcputs(group, COL_NO); @@ -880,9 +881,9 @@ putfilecol(char *group, char *filename, Patcol pc; int len; - nrefs = MAX_POS - 1; + for (pc = mcolors.pats; pc; pc = pc->next) { + nrefs = MAX_POS - 1; - for (pc = mcolors.pats; pc; pc = pc->next) if ((!pc->prog || !group || pattry(pc->prog, group)) && pattryrefs(pc->pat, filename, -1, -1, 0, &nrefs, begpos, endpos)) { if (pc->cols[1]) { @@ -894,6 +895,7 @@ putfilecol(char *group, char *filename, return 0; } + } if (special != -1) { colour = special; -- Peter Stephenson <p.w.stephenson@ntlworld.com> Web page now at http://homepage.ntlworld.com/p.w.stephenson/ ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 15:16 ` Yuri DElia 2011-09-13 16:07 ` Yuri DElia @ 2011-09-13 16:29 ` Bart Schaefer 2011-09-13 17:11 ` Yuri DElia 1 sibling, 1 reply; 15+ messages in thread From: Bart Schaefer @ 2011-09-13 16:29 UTC (permalink / raw) To: zsh-users On Sep 13, 3:16pm, Yuri DElia wrote: } } Bart Schaefer <schaefer <at> brasslantern.com> writes: } } > zstyle -e ':completion:*:default' list-colors \ } > 'reply=("=(#b)${words[CURRENT]:t}(*)=0=7")' } } Your code seem to fail badly with directories. } For instance, completing anything with "./" will incorrectly skip the } first two characters of the files themselves. It works just fine from zsh -f autoload -Uz compinit compinit -D zstyle ... and it also works with my own usual completion styles, so there's something else in your configuration that's clashing with it. [...] } While I was waiting I kept trying Always a good plan. } and came up with this: } } c='${PREFIX:+=(#b)($PREFIX:t)(?)*===$color[bold]}':'=(#b)(?)*==$color[bold]' } zstyle -e ':completion:*' list-colors "reply=(\"$c\")" Strictly speaking I think you should use =0=0=$color[bold]}, that may be why strange things are getting highlighted in some of your attempts. I get different results with =0=0= vs ===. } I'm wondering what variables could in the reply. I found $PREFIX in } other examples, and now also $words[CURRENT]. Is there a list for } these? Maybe I could make it work if I had SUFFIX/somethingelse. All the completion special variables are listed in the "Completion Special Parameters" section of the manual (info section 19.2 with the latest CVS checkout). The list-colors style is looked up several times during the course of a typical completion, so it may get evaluated late enough for the values of words / PREFIX / SUFFIX etc. to be accurate. I still think it's going to be difficult to get a single global list-colors style that covers all the cases. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 16:29 ` Bart Schaefer @ 2011-09-13 17:11 ` Yuri DElia 0 siblings, 0 replies; 15+ messages in thread From: Yuri DElia @ 2011-09-13 17:11 UTC (permalink / raw) To: zsh-users Bart Schaefer <schaefer <at> brasslantern.com> writes: > Strictly speaking I think you should use =0=0=$color[bold]}, that may be > why strange things are getting highlighted in some of your attempts. I > get different results with =0=0= vs ===. Doesn't do anything for me. Could you please try the following? highlights='${PREFIX:+=(#b)${PREFIX:q:t}(?)*=0=1}':'=(#b)(?)*=0=1' zstyle -e ':completion:*' list-colors "reply=(\"$highlights\")" unset highlights and try touch filea touch fileb ls ./<TAB> ls ./file<TAB> ls ./<TAB> and report what happens? In the first ls, the first character is highlighted. In the second, [ab] should be highlighted. In the third, the '=(#b)(?)*=0=1' expression fails, and matches [ab] instead of [f]. You can also try this afterwards: highlights='=(#b)(?)*=0=1' zstyle -e ':completion:*' list-colors "reply=(\"$highlights\")" unset highlights and it will still match [ab]. Can you replicate this issue? ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 14:43 ` Bart Schaefer 2011-09-13 15:16 ` Yuri DElia @ 2011-09-18 13:41 ` Yuri DElia 2011-09-18 13:48 ` Mikael Magnusson 1 sibling, 1 reply; 15+ messages in thread From: Yuri DElia @ 2011-09-18 13:41 UTC (permalink / raw) To: zsh-users Bart Schaefer <schaefer <at> brasslantern.com> writes: > If someone builds up a useful set of these based on this example, please > post back to the list. Just for posterity, this is what I've using since a couple of days: ################## # completition list colorization (emacs style) highlight-comp() { reply=() [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( "=(#b)${PREFIX:q:t}(?)*==1" ) reply+=( "=(#b)(?)*==1" ) } zstyle -e ':completion:*' list-colors highlight-comp ################## It seems to work fine for most cases. This particular code also seems to avoid the reset bug as mentioned before (although this wasn't intended). Is also works for in-word completions, like this: % ls ///list<TAB> etc/ lib/ usr/ but it's also pure chance, since PREFIX in this case seems to be "///list" which doesn't pass the "! -d" test (which is done for simple directories). I tried to write better code to handle this case, but "$compstate" doesn't seem to put anything meaningful (I was expecting insert_positions to be set to something!). Also, I could avoid the test entirely if I could set a different function when completing arguments instead of files. How can I do this? Thanks. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-18 13:41 ` Yuri DElia @ 2011-09-18 13:48 ` Mikael Magnusson [not found] ` <ed790212f803298ea33fd6091b9d5062@thregr.org> 0 siblings, 1 reply; 15+ messages in thread From: Mikael Magnusson @ 2011-09-18 13:48 UTC (permalink / raw) To: Yuri DElia; +Cc: zsh-users On 18 September 2011 15:41, Yuri DElia <wavexx@users.sf.net> wrote: > Bart Schaefer <schaefer <at> brasslantern.com> writes: > >> If someone builds up a useful set of these based on this example, please >> post back to the list. > > Just for posterity, this is what I've using since a couple of days: > > ################## > # completition list colorization (emacs style) > highlight-comp() > { > reply=() > [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( "=(#b)${PREFIX:q:t}(?)*==1" ) > reply+=( "=(#b)(?)*==1" ) > } > > zstyle -e ':completion:*' list-colors highlight-comp > ################## > > It seems to work fine for most cases. This particular code also seems to avoid > the reset bug as mentioned before (although this wasn't intended). > > Is also works for in-word completions, like this: > > % ls ///list<TAB> > etc/ lib/ usr/ > > but it's also pure chance, since PREFIX in this case seems to be "///list" which > doesn't pass the "! -d" test (which is done for simple directories). I tried to > write better code to handle this case, but "$compstate" doesn't seem to put > anything meaningful (I was expecting insert_positions to be set to something!). > > Also, I could avoid the test entirely if I could set a different function when > completing arguments instead of files. How can I do this? [...] > zstyle -e ':completion:*' list-colors highlight-comp Here you can use something like ":completion:*:files:" instead, i don't know off hand what the exact value you want is, bindkey some key to _complete_help and check. Or maybe you want to make it match against _files rather than the specific tag. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 15+ messages in thread
[parent not found: <ed790212f803298ea33fd6091b9d5062@thregr.org>]
* Re: Completion lists [not found] ` <ed790212f803298ea33fd6091b9d5062@thregr.org> @ 2011-09-18 14:08 ` Mikael Magnusson 2011-09-18 14:35 ` Yuri D'Elia 0 siblings, 1 reply; 15+ messages in thread From: Mikael Magnusson @ 2011-09-18 14:08 UTC (permalink / raw) To: Yuri D'Elia, Zsh Users [you forgot to reply to all] On 18 September 2011 16:03, Yuri D'Elia <wavexx@users.sourceforge.net> wrote: > On Sun, 18 Sep 2011 15:48:39 +0200, Mikael Magnusson wrote: >>> >>> % ls ///list<TAB> >>> etc/ lib/ usr/ >>> >>> but it's also pure chance, since PREFIX in this case seems to be >>> "///list" which >>> doesn't pass the "! -d" test (which is done for simple directories). I >>> tried to >>> write better code to handle this case, but "$compstate" doesn't seem to >>> put >>> anything meaningful (I was expecting insert_positions to be set to >>> something!). >>> >>> Also, I could avoid the test entirely if I could set a different function >>> when >>> completing arguments instead of files. How can I do this? >> >> [...] >>> >>> zstyle -e ':completion:*' list-colors highlight-comp >> >> Here you can use something like ":completion:*:files:" instead, i >> don't know off hand what the exact value you want is, bindkey some key >> to _complete_help and check. Or maybe you want to make it match >> against _files rather than the specific tag. > > I guess I want to match set a different functions depending whether I'm > completing on _files or _arguments, but I'm unsure how to do that. > > $ vi ./d^xh > tags in context :completion::complete:vi:: > all-files (_files _default (eval)) > > Doing > > zstyle -e ':completion:*:files:' list-colors .. > > doesn't do what I mean. As you can see, the tag here is "all-files", not "files". You also need another * after the last :, I see that I missed that, sorry. I think you can put either all-files or _files and it might work. Note that if you set the list-dirs-first style, you'll get other-files and directories instead of all-files. -- Mikael Magnusson ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-18 14:08 ` Mikael Magnusson @ 2011-09-18 14:35 ` Yuri D'Elia 0 siblings, 0 replies; 15+ messages in thread From: Yuri D'Elia @ 2011-09-18 14:35 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Zsh Users On Sun, 18 Sep 2011 16:08:29 +0200, Mikael Magnusson wrote: >> zstyle -e ':completion:*:files:' list-colors .. >> >> doesn't do what I mean. > > As you can see, the tag here is "all-files", not "files". You also > need another * after the last :, I see that I missed that, sorry. I > think you can put either all-files or _files and it might work. Note > that if you set the list-dirs-first style, you'll get other-files and > directories instead of all-files. Ah, thanks! This: ###### # completition list colorization (emacs style) highlight-comp() { reply=( "=(#b)${PREFIX:q}(?)*==1" ) } highlight-comp-files() { reply=() [ -n "$PREFIX" -a ! -d "$PREFIX" ] && reply+=( "=(#b)${PREFIX:q:t}(?)*==1" ) reply+=( "=(#b)(?)*==1" ) } zstyle -e ':completion:*' list-colors highlight-comp zstyle -e ':completion:*:all-files' list-colors highlight-comp-files ###### ...now covers a couple more edge cases where an argument might match some existing files (git completion being one of the main offenders ;)). One more thing I'd like to cover when completing files. Is there a way to get the prefix up to the insert position when completing something like: ls ///list<TAB> (where the cursor is placed just after the first /) Looking at the documentation, $compstate should help, but inside the callback function PREFIX is still set to "///list" and $compstate[insert_positions] is empty. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Completion lists 2011-09-13 12:54 Completion lists Yuri DElia 2011-09-13 14:43 ` Bart Schaefer @ 2011-09-16 21:58 ` Tomasz Pala 1 sibling, 0 replies; 15+ messages in thread From: Tomasz Pala @ 2011-09-16 21:58 UTC (permalink / raw) To: zsh-users On Tue, Sep 13, 2011 at 12:54:01 +0000, Yuri DElia wrote: > I would like to customize how the completion list is shown in zsh, I a way > similar to how current emacs does it. I've looking around, but found nothing. I think I've already posted this (in polish, but with screenshots): http://jakilinux.org/aplikacje/konsola/zsh-automatyzacja-czynnosci/ In this case try: setopt extended_glob highlights='${PREFIX:+=(#bi)($PREFIX:t)(?)*==31=1;32}':${(s.:.)LS_COLORS}} highlights2='=(#bi) #([0-9]#) #([^ ]#) #([^ ]#) ##*($PREFIX)*==1;31=1;35=1;33=1;32=}' zstyle -e ':completion:*' list-colors 'if [[ $words[1] != kill && $words[1] != strace ]]; then reply=( "'$highlights'" ); else reply=( "'$highlights2'" ); fi' unset highlights -- Tomasz Pala <gotar@pld-linux.org> ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-09-18 14:56 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-09-13 12:54 Completion lists Yuri DElia 2011-09-13 14:43 ` Bart Schaefer 2011-09-13 15:16 ` Yuri DElia 2011-09-13 16:07 ` Yuri DElia 2011-09-13 17:40 ` Bart Schaefer 2011-09-13 18:48 ` Yuri DElia 2011-09-16 21:04 ` Peter Stephenson 2011-09-16 21:07 ` Peter Stephenson 2011-09-13 16:29 ` Bart Schaefer 2011-09-13 17:11 ` Yuri DElia 2011-09-18 13:41 ` Yuri DElia 2011-09-18 13:48 ` Mikael Magnusson [not found] ` <ed790212f803298ea33fd6091b9d5062@thregr.org> 2011-09-18 14:08 ` Mikael Magnusson 2011-09-18 14:35 ` Yuri D'Elia 2011-09-16 21:58 ` Tomasz Pala
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).