From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16693 invoked from network); 14 Jul 2005 02:49:30 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 14 Jul 2005 02:49:30 -0000 Received: (qmail 66964 invoked from network); 14 Jul 2005 02:49:24 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jul 2005 02:49:24 -0000 Received: (qmail 9313 invoked by alias); 14 Jul 2005 02:49:20 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 21457 Received: (qmail 9302 invoked from network); 14 Jul 2005 02:49:18 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 14 Jul 2005 02:49:18 -0000 Received: (qmail 66636 invoked from network); 14 Jul 2005 02:49:18 -0000 Received: from zproxy.gmail.com (64.233.162.198) by a.mx.sunsite.dk with SMTP; 14 Jul 2005 02:49:11 -0000 Received: by zproxy.gmail.com with SMTP id i1so178379nzh for ; Wed, 13 Jul 2005 19:49:09 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HFLvbXJZFsrJ/qvqAO3558HVnhsq6QIYquFnplPTIf6Qp/0k3dVyYFrSrTn5WukDjeAm1F2dyZa7mJjMiNjctLhP9lRBdNtcyBkhgi1XFM6hQ4qG0fw34MKYB9vheoGGCbwrSOWxQPpVwV8T9UKmrDbOQtCuFrUB0m+i3Rj+b+E= Received: by 10.36.42.20 with SMTP id p20mr4968nzp; Wed, 13 Jul 2005 19:49:09 -0700 (PDT) Received: by 10.36.115.16 with HTTP; Wed, 13 Jul 2005 19:49:09 -0700 (PDT) Message-ID: Date: Wed, 13 Jul 2005 22:49:09 -0400 From: Keir Mierle Reply-To: Keir Mierle To: Bart Schaefer Subject: Re: Default usability wiki page set up Cc: zsh-workers@sunsite.dk In-Reply-To: <1050713080132.ZM27122@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <1050713080132.ZM27122@candle.brasslantern.com> X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.5 required=6.0 tests=AWL,BAYES_00,RCVD_BY_IP autolearn=ham version=3.0.2 X-Spam-Hits: -2.5 On 7/13/05, Bart Schaefer 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? >=20 > I've been waiting to see where this discussion would go, but so far > it seems rather one-sided, so ... >=20 > 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. =20 > 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/compinsta= ll 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