Default usability wiki page set up

Default usability wiki page set up

[Keir Mierle]

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

Re: Default usability wiki page set up

[Bart Schaefer]

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.

Re: Default usability wiki page set up

[Keir Mierle]

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

Re: Default usability wiki page set up

[Bart Schaefer]

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").

Re: Default usability wiki page set up

[Clint Adams]

> 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.