| View previous topic :: View next topic |
| Author |
Message |
SpaceToast
n00b
Joined: 16 Oct 2015
Posts: 19
|
 Posted: Thu Nov 19, 2015 4:18 pm Post subject: [zsh] Tips |
 |
|
Zsh is a great shell. However, it requires a lot of setting up to be provide the high quality interactive experience it offers. Here's a set of tips to improve manageability. Some of these may also apply to other shells, feel free to experiment if you hate it and think it should be shot in the foot or something.
ZDOTDIR: This is where your zsh dot-files are located, and defaults to $HOME. To keep your home directory clean, you can set this to somewhere else, for example ~/.config/zsh. You can either do this globally somewhere in /etc (note: this would always be applied, even if you set NO_GLOBAL_RCS, so the latter is recommended) or you can simply put it into ~/.zshenv. Here's mine!
| Code: | if [[ -o rcs ]]; then
: "${XDG_CACHE_HOME:=$HOME/.cache}"
: "${XDG_CONFIG_HOME:=$HOME/.config}"
: "${XDG_DATA_HOME:=$HOME/.local/share}"
: "${ZDOTDIR:=$XDG_CONFIG_HOME/zsh}"
fi |
Zshrc: the most common method of configuring zsh is by editing ${ZDOTDIR}/.zshrc. Zsh has a lot of options, however, and there may be too many to tackle right off.
There are several projects that exist in order to simplify configuration and provide some built in functionality + plugins. The more notable ones (that actually provide a form of lib) are oh-my-zsh and prezto. Both of these, however, dislike each other and are borderline hostile to independent scripts, as well as obnoxiously slow (partly due to name resolution).
Most zshrc will typically try to include everything in them, and as a result become unreadable and difficult to edit. The solution is to do similar thing to /etc/profile.d, and simply source through everything in ${ZDOTDIR}/*.zsh, for example.
In terms of builtin functionality, I recommend zgen, which hardcodes strings to source (regenerating on demand) and lets you mix and match your own and any other plugins you wish (and allows you to use either of the two libs). My current zshrc can be found here as an example.
dotfiles: dotfiles are your user-specific config files. E.g your zshrc. There's actually a never ending argument on whether or not to open source them or not. Personally, I think you should open source the greatest common denominator among your systems. That way you have a generic configuration, with simple scripts you add in that are for that machine specifically. For reference, my zsh stuff can be found here, with machine specific things finding their way into ${ZDOTDIR}/*.zrc (to avoid conflicts with .zsh files, that I may want to easily call).
tmux/others: tmux and co are a good way to manage your terminals that aren't ui-level tabs (those are just silly). Here's a simple one liner I put into my ${ZDOTDIR}/pre (but you can put it in the start of your zshrc, for example) that will launch a session unique to that terminal (I use byobu, but you can simply substitute byobu for tmux and achieve the same):
| Code: | | [ -z "$TMUX" ] && exec byobu new -s "$$" |
It's always a good idea to read the man page of anything you use. Go through the options! You can always set/unset them in rc files.
Last edited by SpaceToast on Thu Nov 19, 2015 7:50 pm; edited 1 time in total |
|
| Back to top |
|
 |
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Nov 19, 2015 6:28 pm Post subject: Re: [zsh] Tips |
|
|
SpaceToast ... this really belongs in the ZSH users (lovers?) thread ... even though you mention oh-my-don't-mention-that-word ;) ... I've asked mods to move it.
| SpaceToast wrote: | | ZDOTDIR: This is where your zsh dot-files are located, and defaults to $HOME. To keep your home directory clean, you can set this to somewhere else, for example ~/.config/zsh. You can either do this globally somewhere in /etc or you can simply put it into ~/.zshenv. |
Hehe ... "clean", the reason its the "default" is that this is the standard location for dotfiles ... regardless of what the "XDG specification (sic)" claims on the matter. There is nothing "unclean" about it ... infact the addition of .{config,cache,local} does nothing to change that fact (except perhaps making a parallel "standard").
| Code: | % print ${#$(print -rl ~/.*(.))}\\n${#$(print -rl ~/.*(/))}
70
32
% print ${#$(print -rl .config/*(/))}
5 |
Also, your suggestion to do this "globbally" would lead your users to have no choice in the matter as /etc/zsh/zshenv is read on every call to zsh and "cannot be overridden" ... see 'man zshall | less -p "STARTUP/SHUTDOWN FILES"' ... it's not even possible to overide with NO_GLOBAL_RCS.
| SpaceToast wrote: | | Code: | : "${XDG_CACHE_HOME:=$HOME/.cache}"
: "${XDG_CONFIG_HOME:=$HOME/.config}"
: "${XDG_DATA_HOME:=$HOME/.local/share}"
: "${ZDOTDIR:=$XDG_CONFIG_HOME/zsh}" |
|
Given ~/.zshenv is sourced on every call to zsh (interactive or not), anything of this nature should be within a test condition:
| $ZDOTDIR/.zshenv: | if [[ -o rcs ]]; then
:
fi |
| SpaceToast wrote: | | There are several projects that exist in order to simplify configuration and provide some built in functionality + plugins. The more notable ones (that actually provide a form of lib) are oh-my-zsh and prezto. |
If by "notable" you mean "should be avoided" then yes, by all means ;) The point about configuration is that the "user" is configuring the shell to meet their needs ... that requires a user at point of origin, if you opt for a ready made do-my-zsh then the user never aquires any understanding of how the shell is configured, or what such "functionality" is doing, why they need it, etc, etc. Added to this is the level of oh-my-brokeness that becomes a caccophany of user support requests ... on #zsh you won't recieve any support for oh-my-zsh because the task is too daunting.
| SpaceToast wrote: | | Most zshrc will typically try to include everything in them, and as a result become unreadable and difficult to edit. The solution is to do similar thing to /etc/profile.d, and simply source through everything in ${ZDOTDIR}/*.zsh, for example. |
Well, no, "unreadable and difficult to edit" is entirely dependent on how its organised, commented, etc, also $ZDOTDIR/.zsh/ exists for a specific purpose, it provides a user with a place to add to, or modify the functions, completions, etc in $fpath
| Code: | % print -rl $fpath
/home/khayyam/.zsh/completions
/home/khayyam/.zsh/functions.zwc
/home/khayyam/.zsh/functions
/home/khayyam/.zsh/scripts
/usr/local/share/zsh/site-functions
/usr/share/zsh/site-functions
/usr/share/zsh/5.1.1/functions/Calendar
/usr/share/zsh/5.1.1/functions/Chpwd
/usr/share/zsh/5.1.1/functions/Completion
/usr/share/zsh/5.1.1/functions/Completion/Base
/usr/share/zsh/5.1.1/functions/Completion/Linux
/usr/share/zsh/5.1.1/functions/Completion/Unix
/usr/share/zsh/5.1.1/functions/Completion/X
/usr/share/zsh/5.1.1/functions/Completion/Zsh
/usr/share/zsh/5.1.1/functions/Exceptions
/usr/share/zsh/5.1.1/functions/MIME
/usr/share/zsh/5.1.1/functions/Misc
/usr/share/zsh/5.1.1/functions/Newuser
/usr/share/zsh/5.1.1/functions/Prompts
/usr/share/zsh/5.1.1/functions/TCP
/usr/share/zsh/5.1.1/functions/VCS_Info
/usr/share/zsh/5.1.1/functions/VCS_Info/Backends
/usr/share/zsh/5.1.1/functions/Zftp
/usr/share/zsh/5.1.1/functions/Zle |
... so while breaking .zshrc down into smaller files is an option, $ZDOTDIR/.zsh is not something you want to "source through everything in". In fact, you should be using .zsh/ to organise completions, functions, etc ... eg:
| $ZDOTDIR/.zshrc: | zdotdir=${ZDOTDIR:-$HOME}
fpath=($zdotdir/{.zsh/*.zwc,.zsh/{functions,scripts}}(N) $fpath)
# Autoload functions that have the executable bit on.
for d in $fpath; do
fns=( $d/*~*~(N.x:t) )
(( ${#fns} )) && autoload $fns
done
# Add $zdotdir/.zsh/completions to $fpath
fpath=($zdotdir/.zsh/completions $fpath) |
| SpaceToast wrote: | | In terms of builtin functionality, I recommend zgen, which hardcodes strings to source (regenerating on demand) and lets you mix and match your own and any other plugins you wish (and allows you to use either of the two libs). My current zshrc can be found here as an example. |
Hehe ... zsh has "plugins"? Next you'll be telling us *nix has "folders" ;) .. seriously though, that would seem to be a case of using a metaphor from winamp, and the like, for a "shell". Anyhow, check-out my zsh config files ... mostly well commented, and hopefully transparent as to my intentions, and to what its doing.
best ... khay |
|
| Back to top |
|
|
SpaceToast
n00b
Joined: 16 Oct 2015
Posts: 19
|
| Posted: Thu Nov 19, 2015 7:47 pm Post subject: |
|
|
| khayyam wrote: | SpaceToast ... this really belongs in the ZSH users (lovers?) thread ... even though you mention oh-my-don't-mention-that-word  ... I've asked mods to move it. |
Igli set me up! I swear
| khayyam wrote: | | Hehe ... "clean", the reason its the "default" is that this is the standard location for dotfiles ... regardless of what the "XDG specification (sic)" claims on the matter. There is nothing "unclean" about it ... infact the addition of .{config,cache,local} does nothing to change that fact (except perhaps making a parallel "standard"). |
This is rather off-topic, but the reason that I like the XDG specification is that in the end, it allows for going through / having many configs in a more manageable way. Dotfiles are dotfiles (with a leading dot) so they don't show up normally (e.g ls). As such you need to add an -A to ls, for example. .config and the like centralize this under a single directory: if you're going into ~/.config, you're looking for config files, so there's no longer a reason to hide them. Just slight QoL improvements.
| khayyam wrote: | | Also, your suggestion to do this "globbally" would lead your users to have no choice in the matter as /etc/zsh/zshenv is read on every call to zsh and "cannot be overridden" ... see 'man zshall | less -p "STARTUP/SHUTDOWN FILES"' ... it's not even possible to overide with NO_GLOBAL_RCS. |
I'm actually aware of this. I'm suggesting to do it in ~/.zshenv, but wanted to mention the possibility of doing it in /etc. Will add note on the side effect.
| khayyam wrote: | | if [[ -o rcs ]] |
Oh! Missed that part of STARTUP/SHUTDOWN. Will do.
| khayyam wrote: | | If by "notable" you mean "should be avoided" |
By "notable" I mean "large" (which I typically find a bad thing). I do think they need to be mentioned (some bits here and there can be used, sometimes).
| khayyam wrote: | | $ZDOTDIR/.zsh is not something you want to "source through everything in" |
Seems to be a point of miscommunication, not sourcing everything in $ZDOTDIR/.zsh/*, but rather $ZDOTDIR/*.zsh (or, in my current config, $ZDOTDIR/*.zrc, to get rid of such ambiguity, in part).
| khayyam wrote: | | zsh has "plugins"? Next you'll be telling us *nix has "folders" |
I call anything I can "plug out" (remove with minimal effort) a plug-in  I don't really care what an EDT developer in the 70s thought about it, or what people have assumed it to mean. Syntactically it makes sense! (And GIF is pronounced gif. Because you don't need to spell it out, like "jiff")
| khayyam wrote: | | Anyhow, check-out my zsh config files |
Will do~ |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Thu Nov 19, 2015 9:31 pm Post subject: |
|
|
| khayyam wrote: | | Hehe ... "clean", the reason its the "default" is that this is the standard location for dotfiles ... regardless of what the "XDG specification (sic)" claims on the matter. There is nothing "unclean" about it ... infact the addition of .{config,cache,local} does nothing to change that fact (except perhaps making a parallel "standard"). |
| SpaceToast wrote: | | This is rather off-topic, but the reason that I like the XDG specification is that in the end, it allows for going through / having many configs in a more manageable way. Dotfiles are dotfiles (with a leading dot) so they don't show up normally (e.g ls). As such you need to add an -A to ls, for example. .config and the like centralize this under a single directory: if you're going into ~/.config, you're looking for config files, so there's no longer a reason to hide them. Just slight QoL improvements. |
SpaceToast ... except that it doesn't ... the above count of dotfiles, .directories, and .config/* shows that it doesn't make it any more "managable", it justs adds additional directories in which you might have to look, and so, in fact, makes it less managable. To this XDG advocates tend to reply "well, thats because x,y,z does't follow the specification", but that is a poor argument, its not acceptable to introduce a "specification" and then say the previous 'standard', or methodology, is broken when not switching to it, a standard, or specification, is not only adherence, it needs to provide some method of managing the transition, and/or provide some reason for doing so ... in short its not something that freedesktop.org can author and then say "you need to adhere to it" ... particualy when, as the above shows, the majority doesn't. Now, fine, if this is something you perfer I'm OK with that, have your XDG_CONFIG_HOME, but please allow me to say NO_XDG and store such dotfiles, and directories, in a perfectly workable, and valid, location. The point I was making is that there is nothing "cleaner" about the specification, if I were able to disable it I'd probably not make an issue of it, but as the specification actually adds to the (imagined) problem, and as I'm not able to disable it, I'll call it for the poorly implimented fluff it is.
| SpaceToast wrote: | | khayyam wrote: | | If by "notable" you mean "should be avoided" |
By "notable" I mean "large" (which I typically find a bad thing). I do think they need to be mentioned (some bits here and there can be used, sometimes). |
Well, I take notable to mean "worthy of mention", and while getting to grips with zsh configuration isn't something a user will instantly grasp I'd generally recommend not using such things, but starting from the basics, and learning what things do, how you can change them, etc.
| SpaceToast wrote: | | khayyam wrote: | | $ZDOTDIR/.zsh is not something you want to "source through everything in" |
Seems to be a point of miscommunication, not sourcing everything in $ZDOTDIR/.zsh/*, but rather $ZDOTDIR/*.zsh (or, in my current config, $ZDOTDIR/*.zrc, to get rid of such ambiguity, in part). |
Ummm ... ok ... but surely '*.zsh' denotes a script, and why in your 'zshrc' (aka 'zgen.zrc') linked above do you have a hash-bang when its being sourced? I'm not opposed to spliting out the config (I also source a $ZDOTDIR/.zshrc-local ... if it exists) but this seems to be needlessly complicated and, well, odd.
| SpaceToast wrote: | | khayyam wrote: | | zsh has "plugins"? Next you'll be telling us *nix has "folders" |
I call anything I can "plug out" (remove with minimal effort) a plug-in :) I don't really care what an EDT developer in the 70s thought about it, or what people have assumed it to mean. Syntactically it makes sense! |
I suppose that depends on who you ask, or whom you're explaining it to ... *nix doesn't have "folders", this is a DE metaphor (derived from OSX), I'm inclined to fain ignorance, as my world is populated with directories, paths, pipes, variables, etc, etc, and I expect that those entering my world don't bring maps from other OSes and expect they can stop me in the street and ask " ¿donde esta la musica?" and I'll somehow understand them. This is particularly true of shell, scripts, completions, etc ... we don't have plugins, we have builtins, commands, functions, aliases, etc, etc. If someone says "plugins", or "shortcuts", then they are not speaking about shell.
best ... khay |
|
| Back to top |
|
|
SpaceToast
n00b
Joined: 16 Oct 2015
Posts: 19
|
| Posted: Fri Nov 20, 2015 12:51 am Post subject: |
|
|
| khayyam wrote: | | SpaceToast ... except that it doesn't ... the above count of dotfiles, .directories, and .config/* shows that it doesn't make it any more "managable", it justs adds additional directories in which you might have to look, and so, in fact, makes it less managable. To this XDG advocates tend to reply "well, thats because x,y,z does't follow the specification", but that is a poor argument, its not acceptable to introduce a "specification" and then say the previous 'standard', or methodology, is broken when not switching to it, a standard, or specification, is not only adherence, it needs to provide some method of managing the transition, and/or provide some reason for doing so ... in short its not something that freedesktop.org can author and then say "you need to adhere to it" ... particualy when, as the above shows, the majority doesn't. Now, fine, if this is something you perfer I'm OK with that, have your XDG_CONFIG_HOME, but please allow me to say NO_XDG and store such dotfiles, and directories, in a perfectly workable, and valid, location. The point I was making is that there is nothing "cleaner" about the specification, if I were able to disable it I'd probably not make an issue of it, but as the specification actually adds to the (imagined) problem, and as I'm not able to disable it, I'll call it for the poorly implimented fluff it is. |
In the end it does come down to preference though. e.g I find it better to have ~/.config/vim/ and ~/.config/vim/init.vim rather than ~/.vim/ and ~/.vimrc : if I'm looking vim stuff, I can stroll into ~/.config/vim and they will all be there, rather than several (hidden) files under $HOME, and then the rest under ~/.vim/. The primary reason I mention it at all is because, while having the default usage of $HOME is trivial (simply don't do anything), putting things into $XDG_CONFIG_HOME is less immediately obvious (even though support technically exists).
| khayyam wrote: | | Well, I take notable to mean "worthy of mention", and while getting to grips with zsh configuration isn't something a user will instantly grasp I'd generally recommend not using such things, but starting from the basics, and learning what things do, how you can change them, etc. |
A potential use for oh-my-fluff is getting a default set of opts (e.g see: set -o), an introduction to the opts. In the end, both of those are simply a set of opts, completions and scripts (e.g git data). Moreover, both of those provide a gathering point for examples of "things you can do" with zsh (e.g the sudo "plugin"), and which can be used independently of o-m-z.
| khayyam wrote: | | Ummm ... ok ... but surely '*.zsh' denotes a script, and why in your 'zshrc' (aka 'zgen.zrc') linked above do you have a hash-bang when its being sourced? I'm not opposed to spliting out the config (I also source a $ZDOTDIR/.zshrc-local ... if it exists) but this seems to be needlessly complicated and, well, odd. |
I'll be fully honest here, I #! because I'm too lazy to # vim:ft=zsh, though I probably should, eventually. In terms of odd that's quite possible, I typically make my configs (and just about everything else) bottom-up, as the need arises, which can sometimes lead to weirdness. Will probably rewrite it once I get to it.
| khayyam wrote: | | I suppose that depends on who you ask, or whom you're explaining it to ... *nix doesn't have "folders", this is a DE metaphor (derived from OSX), I'm inclined to fain ignorance, as my world is populated with directories, paths, pipes, variables, etc, etc, and I expect that those entering my world don't bring maps from other OSes and expect they can stop me in the street and ask " ¿donde esta la musica?" and I'll somehow understand them. This is particularly true of shell, scripts, completions, etc ... we don't have plugins, we have builtins, commands, functions, aliases, etc, etc. If someone says "plugins", or "shortcuts", then they are not speaking about shell. |
Arguably, all of those things are just different kinds of files We can call them any kinds of different things we want, to differentiate more easily, without changing what they really are. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Nov 20, 2015 2:52 pm Post subject: |
|
|
| SpaceToast wrote: | | khayyam wrote: | | [...] Now, fine, if this is something you prefer I'm OK with that, have your XDG_CONFIG_HOME, but please allow me to say NO_XDG and store such dotfiles, and directories, in a perfectly workable, and valid, location. [...] |
In the end it does come down to preference though. |
SpaceToast ... this is getting silly, its neither "cleaner", "more manageable", or a matter of "preference" ... its a specification with little in the way of justification behind it. If, by means of the specification (ie, setting NO_XDG_CONFIG), I was able to disable it, then that would make it a matter of preference. The specification doesn't provide for that because that would allow for me to continue to work in ways that freedesktop.org has decided are obsolete, in other words "wrong". I just have to put up with the fact that "cleaner" and "more manageable", means "having a parallel namespace for storing config files", ie, more of the same. Similarly, I'm expected to have xdg-utils (and its dependencies) so that a professional grade network analysis tool can set a preference, and am provided a warning when some app doesn't find xdg-screensaver, or the like. So, you'll forgive me for rejecting the various reasons provided as to why the specification is a "good idea".
| SpaceToast wrote: | | [...] e.g I find it better to have ~/.config/vim/ and ~/.config/vim/init.vim rather than ~/.vim/ and ~/.vimrc : if I'm looking vim stuff, I can stroll into ~/.config/vim and they will all be there, rather than several (hidden) files under $HOME, and then the rest under ~/.vim/. |
It's not "several (hidden) files", it's one file, ~/.vimrc ... you're making it seem like there is some reason that underscores the rational for the existence of ~/.config, when there isn't. But ok, I'll follow your logic ... I find it better to have a backslash as a designator of path, it doesn't make any sense that I should have to use c:\\ and then have to switch to http:// if I access some webpage, the new specification (authored by me) states that its "cleaner", "more manageable", etc, that we use the new schema, and x,y,z needs to get up to speed and support it.
| SpaceToast wrote: | | The primary reason I mention it at all is because, while having the default usage of $HOME is trivial (simply don't do anything), putting things into $XDG_CONFIG_HOME is less immediately obvious (even though support technically exists). |
OK, but you're also validating the specification and suggesting this is advisable for some reason.
| SpaceToast wrote: | | khayyam wrote: | | Well, I take notable to mean "worthy of mention", and while getting to grips with zsh configuration isn't something a user will instantly grasp I'd generally recommend not using such things, but starting from the basics, and learning what things do, how you can change them, etc. |
A potential use for oh-my-fluff is getting a default set of opts (e.g see: set -o), an introduction to the opts. In the end, both of those are simply a set of opts, completions and scripts (e.g git data). Moreover, both of those provide a gathering point for examples of "things you can do" with zsh (e.g the sudo "plugin"), and which can be used independently of o-m-z. |
Its better to be at the bottom of a ladder you want to climb than half way up one you don't. You're omitting to take into account what I pointed out above, the user, its the user that underscores "use", and use involves skill. That's not something that can be circumvented. What tends to happen when "usability" supplants skill is that the user becomes subjected to the interface, rather than the software, and in doing so are prevented from understanding how it works (interface being layered over the software). In the case of oh-my-zsh (which, I should note, is developed within an almost exclusively OSX environment) its focus is on doing everything, and trivial things like themes, etc, etc, because its not about understanding, or skill, its about the surface. It is in such an environment that "things you can do" are really "things o-m-z does", and little is understood about it (other than "oh-my-shiny" prompt). It conditions users, and in so doing you end up with users who pop into #zsh to ask "I'm using o-m-z ... why doesn't x,y,z work?", or "how do I get a prompt like the one in this picture?".
| SpaceToast wrote: | | khayyam wrote: | | I suppose that depends on who you ask, or whom you're explaining it to ... *nix doesn't have "folders", this is a DE metaphor (derived from OSX), I'm inclined to fain ignorance, as my world is populated with directories, paths, pipes, variables, etc, etc, and I expect that those entering my world don't bring maps from other OSes and expect they can stop me in the street and ask " ¿donde esta la musica?" and I'll somehow understand them. This is particularly true of shell, scripts, completions, etc ... we don't have plugins, we have builtins, commands, functions, aliases, etc, etc. If someone says "plugins", or "shortcuts", then they are not speaking about shell. |
Arguably, all of those things are just different kinds of files :) We can call them any kinds of different things we want, to differentiate more easily, without changing what they really are. |
No, builtins, functions, variables, aliases, etc, are not "files". If you want to argue that such terminology is superfluous, then I'll have to fain ignorance of what it is you're singing about.
best ... khay |
|
| Back to top |
|
|
steveL
Watchman
Joined: 13 Sep 2006
Posts: 5153
Location: The Peanut Gallery
|
| Posted: Fri Nov 20, 2015 3:20 pm Post subject: |
|
|
FWIW I agree that XDG directories are a PITA, obfuscating .foo under ~/.cache/foo or ~/.apps/foo etc (usually longer.)
Not sure how relevant it is; the dotdir thing was only "an example" and can be improved, in line with khayyam's recommendation for subdirs of .zsh. (Certainly doesn't merit a page of argumentation^W discussion, imo ;)
As for merging it with zsh-lovers, no thanks; please link from there to here, by all means, but let's work with SpaceToast around her setup, and documentation.
I'd have to dig thru IRC logs, but I'm pretty sure it was about what you can do, not zsh itself; those things are what I wanted SpaceToast to document (bfeore they get forgotten, as I sure as hell ain't pulling them out of logs over time.;)
Regards,
igli
Oh, and welcome to the forums, SpaceToast :-) You're going to fit right in, and be an asset to the community (when you're mellow, as for all of us. ;) |
|
| Back to top |
|
|
SpaceToast
n00b
Joined: 16 Oct 2015
Posts: 19
|
| Posted: Fri Nov 20, 2015 4:47 pm Post subject: |
|
|
| khayyam wrote: | | It's not "several (hidden) files", it's one file, ~/.vimrc |
.vimrc, .viminfo, .viminfo.tmp, .vim/*
Even moving all of the .vim* into .vim/* would already be an improvement.
| khayyam wrote: | | which, I should note, is developed within an almost exclusively OSX environment |
OSX is certified by The Open Group and POSIX compliant. As such, I don't see why this matters.
| khayyam wrote: | | you end up with users who pop into #zsh to ask "I'm using o-m-z ... why doesn't x,y,z work?", or "how do I get a prompt like the one in this picture?". |
You'd end up with these users either way. In fact, you'd end up with the latter even if o-m-z didn't exist. There will always be people who are not interested in learning the functionality of what they are using. If we simply put those users behind a wall of "don't come here" and stick a pitchfork out, they'll simply use the next thing (e.g bash) and have the same problems.
| steveL wrote: | | can be improved, in line with khayyam's recommendation for subdirs of .zsh |
I'm already brewing a few ideas that are more or less in line with what I'd like to have and are more sane than what I'm doing now
| steveL wrote: | | Oh, and welcome to the forums, SpaceToast You're going to fit right in, and be an asset to the community (when you're mellow, as for all of us. |
Am I ever really mellow?
| steveL wrote: | As for merging it with zsh-lovers, no thanks; please link from there to here, by all means, but let's work with SpaceToast around her setup, and documentation.
I'd have to dig thru IRC logs, but I'm pretty sure it was about what you can do, not zsh itself; those things are what I wanted SpaceToast to document (bfeore they get forgotten, as I sure as hell ain't pulling them out of logs over time. |
You wanted me to document the byobu/tmux thing specifically  (and good thing I did! the hint on -o rcs is actually an important thing I completely missed).
I think I'll just use up a good chunk of today just write some new configs...
Part of the reason I like "plugins" is that some functionality (again, the sudo "plugin" from O-M-Z, for example) is reasonable and independent from the framework; and there's no reason to rewrite the wheel in such circumstances (so I'll stand behind zgen being a thing), but I do agree that o-m-z (as a whole) is fairly terrible.
Anyway, I can see that khayyam is strongly opposed to XDG (having read the arguments I can see why, and agree that a NO_XDG_CONFIG should be added), but I also don't believe that "validating the specification" or suggesting it as an alternative for people who do hold the preference (just because some do not make it optional does not change that people implementing things do so based on preference) is evil, and merits what is slowly becoming a flame war, so I'm going to avoid any further comments on this. |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Fri Nov 20, 2015 8:24 pm Post subject: |
|
|
| SpaceToast wrote: | | khayyam wrote: | | It's not "several (hidden) files", it's one file, ~/.vimrc |
.vimrc, .viminfo, .viminfo.tmp, .vim/* Even moving all of the .vim* into .vim/* would already be an improvement. |
SpaceToast ... you're being disingenuous, do you ever have to go looking for .viminfo.{,tmp} so you can edit them? Besides, these are all configurable, see ':he viminfo-file-name', ':he initialization', and 'he: $VIM'. If you move ~/.vimrc to ~/.vim/vimrc it is automatically used, you can also use 'vim -u' to point to your $XDG_CONFIG_HOME/vim/vimrc, or use $VIM to setup whatever location you want for support files. Also, tmpfiles can be disabled, written to $TMPDIR or some other location.
| SpaceToast wrote: | | khayyam wrote: | | which, I should note, is developed within an almost exclusively OSX environment |
OSX is certified by The Open Group and POSIX compliant. As such, I don't see why this matters. |
That was a point of 'note', and it was in relation to how a community brings with it its mode of thinking, expectations, metaphors, etc, not its relation to its adherence to POSIX (or not).
| SpaceToast wrote: | | khayyam wrote: | | you end up with users who pop into #zsh to ask "I'm using o-m-z ... why doesn't x,y,z work?", or "how do I get a prompt like the one in this picture?". |
You'd end up with these users either way. In fact, you'd end up with the latter even if o-m-z didn't exist. There will always be people who are not interested in learning the functionality of what they are using. If we simply put those users behind a wall of "don't come here" and stick a pitchfork out, they'll simply use the next thing (e.g bash) and have the same problems. |
That could be argued, but I don't think it's true (while I'd admit there is both some level of nature, and nurture, involved), you also have to take into account that peoples expectations are conditioned by an industry which expects they not be users, in the sense I outline above, but a target audience (ie, consumers). So, it is far more a question of pedagogy than human behaviour, and there is a barrier to learning, and skill acquisition. Rather than pitchforks, or signs, its simply a matter of there being something that someone can claim to know (to some extent) and the task of acquiring that knowledge. The problem I was getting at above is the expectation that users need not know (because someone or other will provide a means to short circuit that difficult climb, and place them half way up the ladder).
| SpaceToast wrote: | | Anyway, I can see that khayyam is strongly opposed to XDG (having read the arguments I can see why, and agree that a NO_XDG_CONFIG should be added), but I also don't believe that "validating the specification" or suggesting it as an alternative for people who do hold the preference (just because some do not make it optional does not change that people implementing things do so based on preference) is evil, and merits what is slowly becoming a flame war, so I'm going to avoid any further comments on this. |
I am strongly opposed ... but I feel I can provide good reasons why. As to the question of "validating", then, sorry its not about "preference", as I've outlined in the past, not all choices are equal, my choice to piss in the water supply upstream from you is not equal to your choice to drink it or not.
best ... khay |
|
| Back to top |
|
|
desultory
Bodhisattva
Joined: 04 Nov 2005
Posts: 9410
|
| Posted: Sat Nov 21, 2015 4:54 am Post subject: |
|
|
| khayyam wrote: | | If you want to argue that such terminology is superfluous, then I'll have to fain ignorance of what it is you're singing about. |
You will be forced to be cheerfully prone to ignorance? That makes no sense.
| khayyam wrote: | | SpaceToast wrote: | | khayyam wrote: | | It's not "several (hidden) files", it's one file, ~/.vimrc |
.vimrc, .viminfo, .viminfo.tmp, .vim/* Even moving all of the .vim* into .vim/* would already be an improvement. |
SpaceToast ... you're being disingenuous, do you ever have to go looking for .viminfo.{,tmp} so you can edit them? Besides, these are all configurable, see ':he viminfo-file-name', ':he initialization', and 'he: $VIM'. If you move ~/.vimrc to ~/.vim/vimrc it is automatically used, you can also use 'vim -u' to point to your $XDG_CONFIG_HOME/vim/vimrc, or use $VIM to setup whatever location you want for support files. Also, tmpfiles can be disabled, written to $TMPDIR or some other location.
| SpaceToast wrote: | | khayyam wrote: | | which, I should note, is developed within an almost exclusively OSX environment |
OSX is certified by The Open Group and POSIX compliant. As such, I don't see why this matters. |
That was a point of 'note', and it was in relation to how a community brings with it its mode of thinking, expectations, metaphors, etc, not its relation to its adherence to POSIX (or not).
| SpaceToast wrote: | | khayyam wrote: | | you end up with users who pop into #zsh to ask "I'm using o-m-z ... why doesn't x,y,z work?", or "how do I get a prompt like the one in this picture?". |
You'd end up with these users either way. In fact, you'd end up with the latter even if o-m-z didn't exist. There will always be people who are not interested in learning the functionality of what they are using. If we simply put those users behind a wall of "don't come here" and stick a pitchfork out, they'll simply use the next thing (e.g bash) and have the same problems. |
That could be argued, but I don't think it's true (while I'd admit there is both some level of nature, and nurture, involved), you also have to take into account that peoples expectations are conditioned by an industry which expects they not be users, in the sense I outline above, but a target audience (ie, consumers). So, it is far more a question of pedagogy than human behaviour, and there is a barrier to learning, and skill acquisition. Rather than pitchforks, or signs, its simply a matter of there being something that someone can claim to know (to some extent) and the task of acquiring that knowledge. The problem I was getting at above is the expectation that users need not know (because someone or other will provide a means to short circuit that difficult climb, and place them half way up the ladder).
| SpaceToast wrote: | | Anyway, I can see that khayyam is strongly opposed to XDG (having read the arguments I can see why, and agree that a NO_XDG_CONFIG should be added), but I also don't believe that "validating the specification" or suggesting it as an alternative for people who do hold the preference (just because some do not make it optional does not change that people implementing things do so based on preference) is evil, and merits what is slowly becoming a flame war, so I'm going to avoid any further comments on this. |
I am strongly opposed ... but I feel I can provide good reasons why. As to the question of "validating", then, sorry its not about "preference", as I've outlined in the past, not all choices are equal, my choice to piss in the water supply upstream from you is not equal to your choice to drink it or not. |
I stand corrected, Mr. Grylls (follow that link at your own risk, though is it apropos the analogy drawn by khayyam). |
|
| Back to top |
|
|
khayyam
Watchman
Joined: 07 Jun 2012
Posts: 6227
Location: Room 101
|
| Posted: Sat Nov 21, 2015 8:54 am Post subject: |
|
|
| desultory wrote: | | khayyam wrote: | | If you want to argue that such terminology is superfluous, then I'll have to fain ignorance of what it is you're singing about. |
You will be forced to be cheerfully prone to ignorance? That makes no sense. |
desultory ... the point being (wrt terminateology) both 'fain', and 'singing', provide a clue to an intended meaning without their having to make "sense" ... that's what feigning ignorance involves. Now, take your plugin and sensitise it ;)
best ... khay |
|
| Back to top |
|
|
|
|
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
|
|
Documentation, Tips & Tricks
