Re: Default usability wiki page set up

[Keir Mierle <mierle@xxxxxxxxx>]

On 7/13/05, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> 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