Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ZSH users (lovers?) thread
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 10, 11, 12, 13  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
View previous topic :: View next topic  
Author Message
yngwin
Retired Dev
Retired Dev


Joined: 19 Dec 2002
Posts: 4572
Location: Suzhou, China

PostPosted: Mon Jul 30, 2012 12:26 pm    Post subject: Reply with quote

Are there any add-ons (like zsh-syntax-highlighting) that you guys would like to see ebuilds for in portage? If it is something that seems useful, I can add them.
_________________
"Those who deny freedom to others deserve it not for themselves." - Abraham Lincoln
Free Culture | Defective by Design | EFF
Back to top
View user's profile Send private message
Spark25x
n00b
n00b


Joined: 26 Feb 2012
Posts: 23

PostPosted: Mon Jul 30, 2012 12:36 pm    Post subject: Reply with quote

yngwin wrote:
Are there any add-ons (like zsh-syntax-highlighting) that you guys would like to see ebuilds for in portage? If it is something that seems useful, I can add them.

I think people will enjoy a "oh-my-zsh" ebuild :) i have it from github,but i guess a ebuild will be nicer :D
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Jul 30, 2012 12:41 pm    Post subject: Reply with quote

khayyam wrote:
mv wrote:
Also, perhaps, you might want to cut paths if they become so long that they almost fill a line.

'%3~' will do exactly this (truncate to three directories).

You are right; I didn't look at the code but just at the description and tried it very briefly. Actually, I ignored the zsh "internal" solution for this case, because the string "..." is fixed when you cut in the middle, while I want the omission-dots to appear in a rather different color (I want to recognize immediately by color if the path is cut and where).
Quote:
I use a precmd/preexec function for status

Nice idea. I was not aware that these functions were allowed to produce some output: I had always though they should only be used to set variables (e.g. for usage within the prompt).
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Jul 30, 2012 12:44 pm    Post subject: Reply with quote

spark666 wrote:
yngwin wrote:
Are there any add-ons (like zsh-syntax-highlighting) that you guys would like to see ebuilds for in portage? If it is something that seems useful, I can add them.

I think people will enjoy a "oh-my-zsh" ebuild :) i have it from github,but i guess a ebuild will be nicer :D

For zsh-syntax-highlighting and oh-my-zsh there are live ebuilds in the mv overlay. However, both ebuilds are updated only very infrequently.
Back to top
View user's profile Send private message
LiamOS
n00b
n00b


Joined: 06 Jun 2012
Posts: 61
Location: Ireland

PostPosted: Mon Jul 30, 2012 1:49 pm    Post subject: Reply with quote

khayyam wrote:
LiamOS ...

for me colour functions as as visual clue and I think I'd find your prompt more of an annoyance than an aid, but each to their own. Plus, for general use I wouldn't want to source my .zshrc on each command, and I question the wisdom of doing this simply for the purpose of aesthetics.

Indeed, it's little more than a gimmick, but I've not yet come to the stage where I actually need my prompt to tell me anything other than where I am. (I'm still a massive noob with zsh.)


mv wrote:
Actually, it is even worse since it is sourced each second and not each command - which makes no sense concerning prompt colors. I would use PS1=$(....${RANDOM}...) if I would want different colors for every prompt.

That's a much better idea. Thanks.
Edit: Actually, does that work? I thought RANDOM only generates once per call, and it's only called once when your shell sources .zshrc. I'm not on a machine with zsh now so I can't test it.

khayyam wrote:

'%3~' will do exactly this (truncate to three directories).

Awesome. I was trying to script a function to do this and was having some trouble. I guess I underestimated zsh. :oops:
_________________
CFLAGS=" -O999999"
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Jul 30, 2012 2:25 pm    Post subject: Reply with quote

LiamOS wrote:
mv wrote:
Actually, it is even worse since it is sourced each second and not each command - which makes no sense concerning prompt colors. I would use PS1=$(....${RANDOM}...) if I would want different colors for every prompt.

Edit: Actually, does that work? I thought RANDOM only generates once per call

Of course, it generates only once per call. This is why the above code snippet is far from being complete: The code within $(...) is executed each time the prompt is printed (you need to setopt promptsubst for this); of course this means that the code within $(....) has to print/echo the actual prompt, but it can use ${RANDOM} to do this.
Edit: You need not put the whole prompt into a single $(...), of course, just the relevant part suffices. Here is an example for the some incomplete prrompt (containing only the user name in a random color):
Code:
PS1='%F{$(case $((${RANDOM}%3)) in (0) printf red;; (1) printf cyan;; (2) printf green;; esac)}%n%f'

Quote:
I was trying to script a function to do this and was having some trouble. I guess I underestimated zsh. :oops:

You can do the same manually without using zsh (as mentioned in an earlier post, the set_prompt script does this manually to obtain an additional feature).
Back to top
View user's profile Send private message
LiamOS
n00b
n00b


Joined: 06 Jun 2012
Posts: 61
Location: Ireland

PostPosted: Mon Jul 30, 2012 2:51 pm    Post subject: Reply with quote

mv wrote:
Of course, it generates only once per call. This is why the above code snippet is far from being complete: The code within $(...) is executed each time the prompt is printed (you need to setopt promptsubst for this); of course this means that the code within $(....) has to print/echo the actual prompt, but it can use ${RANDOM} to do this.
Edit: You need not put the whole prompt into a single $(...), of course, just the relevant part suffices. Here is an example for the some incomplete prrompt (containing only the user name in a random color):
Code:
PS1='%F{$(case $((${RANDOM}%3)) in (0) printf red;; (1) printf cyan;; (2) printf green;; esac)}%n%f'


Aha, I see now. Thanks for that!
I also just got a friend to use my earlier prompt on his netbook to see if it was actually that bad... The results is that sourcing .zshrc that much causes a pretty big delay in getting your next prompt down(Really noticeable if you just 'ls'), and probably has a fair overhead too. Oh the solutions a noob will come up with. :?
_________________
CFLAGS=" -O999999"
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Mon Jul 30, 2012 2:59 pm    Post subject: Reply with quote

yngwin wrote:
Are there any add-ons (like zsh-syntax-highlighting) that you guys would like to see ebuilds for in portage? If it is something that seems useful, I can add them.

yngwin ... I'm really not a fan of oh-my-zsh (for many reasons) and so would like to add at least one 'nay' ITR, app-shells/zsh-run-help (from mv overlay) would be good inclusion however.

In the case of app-shells/zsh-completion this needs to be modified to reflect make.conf (and similar) moving to /etc/portage ... thought that worth mentioning as it will no doubt become a bug in the not too distant future (infact I should probably file one).

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Jul 30, 2012 3:02 pm    Post subject: Reply with quote

LiamOS wrote:
Aha, I see now. Thanks for that!

I just realized that it does not work: If ${RANDOM} is called in a subshell, it is actually not random (this is clear, because it cannot pass the new seed to the parrent shell).
Probably you have to read from /dev/urandom or something similar to get a real random number or you must call ${RANDOM} in some precmd function hook.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Mon Jul 30, 2012 3:22 pm    Post subject: Reply with quote

LiamOS wrote:
[...] it's little more than a gimmick, but I've not yet come to the stage where I actually need my prompt to tell me anything other than where I am. (I'm still a massive noob with zsh.)

Liam ... well, my advice would be to start as you mean to go on ... and that goes for the entire zsh initialisation, not just the prompt. So, short, sweet, and simple.

LiamOS wrote:
khayyam wrote:
'%3~' will do exactly this (truncate to three directories).

Awesome. I was trying to script a function to do this and was having some trouble. I guess I underestimated zsh.

The prompt escapes are covered in 'man zshmisc' ...

best ... khay


Last edited by khayyam on Mon Jul 30, 2012 3:23 pm; edited 1 time in total
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Mon Jul 30, 2012 3:23 pm    Post subject: Reply with quote

khayyam wrote:
app-shells/zsh-run-help (from mv overlay) would be good inclusion however.

Actually, this would work better if it (i.e. the code of the ebuild) would be included into the zsh ebuild with a USE-Flag.
Alternatively, once EAPI=5 (the current EAPI=4-slot-abi) is available, it would be possible that app-shells/zsh would have subslots SLOT="0/${PV}" and zsh-run-help RDEPENDs on app-shells/zsh:=
The problem with the separate ebuild and non-slot-dependency is that you are not forced to rebuild the help-file if you install a different version of zsh, and so it is not forced that the help-file matches the currently installed zsh version.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Mon Jul 30, 2012 3:35 pm    Post subject: Reply with quote

mv wrote:
khayyam wrote:
app-shells/zsh-run-help (from mv overlay) would be good inclusion however.

Actually, this would work better if it (i.e. the code of the ebuild) would be included into the zsh ebuild as a USE-Flag.
Alternatively, once EAPI=5 (the current EAPI=4-slot-abi) is available, it would be possible that app-shells/zsh would have subslots SLOT="0/${PV}" and zsh-run-help depends on app-shells/zsh:=
The problem with the separate ebuild and non-slot-dependency is that you are not forced to rebuild the help-file if you install a different version of zsh, and so it is not forced that the help-file matches the currently installed zsh version.

mv ... yes, actually, I never understood why it was expected that this would be done via Util/helpfiles and not as part of the 'make install' (or 'make help install'), and probably its for this reason that its a rarity to find run-help files installed.

best ... khay
Back to top
View user's profile Send private message
LiamOS
n00b
n00b


Joined: 06 Jun 2012
Posts: 61
Location: Ireland

PostPosted: Mon Jul 30, 2012 3:40 pm    Post subject: Reply with quote

khayyam wrote:
LiamOS wrote:
[...] it's little more than a gimmick, but I've not yet come to the stage where I actually need my prompt to tell me anything other than where I am. (I'm still a massive noob with zsh.)

Liam ... well, my advice would be to start as you mean to go on ... and that goes for the entire zsh initialisation, not just the prompt. So, short, sweet, and simple.

I did the same with my Bash prompt. From the default, I went crazy with colours and such, but now it just tells me who and where I am, and is red(and # instead of $) if I'm root.
I'm still going to work on a weird, multicoloured zsh prompt that doesn't source itself all day(I know a few people who'd absolutely love it :?), but I doubt I'd use it much more than for the occasional laugh.
_________________
CFLAGS=" -O999999"
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Jul 31, 2012 7:00 am    Post subject: Reply with quote

So as to keep this thread active I thought I'd re-read the entire thread and look for any unanswerd questions ... and though the following was provided an answer it does offer a nice segway:

benol wrote:
How can I check if the module has already been loaded in my .zshrc?

To which ag_x provided the following:

Code:
[[ -z "$modules[zsh/complist]" ]] && zmodload zsh/complist

This will work but I would use the following as then there is no call made to /usr/bin/[

Code:
(( $+modules[zsh/complist] )) || zmodload -i zsh/complist

In a similar manner we can use zsh's 'commands' and 'terminfo' hashes ...

Code:
if (( $+commands[dircolors] )) && (( $terminfo[colors] == 256 )) ; then

or, say, test for the existance of a command in a conditional ...

Code:
if (( $+commands[which] )) ; then
    alias which="alias |${commands[which]} --tty-only --read-alias --show-dot --show-tilde"
else
    which () {
        builtin type "$@" \
    }
fi

Also, the '${commands}' hash can be used to provide the full path for a variable ...

Code:
export EDITOR="${commands[vim]}"

Thought that might be of some interest ... and the minor inconvinience of typing 'rehash' on the odd occasion when adding some command in the $PATH (which in my case is very rare) is offset by the precence of these hashes.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Jul 31, 2012 7:29 am    Post subject: Reply with quote

khayyam wrote:
This will work but I would use the following as then there is no call made to /usr/bin/[

Where do you see a call to '[' here? '[[' is certainly a built-in (and '[' also happens to be built-in in the case of zsh).
Quote:
Code:
export EDITOR="${commands[vim]}"

Also here, I do not see the point: Why not set EDITOR="vim"? When you call $EDITOR, the name will be looked up in the hash.
(OK, if an external programm neeeds the full path, you also need the full path. But then the more portable EDITOR=`command -v vim` should do the same (I have not looked up the code, but would be surprised if zsh would not just look up the hash)).
Quote:
... and the minor inconvinience of typing 'rehash'

Typing 'rehash' will not fix the above variable if vim moved to a different place. You really have to re-source the assignment then.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Jul 31, 2012 8:45 am    Post subject: Reply with quote

mv wrote:
Where do you see a call to '[' here? '[[' is certainly a built-in (and '[' also happens to be built-in in the case of zsh).

mv ... yes, sorry, my bad ...

mv wrote:
Quote:
Code:
export EDITOR="${commands[vim]}"

Also here, I do not see the point: Why not set EDITOR="vim"? When you call $EDITOR, the name will be looked up in the hash.
(OK, if an external programm neeeds the full path, you also need the full path. But then the more portable EDITOR=`command -v vim` should do the same (I have not looked up the code, but would be surprised if zsh would not just look up the hash)).

Yes, for situations in which an external program wants the full path. I don't see how (or indeed why) using backticks within zsh is any more 'portable' or why an external program can't use the enviroment variable.

mv wrote:
Quote:
... and the minor inconvinience of typing 'rehash'

Typing 'rehash' will not fix the above variable if vim moved to a different place. You really have to re-source the assignment then.

I wasn't saying it would ... I was speaking to the various claims at annoyance due to commands not being automatically added to the hash and how this was a minor inconvinence compared to their availablity.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Jul 31, 2012 9:13 am    Post subject: Reply with quote

khayyam wrote:
I don't see how (or indeed why) using backticks within zsh is any more 'portable'

You can use the same code then also for other shells. It depends on your setup, but usually, it is a good idea to have a shell-independent startup-file (which sets standard environment variables like EDITOR) and a zsh/bash/whatever-specific startup file for the shell of your choice so that you can quickly change if necessary.
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sat Aug 11, 2012 2:56 pm    Post subject: Reply with quote

zsh users, et al ...

again, with the purpose of keeping this thread active, another zsh tip ...

When installing zsh the completion system includes various _completion files for various OSes/distributions/etc, these include completions for yum, apt-get, and other commands not likely to be installed, or used, on gentoo. While perhaps useful as examples of completions they are none the less in $fpath and though they can be ignored (via 'ignored-patterns') they will otherwise be autoloaded via compinit. If, like me, you zcompile completions/functions then they also add to the size of the .zwc, and I assume this has a knock on effect in terms of initilaisation.

So, these files can be excluded from the install using INSTALL_MASK ...

/etc/portage/env/app-shells/zsh
Code:
INSTALL_MASK="$INSTALL_MASK /usr/share/zsh/"${PV}"/functions/Completion/AIX /usr/share/zsh/"${PV}"/functions/Completion/BSD /usr/share/zsh/"${PV}"/functions/Completion/Cygwin /usr/share/zsh/"${PV}"/functions/Completion/Darwin /usr/share/zsh/"${PV}"/functions/Completion/Debian /usr/share/zsh/"${PV}"/functions/Completion/Mandriva /usr/share/zsh/"${PV}"/functions/Completion/openSUSE /usr/share/zsh/"${PV}"/functions/Completion/Redhat /usr/share/zsh/"${PV}"/functions/Completion/Solaris"

If you zcompile your functions/completions/zcompdump, then you will want to rebuild the *.zwc subsequent to the re-merge.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sat Aug 11, 2012 5:34 pm    Post subject: Reply with quote

Great tip, khayyam. However, modifying INSTALL_MASK in /etc/portage/env is not guaranteed to work with future portage versions (it might already break with binary packages). It is probably more compatible to do this is in a env/*.conf file. In this case, your wrong (nested) quoting is an issue, since env/*.conf files are interpreted by python. Fortunately, INSTALL_MASK does not necessarily need the full path, so we can even use
/etc/portage/env/zsh.conf wrote:
INSTALL_MASK="${INSTALL_MASK}
AIX
BSD
Cygwin
Darwin
Debian
Mandriva
openSUSE
Redhat
Solaris"
This env/*.conf file must be activated for the zsh ebuild, e.g. with
Code:
echo "app-shells/zsh zsh.conf" >>/etc/portage/package.env
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Sun Aug 12, 2012 12:30 am    Post subject: Reply with quote

mv wrote:
[...] modifying INSTALL_MASK in /etc/portage/env is not guaranteed to work with future portage versions (it might already break with binary packages). It is probably more compatible to do this is in a env/*.conf file. In this case, your wrong (nested) quoting is an issue, since env/*.conf files are interpreted by python.

mv ... I see, I've not used env/category/package for anything other than the above and had assumed from what little I'd read that this was the only method.

As for the nested quoting, I was in two minds as to quoting ${PV} or not, and as it worked when quoted, I didn't give it much further thought. Anyhow, I've re-merged using the above env/zsh.conf method and I can verify it behaves as expected.

BTW, when removing these from the package, $fpath is unaltered (and so these remain in $fpath even if removed from the install) as $fpath is set at complile time. Obvously, the fpath hash can be altered via initialisation.

Offtopic, but what else can be tied into env/zsh.conf ... is there a method of running something postinst (ie, for creating *.zwc)?

thanks for the additonal info & best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Sun Aug 12, 2012 6:31 am    Post subject: Reply with quote

khayyam wrote:
I've not used env/category/package for anything other than the above

The difference to env/*.conf is that the former extends the bash-side of ebuilds while the latter the portage and bash side of variables. For instance, adding/removing buildpkg to FEATURES in env/category/package will not work, while it does in env/*.conf.
Quote:
As for the nested quoting

In env/category/package you have bash code, i.e. your "nested" quoting is actually not nested but means that ${PV} is actually unquoted (which by accident in a variable assignment has no bad effect even if PV should contain spaces or other bad symbols); however, there is probably no way to include paths with spaces into INSTALL_MASK anyway.
In contrast, env/*.conf is interpreted by python like your make.conf; there are rather different rules for quoting, e.g. spaces after "=" are allowed and there are somewhat different escape sequences. I have not tried whether concatenating strings as in bash is supported, but I suppose not. Moreover, for incremental variables like FEATURES you should set only e.g. FEATURES="buildpkg" or FEATURES="-buildpkg" and portage will automagically add/remove this from FEATURES. However, INSTALL_MASK is not an incremental variable AFAIK.
Quote:
what else can be tied into env/zsh.conf ... is there a method of running something postinst

env/*.conf can only do things which you can also do in make.conf (since it is only read by a python module). If you want to modify/extend the bash code of ebuilds, you must use env/category/package. Most phases have post_* and pre_* functions which should not be used by ebuilds but are only meant to be used as hooks for such patches.
Quote:
BTW, when removing these from the package, $fpath is unaltered (and so these remain in $fpath even if removed from the install) as $fpath is set at complile time.

Of course. So the cleaner way would be to patch the zsh build system to remove these directories. Here is how you can do this (this replaces the env/zsh.conf and package.env stuff):
/etc/portage/env/app-shells/zsh wrote:
Code:
pre_src_prepare() {
   local i f
   f="local hack ${PORTAGE_CONFIGROOT%/}/etc/portage/env/${CATEGORY}/${PN}*"
   einfo "${f}"
   set --
   for i in AIX BSD Cygwin Darwin Debian Mandriva openSUSE Redhat Solaris
   do   set -- "${@}" -e "s/Completion\/${i}[^ ']*//"
   done
   i='Src/Zle/complete.mdd'
   einfo "Patching ${i} to remove undesired completions"
   sed -i "${@}" -- "${i}" || die "patching ${i} failed"
   einfo "${f} applied"
}
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Mon Aug 13, 2012 4:39 pm    Post subject: Reply with quote

mv wrote:
[...] So the cleaner way would be to patch the zsh build system to remove these directories. Here is how you can do this [...]

mv ... thanks, that would certainly be my prefered method. I'm not sure why but I get the following error with the above and I don't remember seeing this previously:

Code:
ln: failed to create hard link `/var/tmp/portage/app-shells/zsh-4.3.17/temp/prepstrip/inodes/29454_lockfile': File exists

Otherwise it applies and installs correctly ...

Code:
 * local hack /etc/portage/env/app-shells/zsh*
 * Patching Src/Zle/complete.mdd to remove undesired completions
 * local hack /etc/portage/env/app-shells/zsh* applied

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Aug 14, 2012 7:16 am    Post subject: Reply with quote

In the mv overlay is now an ebuild for zsh which (if the appropriate USE-flags are selected) installs data for run-help and removes undesired completions.

It would be great if this ebuild (or a modification of it) could go into the main portage tree. Should I open an "enhancement" bug for this?
In case it goes to the portage tree, it would be reasonable to introduce a new USE_EXPAND="COMPLETION" in the profile's make.default so that users could select their
completion "wishllist" with COMPLETION="...." (this is done in the mv overlay but cannot be done in the ebuild alone).

Note that you should not use any of the hacks of the previous postings if you use that ebuild (and of course you need to unmerge zsh-run-help if you had merged it).

A different topic: Has anybody checked out auto-fu-zsh from the mv overlay? It is really great though unfortunately rather slow and does not play too well with zsh-syntax-highlighting (e.g. if you do not end the command with a space, text attributes are not reset reliably before the command is executed). There are some clones of the auto-fu.zsh git repository on github, but it seems currently nobody really has improved it yet. So if some zsh wizard here is looking for a challenge... :wink:
Back to top
View user's profile Send private message
khayyam
Watchman
Watchman


Joined: 07 Jun 2012
Posts: 6227
Location: Room 101

PostPosted: Tue Aug 14, 2012 2:06 pm    Post subject: Reply with quote

mv wrote:
In the mv overlay is now an ebuild for zsh which (if the appropriate USE-flags are selected) installs data for run-help and removes undesired completions.

mv ... thanks, I've been meaning to update to 5.0.0. Having emerged with the defualt USE and COMPLETION everything seems to be a'ok. It seems the pkg_postinst() warning re ${ZDOTDIR}/.zcompdump has been removed (I'm not sure when this happened but I'd reported this as a bug many years back, and remember that it use to warn that it will need removed on revisions), so anyone updating should be forwarned that you will need to delete ~/.zcompdump, .zcompdump.zwc (and any other zcompiled functions) due to 4.x => 5.x.

mv wrote:
It would be great if this ebuild (or a modification of it) could go into the main portage tree. Should I open an "enhancement" bug for this?

I would say yes ... if you provide the bug #, I'll vote.

mv wrote:
A different topic: Has anybody checked out auto-fu-zsh from the mv overlay? It is really great though unfortunately rather slow

I haven't but I can imagine it would be ... for me such a feature would be more of an annoyance, it reminds me a little of 'correct as you type' spelling correction.

best ... khay
Back to top
View user's profile Send private message
mv
Watchman
Watchman


Joined: 20 Apr 2005
Posts: 6747

PostPosted: Tue Aug 14, 2012 2:54 pm    Post subject: Reply with quote

khayyam wrote:
for me such a feature would be more of an annoyance, it reminds me a little of 'correct as you type' spelling correction.

I can expect if you use it with spelling corrections completer, it will be horrible. I use it only with completer "_oldllist _complete".
I am not yet decided whether it is more useful or more annoying. In the average, it certainly saves several keystrokes, especially for commands with well-written completions functions. The disadvantage ist that if you type blindly you must get yourself used to typing a space at the end or you might get some surprises, and for commands without appropriate completions (either because nobody has written them or because it is not possible to write reasonable ones), it can be an obstacle.
The latter again is a good motivation to write completion functions for every little command you use frequently (or to fix existing ones if they were suboptimal). :wink:
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... 10, 11, 12, 13  Next
Page 11 of 13

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum