* Default usability wiki page set up @ 2005-07-13 5:46 Keir Mierle 2005-07-13 8:01 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Keir Mierle @ 2005-07-13 5:46 UTC (permalink / raw) To: zsh-workers I set up a page where we can discuss the default usability of ZSH. http://zshwiki.org/NiceZshDefaults Perhaps we could get a better conses on things before I start implementing code that won't be accepted? Thanks, Keir ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Default usability wiki page set up 2005-07-13 5:46 Default usability wiki page set up Keir Mierle @ 2005-07-13 8:01 ` Bart Schaefer 2005-07-14 2:49 ` Keir Mierle 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-07-13 8:01 UTC (permalink / raw) To: zsh-workers On Jul 13, 1:46am, Keir Mierle wrote: } } Perhaps we could get a better conses on things before I start } implementing code that won't be accepted? I've been waiting to see where this discussion would go, but so far it seems rather one-sided, so ... The first thing you have to explain is exactly where you think we should put these defaults. You keep using the phrase "out of the box" without seeming to notice that there is no box -- and I don't mean in the obvious sense that zsh is distributed electronically. We don't control what gets installed in the /etc/z* files; it would instantly alienate the very sysadmins who have to make zsh available to their users if "make install" stomped on whatever they may already have in those files; and back when we included samples in the source distribution, the results were messy to the point of near-disaster because of inattention on the part of (for example) the people at RedHat who created the zsh RPM. (Those sorts of packagings are the closest zsh comes to a "box", but -- except for, say, Clint, who actively contributes to this list as the Debian packager -- the zsh maintainers are not the people who pack those boxes.) We're even farther from being able to control the default "skeleton" that sets up individual users' home directories. Before any other discussion is useful, the bootstrap problem has to be solved. As for "Make completions Just Work(TM)" I'm not sure how much closer you want us to get. There are 460 completion functions now included in the distribution, plus "compinstall" to interactively set up your init files to use them; and commands like xpdf and acroread *do* have completions that are limited to files they're likely to understand, once the completion system has been enabled. It's also worth noting that a significant source of complaints when lots of nifty defaults are provided is that the shell (or any other program) begins to take much longer to start up. I can't tell you how annoyed I am when I find that a sysadmin has preset the LESSOPEN environment for me to the horrible lesspipe.sh, and I end up waiting several seconds every time I want to look at a text file while this stupid script analyzes it seven ways from Tuesday to decide if it should uncompress it or unzip it or some other thing that only needs to happen in a tiny fraction of the actual cases where I use less. This is an example of killing usability in the name of ease of use, and it's where every discussion of "better program defaults" that I have ever seen (and I don't mean just for zsh) always ends up going. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Default usability wiki page set up 2005-07-13 8:01 ` Bart Schaefer @ 2005-07-14 2:49 ` Keir Mierle 2005-07-14 9:55 ` Bart Schaefer 0 siblings, 1 reply; 5+ messages in thread From: Keir Mierle @ 2005-07-14 2:49 UTC (permalink / raw) To: Bart Schaefer; +Cc: zsh-workers On 7/13/05, Bart Schaefer <schaefer@brasslantern.com> wrote: > On Jul 13, 1:46am, Keir Mierle wrote: > } > } Perhaps we could get a better conses on things before I start > } implementing code that won't be accepted? > > I've been waiting to see where this discussion would go, but so far > it seems rather one-sided, so ... > > The first thing you have to explain is exactly where you think we > should put these defaults. You keep using the phrase "out of the > box" without seeming to notice that there is no box -- and I don't > mean in the obvious sense that zsh is distributed electronically. When thinking about usability, it is practical to forget about implementation details until some idea of what to put in place arises. Sure, it is easy to come up with ideas that are not possible to implement, but it is just as easy to miss ideas because the discussion becomes embroiled in implementation details. This is common practice in industry, and is how our team is designing the new interface for Trac (see our project, http://www.third-bit.com/trac/argon). I absolutely agree, implementation details need to be fleshed out-- but I was avoiding them to hold out for what sorts of default niceties the zsh dev base would be willing to consider. > We don't control what gets installed in the /etc/z* files; it would > instantly alienate the very sysadmins who have to make zsh available > to their users if "make install" stomped on whatever they may already > have in those files; and back when we included samples in the source > distribution, the results were messy to the point of near-disaster > because of inattention on the part of (for example) the people at > RedHat who created the zsh RPM. (Those sorts of packagings are the > closest zsh comes to a "box", but -- except for, say, Clint, who > actively contributes to this list as the Debian packager -- the zsh > maintainers are not the people who pack those boxes.) Fair enough. I agree, we do not directly control what goes into the /etc/z*, but would make install not clobber these files now? I glanced through Makefile.in; I can not tell either way. I am not a shell expert, I was hoping someone on this list could help with this. > We're even farther from being able to control the default "skeleton" > that sets up individual users' home directories. Before any other > discussion is useful, the bootstrap problem has to be solved. This is a hack, and ugly, but perhaps we could check for the existance of a .zshrc, and if not, invoke a 'first time? want some help?' mode that takes the user through a couple things and then creates a .zshrc? For example, 'first time' mode sets up prompt (via promptinit, which I just discovered a few minutes ago, all this time I'd been manually specifying my prompt) and completion via compinit (which is immensely better than setting up completions manually, but still needs some work). If they veto the tutorial (though I'm hesitant to call it that), then 'touch .zshrc' would prevent future invocations. > As for "Make completions Just Work(TM)" I'm not sure how much closer > you want us to get. There are 460 completion functions now included > in the distribution, plus "compinstall" to interactively set up your > init files to use them; and commands like xpdf and acroread *do* have > completions that are limited to files they're likely to understand, > once the completion system has been enabled. Cool, I didn't know about compinstall. I tried running it, no luck. This is probably debian specific, but with zsh installed, there is no hint about where compinstall is. Thankfully, I'm a seasoned debian user, and know how to figure this out. keir@howl ~ % dpkg -L zsh|grep compinst /usr/share/zsh/4.2.5/functions/Completion/compinstall Cool, there it is. Ok, let's run it. keir@howl ~ % /usr/share/zsh/4.2.5/functions/Completion/compinstall zsh: permission denied: /usr/share/zsh/4.2.5/functions/Completion/compinstall Huh? Perhaps 'file not executable' would have been better. keir@howl ~ % zsh /usr/share/zsh/4.2.5/functions/Completion/compinstall I haven't found any existing completion definitions..... Success! I needed to run it under zsh. Should have been obvious. But it wasn't... > It's also worth noting that a significant source of complaints when > lots of nifty defaults are provided is that the shell (or any other > program) begins to take much longer to start up. I can't tell you > how annoyed I am when I find that a sysadmin has preset the LESSOPEN > environment for me to the horrible lesspipe.sh, and I end up waiting > several seconds every time I want to look at a text file while this > stupid script analyzes it seven ways from Tuesday to decide if it > should uncompress it or unzip it or some other thing that only needs > to happen in a tiny fraction of the actual cases where I use less. Ok, so let's not set LESSOPEN to lesspipe.sh. And if there's something that causes a signifcant slowdown, then we won't do it. But let's at least consider the possibilities before throwing the baby out with the bathwater. > This is an example of killing usability in the name of ease of use, > and it's where every discussion of "better program defaults" that I > have ever seen (and I don't mean just for zsh) always ends up going. Remember, I want to enhance the default usability of zsh. Not increase ease of use at the expense of usability. I have another crazy idea: Why not add a standard 'help' command? I know it sounds weird that a myself, someone who's used unix as his primary desktop for, oh, 7 years now, has typed 'help completion' or 'help something' on multiple occasions, hoping that zsh can telepathically understand my desires. So how about that? A very simple command, help, in the style of vim's help command (with a short 'h' abbreviation) that first searches zsh's docs, and has quick, helpful pages (with examples!) for various topics, and if no match is found, try the system man pages. Thanks for the detailed response, Keir ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Default usability wiki page set up 2005-07-14 2:49 ` Keir Mierle @ 2005-07-14 9:55 ` Bart Schaefer 2005-07-14 21:16 ` Clint Adams 0 siblings, 1 reply; 5+ messages in thread From: Bart Schaefer @ 2005-07-14 9:55 UTC (permalink / raw) To: zsh-workers On Jul 13, 10:49pm, Keir Mierle wrote: } } Fair enough. I agree, we do not directly control what goes into the } /etc/z*, but would make install not clobber these files now? No, because those files aren't provided anywhere in the source. } This is a hack, and ugly, but perhaps we could check for the existance } of a .zshrc, and if not, invoke a 'first time? want some help?' mode That would be a possibility, though it'd have to look for more than just a .zshrc, and it'd have to operate only for unprivileged users and only in interactive mode, etc. } Cool, I didn't know about compinstall. I tried running it, no luck. } This is probably debian specific, but with zsh installed, there is no } hint about where compinstall is. It's explained in the zsh manual pages (or info files, I'm not a Debian user so I don't know what it installs with zsh). Quote: To run compinstall you will need to make sure it is in a directory mentioned in your fpath parameter, which should already be the case if zsh was properly configured as long as your startup files do not remove the appropriate directories from fpath. Then it must be autoloaded (`autoload -U compinstall' is recommended). You can abort the installation any time you are being prompted for information, and your .zshrc will not be altered at all; changes only take place right at the end, where you are specifically asked for confirmation. } I have another crazy idea: Why not add a standard 'help' command? There's provision for this included with the zsh sources. Once again it's up to the packagers to actually install the files from which the help is read. Admittedly, the script that auto-generates those files probably needs a bit of maintenance that it hasn't received recently. The command is called run-help rather than just help, because it's set up to be invoked by ZLE in a manner similar to completion. Also because back in the day (zsh is going on 20 years old now, remember) there was already a "help" command provided with UNIX systems that did something somewhat different. Setting up the help is mentioned in the manual, too (see "helpfiles"). ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Default usability wiki page set up 2005-07-14 9:55 ` Bart Schaefer @ 2005-07-14 21:16 ` Clint Adams 0 siblings, 0 replies; 5+ messages in thread From: Clint Adams @ 2005-07-14 21:16 UTC (permalink / raw) To: zsh-workers > It's explained in the zsh manual pages (or info files, I'm not a Debian > user so I don't know what it installs with zsh). [...] > There's provision for this included with the zsh sources. Once again > it's up to the packagers to actually install the files from which the > help is read. Admittedly, the script that auto-generates those files > probably needs a bit of maintenance that it hasn't received recently. For the record, the man pages and helpfiles are in the zsh package, and the info files are with the html docs in the zsh-doc package. ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-07-14 21:16 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-07-13 5:46 Default usability wiki page set up Keir Mierle 2005-07-13 8:01 ` Bart Schaefer 2005-07-14 2:49 ` Keir Mierle 2005-07-14 9:55 ` Bart Schaefer 2005-07-14 21:16 ` Clint Adams
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).