Good, easy to use, upstream defaults for zsh (i.e. improving usability)

Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Keir Mierle]

Zsh is an amazing shell. I've used Zsh for years as my primary shell, and it
has treated me well.

With one problem.

Defaults. Or lack thereof. It is easy to claim that zsh is so customizable that
there cannot possibly be any set of defaults that will satisfy everyone. And
they would be correct. But it is incorrect to say that there cannot be a
default configuration that is superior to the current default, most of the
time, for the vast majority of people.

Ideas:

 * Make completions Just Work(TM) out of the box. I suggest common commands
   such as 'xpdf' or 'acroread' should complete only .pdf files, or tar only
   completing .gz or .bz2.

 * When completing commands, list them with one line help summaries from man
   pages, like the Friendly Interactive SHell does (fish).

 * Add colors or at least boldface to the default prompt. The reasoning behind
   this is straightforward--it seperates command output. It is very difficult
   to tell where the output of one grep finishes and the other starts without a
   colored prompt.

   The default prompt:
   howl%

   is not very useful.

   Something as straightforward as
   keir@howl:~/music %

   is much better, especially when it is in bold or colored.

 * Extremely controversial: make a 'extract' command that intelligently
   handles all sorts of file formats. There is one argument, that says it is
   not zsh's place to do this. There is another, that says this is something
   zsh could do trivially, is very common, exists in virtually everyone's
   .zshrc in one form or another, and could be done once, properly, for the
   last time, upstream. 

 * Extremely controversial: A set of default aliases.

   For example, everyone I know who uses zsh has 'll' bound to ls -l.  I
   suggest adding single letter aliases, 'l' for 'ls', 'p' for ps, or 'e' for
   edit (which invokes $EDITOR). There are many possibilities. What I am
   suggesting is to take action, make a decision, and make a useful set of
   default aliases.

   That's right, I'm suggesting taking a stand, and adding useful functionality
   to zsh that works out of the box. 

 * A good intro doc on using zsh interacitvely that goes over things it does
   differently from other shells, such as good completion or the above default
   aliases. The intro on the zsh website is ok, but it could use some work.

I have other ideas, but the main purpose of this email is to get a feel for
what the zsh developer community thinks about improving the default usability
of zsh.

It is important to note that I am *not* suggesting removing anything from zsh,
or removing any of the customizability-- only that great defaults would make
zsh more popular, more usable, and just plain better (for those who don't want
to spend hours tweaking their shell).

Good defaults benefit power users too, who no longer have to write their own
extract function, or add their own aliases for ls, ps, or whatever.

Thoughts?

Thanks,
Keir

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Mike Hernandez]

On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:
> With one problem.
> 
> Defaults. Or lack thereof. It is easy to claim that zsh is so customizable that
> there cannot possibly be any set of defaults that will satisfy everyone. And
> they would be correct. But it is incorrect to say that there cannot be a
> default configuration that is superior to the current default, most of the
> time, for the vast majority of people.

Though I'm not a developer, I can't help but reply to this.   I've
used many linux distributions, and have built linux from scratch
(linuxfromscratch.org). I've also used FreeBSD and OpenBSD, and OS X. 
Each comes with it's own set of defaults (apart from LFS which has no
default zsh config, due to it's being built directly from source). 
Most programs leave any customization to the end user.  If you use zsh
with any of the above mentioned OSes you'll find a slightly different
set of defaults.

I would prefer, as an end user, that the developers focus their
efforts on producing the best possible shell, and leave the
customization to us.

Mike

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Keir Mierle]

On 7/10/05, Mike Hernandez <sequethin@gmail.com> wrote:
> On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:
> > With one problem.
> >
> > Defaults. Or lack thereof. It is easy to claim that zsh is so customizable that
> > there cannot possibly be any set of defaults that will satisfy everyone. And
> > they would be correct. But it is incorrect to say that there cannot be a
> > default configuration that is superior to the current default, most of the
> > time, for the vast majority of people.
> 
> Though I'm not a developer, I can't help but reply to this.   I've
> used many linux distributions, and have built linux from scratch
> (linuxfromscratch.org). I've also used FreeBSD and OpenBSD, and OS X.
> Each comes with it's own set of defaults (apart from LFS which has no
> default zsh config, due to it's being built directly from source).
> Most programs leave any customization to the end user.  If you use zsh
> with any of the above mentioned OSes you'll find a slightly different
> set of defaults.

So what? Did you stop to think for a second, that if the default zsh
config didn't
suck, then the various distributions might use it?
 
> I would prefer, as an end user, that the developers focus their
> efforts on producing the best possible shell, and leave the
> customization to us.

And as an end user, who on occasion tries to evangelize zsh, I would prefer if 
developers spent a a small amount of time making zsh work well, by default, most
of the time, for most people.

Me: Try zsh, it rocks.
Friend: Ok, I got zsh. This prompt sucks. How do I fix it?
Me: Go get a .zshrc from the net
Friend: Ok, completion doesn't complete .pdf's for acroread like you
said it would.
Me: Go spend hours tweaking your .zshrc.
Friend: Gah! Why don't they just include this by default?
Me: Beats me.
Friend: Screw this, I'm going back to bash. It's available on most
platforms anyway,
why go through the pain of copying around my .zshrc?

It is unclear to me why so many fight so hard to prevent good defaults from 
making it into many products (especially in open source). Not everyone has the
time or motivation to customize and tweak zsh for hours; why not at least try to
make it work well out of the box?

Thanks,
Keir

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Nikolai Weibull]

Keir Mierle wrote:

> On 7/10/05, Mike Hernandez <sequethin@gmail.com> wrote:

> > On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:

> > Though I'm not a developer, I can't help but reply to this.   I've
> > used many linux distributions, and have built linux from scratch
> > (linuxfromscratch.org). I've also used FreeBSD and OpenBSD, and OS
> > X.  Each comes with it's own set of defaults (apart from LFS which
> > has no default zsh config, due to it's being built directly from
> > source).  Most programs leave any customization to the end user.  If
> > you use zsh with any of the above mentioned OSes you'll find a
> > slightly different set of defaults.

> So what? Did you stop to think for a second, that if the default zsh
> config didn't suck, then the various distributions might use it?
 
How are any of the other shells’ defaults any better?

> > I would prefer, as an end user, that the developers focus their
> > efforts on producing the best possible shell, and leave the
> > customization to us.

> And as an end user, who on occasion tries to evangelize zsh, I would
> prefer if developers spent a a small amount of time making zsh work
> well, by default, most of the time, for most people.
> 
> Me: Try zsh, it rocks.
> Friend: Ok, I got zsh. This prompt sucks. How do I fix it?
> Me: Go get a .zshrc from the net
> Friend: Ok, completion doesn't complete .pdf's for acroread like you
> said it would.
> Me: Go spend hours tweaking your .zshrc.
> Friend: Gah! Why don't they just include this by default?
> Me: Beats me.
> Friend: Screw this, I'm going back to bash. It's available on most
> platforms anyway,
> why go through the pain of copying around my .zshrc?

Same in Bash (for example), no?

I hear what you’re trying to do, but a Z-shell isn’t a fish (wow, that
was a horrible pun),
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Travis Spencer]

On Mon, Jul 11, 2005 at 05:44:39PM +0200, Nikolai Weibull wrote:
> I hear what you're trying to do, but a Z-shell isn't a fish (wow,
> that was a horrible pun),

I am with Keir on this one.  A large minority of the sys admins at my
school use zsh.  In an effort to make converting easier they provide a
pretty usable default environment.  When I first logged in, I was
like, "What they heck!  This thing is totally broken.  Why is this
doing such and such?  Where is such and such?"  Once I figured out
what they where doing, I just added *one* new option to my .zshenv:

setopt NO_GLOBAL_RCS

Done deal.  Now new zsh-converts get a usable environment that they
can choose to customize or simply use as is, and I'm happy because
none of their stuff effects me.

-- 

Regards,

Travis Spencer

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Nikolai Weibull]

Travis Spencer wrote:

> On Mon, Jul 11, 2005 at 05:44:39PM +0200, Nikolai Weibull wrote:

> > I hear what you're trying to do, but a Z-shell isn't a fish (wow,
> > that was a horrible pun),

> I am with Keir on this one.  A large minority of the sys admins at my
> school use zsh.  In an effort to make converting easier they provide a
> pretty usable default environment.  When I first logged in, I was
> like, "What they heck!  This thing is totally broken.  Why is this
> doing such and such?  Where is such and such?"  Once I figured out
> what they where doing, I just added *one* new option to my .zshenv:
> 
> setopt NO_GLOBAL_RCS
> 
> Done deal.  Now new zsh-converts get a usable environment that they
> can choose to customize or simply use as is, and I'm happy because
> none of their stuff effects me.

I really don't understand what you're trying to say here.  Are you
saying that defaults are hard to get right, as the ones that were being
set messed up your environment and made Zsh work in a way that you
didn't expect it to, to the point that you had to use the word "heck"?
Why do you think that the defaults that are being set are going to make
life easier for Zsh-converts?

The global RCs shouldn't really be doing very much anyway, in my
opinion.  On my system they set ZDOTDIR and a default PATH, that's about
it.  I do agree that having completion set up properly by default would
make Zsh a lot more appealing at first glance, but completion can be
quite difficult to set up to a default that suits the largest number of
converters,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Keir Mierle]

On 7/11/05, Nikolai Weibull <mailing-lists.zsh-workers@rawuncut.elitemail.org>
[snip]
> Why do you think that the defaults that are being set are going to make
> life easier for Zsh-converts?

As I outlined earlier, such simple changes as putting bold text in the
prompt would
be immediatly useful. Most of my friends don't even customize their prompt,
requiring them to clear their screen between invocations of commands that output
lots of text. Why not Do The Right Thing? Why not make it work right
out of the box?

> The global RCs shouldn't really be doing very much anyway, in my
> opinion. 

I disagree. I think they should do whatever they can, so everyone else
doesn't have to.

> I do agree that having completion set up properly by default would
> make Zsh a lot more appealing at first glance, but completion can be
> quite difficult to set up to a default that suits the largest number of
> converters,

So it shouldn't be done? Do you think most new zsh converts-to-be (maybe) are
going to spend the time with the extremely complex and comprehensive
completion system to set it up? Only the most die-hard customizers will do this.

And yes, good defaults are 'hard.' That's life. Usability is hard.
There's no two ways
about it. But that doesn't mean it shouldn't be done or that it's not
worth doing.
Quite the contrary, I believe it is absolutely worth doing. With more
users comes
more developers, which few open source projects would complain about.

Thanks,
Keir

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Keir Mierle]

On 7/11/05, Nikolai Weibull
<mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:
> Keir Mierle wrote:
> 
> > On 7/10/05, Mike Hernandez <sequethin@gmail.com> wrote:
> 
> > > On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:
> 
> > > Though I'm not a developer, I can't help but reply to this.   I've
> > > used many linux distributions, and have built linux from scratch
> > > (linuxfromscratch.org). I've also used FreeBSD and OpenBSD, and OS
> > > X.  Each comes with it's own set of defaults (apart from LFS which
> > > has no default zsh config, due to it's being built directly from
> > > source).  Most programs leave any customization to the end user.  If
> > > you use zsh with any of the above mentioned OSes you'll find a
> > > slightly different set of defaults.
> 
> > So what? Did you stop to think for a second, that if the default zsh
> > config didn't suck, then the various distributions might use it?
> 
> How are any of the other shells' defaults any better?

They're not. They're just as awful. This all the more reason to do one better.
Do you think Google, when creating Google Maps, said 'Yahoo maps and
MapQuest can't pan without refreshing, why should we?' No, instead they said
'Hey, we can do something really useful the competition doesn't.'

> > > I would prefer, as an end user, that the developers focus their
> > > efforts on producing the best possible shell, and leave the
> > > customization to us.
> 
> > And as an end user, who on occasion tries to evangelize zsh, I would
> > prefer if developers spent a a small amount of time making zsh work
> > well, by default, most of the time, for most people.
> >
> > Me: Try zsh, it rocks.
> > Friend: Ok, I got zsh. This prompt sucks. How do I fix it?
> > Me: Go get a .zshrc from the net
> > Friend: Ok, completion doesn't complete .pdf's for acroread like you
> > said it would.
> > Me: Go spend hours tweaking your .zshrc.
> > Friend: Gah! Why don't they just include this by default?
> > Me: Beats me.
> > Friend: Screw this, I'm going back to bash. It's available on most
> > platforms anyway,
> > why go through the pain of copying around my .zshrc?
> 
> Same in Bash (for example), no?

Exactly. Bash is just as bad. Which is precisely why we should do one (or two)
better. Which is what we have to do to convince most people to
switch-- the barrier is higher for zsh because it is not installed on
most machines.

> I hear what you're trying to do, but a Z-shell isn't a fish (wow, that
> was a horrible pun),

I'm not suggesting zsh become fish. I am merely suggesting that zsh should not
suck, out of the box, by default.

Thanks,
Keir

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Nikolai Weibull]

Keir Mierle wrote:

> On 7/11/05, Nikolai Weibull
> <mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:

> > Keir Mierle wrote:

> > > On 7/10/05, Mike Hernandez <sequethin@gmail.com> wrote:

> > > > On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:

> > > > Though I'm not a developer, I can't help but reply to this.
> > > > I've used many linux distributions, and have built linux from
> > > > scratch (linuxfromscratch.org). I've also used FreeBSD and
> > > > OpenBSD, and OS X.  Each comes with it's own set of defaults
> > > > (apart from LFS which has no default zsh config, due to it's
> > > > being built directly from source).  Most programs leave any
> > > > customization to the end user.  If you use zsh with any of the
> > > > above mentioned OSes you'll find a slightly different set of
> > > > defaults.

> > > So what? Did you stop to think for a second, that if the default
> > > zsh config didn't suck, then the various distributions might use
> > > it?

> > How are any of the other shells' defaults any better?

> They're not. They're just as awful. This all the more reason to do one
> better.  Do you think Google, when creating Google Maps, said 'Yahoo
> maps and MapQuest can't pan without refreshing, why should we?' No,
> instead they said 'Hey, we can do something really useful the
> competition doesn't.'

Map applications on the Internet have been around 3-5 years, shells
40-45?  What I'm saying is that it seems hard to come up with good
defaults for shells.

> > > > I would prefer, as an end user, that the developers focus their
> > > > efforts on producing the best possible shell, and leave the
> > > > customization to us.

> > > And as an end user, who on occasion tries to evangelize zsh, I
> > > would prefer if developers spent a a small amount of time making
> > > zsh work well, by default, most of the time, for most people.
> > >
> > > Me: Try zsh, it rocks.
> > > Friend: Ok, I got zsh. This prompt sucks. How do I fix it?
> > > Me: Go get a .zshrc from the net
> > > Friend: Ok, completion doesn't complete .pdf's for acroread like
> > > you said it would.
> > > Me: Go spend hours tweaking your .zshrc.
> > > Friend: Gah! Why don't they just include this by default?
> > > Me: Beats me.
> > > Friend: Screw this, I'm going back to bash. It's available on most
> > > platforms anyway,
> > > why go through the pain of copying around my .zshrc?

> > Same in Bash (for example), no?

> Exactly. Bash is just as bad. Which is precisely why we should do one
> (or two) better. Which is what we have to do to convince most people
> to switch-- the barrier is higher for zsh because it is not installed
> on most machines.

Yes, but then "bad" defaults doesn't explain why people are using Bash
over Zsh.

> > I hear what you're trying to do, but a Z-shell isn't a fish (wow,
> > that was a horrible pun),

> I'm not suggesting zsh become fish. I am merely suggesting that zsh
> should not suck, out of the box, by default.

I agree, but we can't hope to do that over a night,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Keir Mierle]

On 7/11/05, Nikolai Weibull
<mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:
> Keir Mierle wrote:
> 
> > On 7/11/05, Nikolai Weibull
> > <mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:
> 
> > > Keir Mierle wrote:
> 
> > > > On 7/10/05, Mike Hernandez <sequethin@gmail.com> wrote:
> 
> > > > > On 7/10/05, Keir Mierle <mierle@gmail.com> wrote:
> 
> > > > > Though I'm not a developer, I can't help but reply to this.
> > > > > I've used many linux distributions, and have built linux from
> > > > > scratch (linuxfromscratch.org). I've also used FreeBSD and
> > > > > OpenBSD, and OS X.  Each comes with it's own set of defaults
> > > > > (apart from LFS which has no default zsh config, due to it's
> > > > > being built directly from source).  Most programs leave any
> > > > > customization to the end user.  If you use zsh with any of the
> > > > > above mentioned OSes you'll find a slightly different set of
> > > > > defaults.
> 
> > > > So what? Did you stop to think for a second, that if the default
> > > > zsh config didn't suck, then the various distributions might use
> > > > it?
> 
> > > How are any of the other shells' defaults any better?
> 
> > They're not. They're just as awful. This all the more reason to do one
> > better.  Do you think Google, when creating Google Maps, said 'Yahoo
> > maps and MapQuest can't pan without refreshing, why should we?' No,
> > instead they said 'Hey, we can do something really useful the
> > competition doesn't.'
> 
> Map applications on the Internet have been around 3-5 years, shells
> 40-45?  What I'm saying is that it seems hard to come up with good
> defaults for shells.

Doesn't mean we shouldn't try.

> > > > > I would prefer, as an end user, that the developers focus their
> > > > > efforts on producing the best possible shell, and leave the
> > > > > customization to us.
> 
> > > > And as an end user, who on occasion tries to evangelize zsh, I
> > > > would prefer if developers spent a a small amount of time making
> > > > zsh work well, by default, most of the time, for most people.
> > > >
> > > > Me: Try zsh, it rocks.
> > > > Friend: Ok, I got zsh. This prompt sucks. How do I fix it?
> > > > Me: Go get a .zshrc from the net
> > > > Friend: Ok, completion doesn't complete .pdf's for acroread like
> > > > you said it would.
> > > > Me: Go spend hours tweaking your .zshrc.
> > > > Friend: Gah! Why don't they just include this by default?
> > > > Me: Beats me.
> > > > Friend: Screw this, I'm going back to bash. It's available on most
> > > > platforms anyway,
> > > > why go through the pain of copying around my .zshrc?
> 
> > > Same in Bash (for example), no?
> 
> > Exactly. Bash is just as bad. Which is precisely why we should do one
> > (or two) better. Which is what we have to do to convince most people
> > to switch-- the barrier is higher for zsh because it is not installed
> > on most machines.
> 
> Yes, but then "bad" defaults doesn't explain why people are using Bash
> over Zsh.

Sure it does. Bash ships by default with most unix/linux installs.
That's enough momentum to stop most people from switching. Look at the
trouble Mozilla has had denting IE's marketshare with firefox; the
pre-installed advantage is enormous. Firefox is way better, by
default, and it's still having trouble!

> > > I hear what you're trying to do, but a Z-shell isn't a fish (wow,
> > > that was a horrible pun),
> 
> > I'm not suggesting zsh become fish. I am merely suggesting that zsh
> > should not suck, out of the box, by default.
> 
> I agree, but we can't hope to do that over a night,

Of course it won't happen over night. Which is why we should start
sooner, rather than later. I started a page with a bit more detail on
the ZSH wiki.

http://zshwiki.org/NiceZshDefaults

Thanks,
Keir

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Nikolai Weibull]

Keir Mierle wrote:

> On 7/11/05, Nikolai Weibull
> <mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:

> > Keir Mierle wrote:

> > > On 7/11/05, Nikolai Weibull
> > > <mailing-lists.zsh-workers@rawuncut.elitemail.org> wrote:

> > > > Keir Mierle wrote:

> > > > > So what? Did you stop to think for a second, that if the
> > > > > default zsh config didn't suck, then the various distributions
> > > > > might use it?

> > > > How are any of the other shells' defaults any better?

> > > They're not. They're just as awful. This all the more reason to do
> > > one better.  Do you think Google, when creating Google Maps, said
> > > 'Yahoo maps and MapQuest can't pan without refreshing, why should
> > > we?' No, instead they said 'Hey, we can do something really useful
> > > the competition doesn't.'

> > Map applications on the Internet have been around 3-5 years, shells
> > 40-45?  What I'm saying is that it seems hard to come up with good
> > defaults for shells.

> Doesn't mean we shouldn't try.

And that's not what I'm saying.

> > > Exactly. Bash is just as bad. Which is precisely why we should do
> > > one (or two) better. Which is what we have to do to convince most
> > > people to switch-- the barrier is higher for zsh because it is not
> > > installed on most machines.

> > Yes, but then "bad" defaults doesn't explain why people are using
> > Bash over Zsh.

> Sure it does. Bash ships by default with most unix/linux installs.
> That's enough momentum to stop most people from switching. Look at the
> trouble Mozilla has had denting IE's marketshare with firefox; the
> pre-installed advantage is enormous. Firefox is way better, by
> default, and it's still having trouble!

No it doesn't; it doesn't explain why Bash ships by default with most
unix/linux installs.  The reason for Bash being the default is that it
is GNU software and that it is closer, in a sense, to the old /bin/sh
than Zsh is.

Firefox has surely made a dent in internet explorers marketshare, but I
know what you're saying,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Peter Stephenson]

Keir Mierle wrote:
> Friend: Ok, completion doesn't complete .pdf's for acroread like you
> said it would.
> Me: Go spend hours tweaking your .zshrc.

  autoload -U compinit
  compinit

should do quite enough for new users to get started.  If this needs to
be more prominent in the documentation, suggest where.  Generally
speaking the shell manual is quite long and complex enough, but
restructuring, summarising and cross-referencing to improve clarity is
always possible.

Bart said most things, but I'm quite happy to consider innovative ideas
as to how we can arrange for a useful default configuration without
trashing the system's or the user's zsh initialisation scripts.  This
isn't an easy problem, and I don't think there's anyway of doing it
without at least some connivance from system administrators and package
maintainers.

I don't think there's any future at all in having shell code run by
default when the shell starts (which is what "sensible built-in
defaults" for completion would mean in practice).

One starting point might be zsh-system-install script along the lines
of compinstall to allow /etc/z* to be configured.  `make install'
could finish with the message `type "make system-install" to install
global defaults', or omething.  But someone has to write it.

- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Bart Schaefer]

On Jul 14,  1:03pm, Peter Stephenson wrote:
}
} Bart said most things, but I'm quite happy to consider innovative ideas
} as to how we can arrange for a useful default configuration without
} trashing the system's or the user's zsh initialisation scripts.  This
} isn't an easy problem, and I don't think there's anyway of doing it
} without at least some connivance from system administrators and package
} maintainers.

Here's something that occurred to me:

During startup, if none of the ${ZDOTDIR:-$HOME}/.z* files are found,
zsh looks for (but does not complain if it does not find) a "new user"
module, e.g. zsh/newuser, and loads it.

(Or the module could be loaded unconditionally, and the test for whether
the .z* files exist could be part of the module bootup.)

We could provide a default implementation of zsh/newuser that looks
for files in /usr/share/zsh/$VERSION (or the equivalent configure-
time path) and either simply reads them, or copies them to the .z*
locations.  Admins who don't want this could choose not to install
the module, or could provide their own rewrite.

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Peter Stephenson]

Bart Schaefer wrote:
> Here's something that occurred to me:
> 
> During startup, if none of the ${ZDOTDIR:-$HOME}/.z* files are found,
> zsh looks for (but does not complain if it does not find) a "new user"
> module, e.g. zsh/newuser, and loads it.
> 
> (Or the module could be loaded unconditionally, and the test for whether
> the .z* files exist could be part of the module bootup.)

The second alternative is more natural from the point of view of
modularity, although a little less efficient.  Presumably we could
safely attempt to unload the module immediately.

> We could provide a default implementation of zsh/newuser that looks
> for files in /usr/share/zsh/$VERSION (or the equivalent configure-
> time path) and either simply reads them, or copies them to the .z*
> locations.  Admins who don't want this could choose not to install
> the module, or could provide their own rewrite.

This is a neat idea.

One thing that occurs to me is that we need to make it easy for admins
to override the defaults.  Hence I think it should look in, say,
<install-path>/newuser/ and <install-path>/$VERSION/newuser/, probably
in that order since the latter will be installed by default, for
whatever files seem appropriate, where <install-path> is /usr/share/zsh
or whatever.  It's possible that version specific code might be
necessary, but the same problem turns up with all initialisation files,
so I don't think that need stop us allowing a global override.  (This
could then decide to look for version specific code, of course.)

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Bart Schaefer]

On Jul 14,  6:43pm, Peter Stephenson wrote:
}
} Bart Schaefer wrote:
} > Here's something that occurred to me:
} > 
} > During startup, if none of the ${ZDOTDIR:-$HOME}/.z* files are found,
} > zsh looks for (but does not complain if it does not find) a "new user"
} > module, e.g. zsh/newuser, and loads it.
} > 
} > (Or the module could be loaded unconditionally, and the test for whether
} > the .z* files exist could be part of the module bootup.)
} 
} The second alternative is more natural from the point of view of
} modularity, although a little less efficient.  Presumably we could
} safely attempt to unload the module immediately.

Agreed on both counts.

} > We could provide a default implementation of zsh/newuser that looks
} > for files in /usr/share/zsh/$VERSION

On further thought, probably the right thing is for the module to look
for a *single* file, and either simply source it, or autoload it and
then call a specified function that it is expected to define.  Anything
else we might want to do can then be programmed in shell language,
within that file or function.

(I think the test for existence of the .z* files should remain within
the C code, though.)

} One thing that occurs to me is that we need to make it easy for admins
} to override the defaults.  Hence I think it should look in, say,
} <install-path>/newuser/ and <install-path>/$VERSION/newuser/, probably
} in that order

This would be fine, though perhaps <install-path>/site-functions/ is a
better spot to look first if it were a single autoloadable file.  There
may be valid reasons to make this something that can be manually loaded/
called, as with compinstall.

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Oliver Kiddle]

Peter wrote:

> One thing that occurs to me is that we need to make it easy for admins
> to override the defaults.  Hence I think it should look in, say,

The problem with leaving it to admins to define the defaults is that the
defaults then vary. A module for installing skeleton startup files isn't
a bad idea but I think we should then distribute our recommended
skeletons. It is better when admins limit customisations to things that
are specific to the machine (environment variables like JAVA_HOME for
instance).

The other thing we might consider is changing the default set of options
that are enabled for interactive shells. autocd is a good candidate
because it is fairly harmless if you don't know about it. extended_glob
is perhaps less appropriate because it forces more special characters to
require quoting. This was done before in early 3.1.x versions if I'm not
mistaken.

And before we add any newuser module, what would we actually want to put
in the default skeleton configuration?

Oliver


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Peter Stephenson]

Oliver Kiddle wrote:
> Peter wrote:
> 
> > One thing that occurs to me is that we need to make it easy for admins
> > to override the defaults.  Hence I think it should look in, say,
> 
> The problem with leaving it to admins to define the defaults is that the
> defaults then vary. A module for installing skeleton startup files isn't
> a bad idea but I think we should then distribute our recommended
> skeletons.

That wasn't the issue: we should certainly distribute our own, otherwise
there's little point in the new module since an administrator can do
everything with the existing global startup files.  The point was that
our defaults would go in a version-specific location, but if an
administrator wanted to override it it's easier to use a fixed location,
so it should search there first.

> The other thing we might consider is changing the default set of options
> that are enabled for interactive shells. autocd is a good candidate
> because it is fairly harmless if you don't know about it. extended_glob
> is perhaps less appropriate because it forces more special characters to
> require quoting. This was done before in early 3.1.x versions if I'm not
> mistaken.
> 
> And before we add any newuser module, what would we actually want to put
> in the default skeleton configuration?

Things like autocd are suitable for this.  It should probably also turn
on completion.  It would be wrong to do very much; for example it
probably ought not to define aliases, certainly not replacements for
common commands which can be both infuriating and dangerous.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Dan Nelson]

In the last episode (Jul 10), Keir Mierle said:
> Ideas:
> 
>  * Add colors or at least boldface to the default prompt. The reasoning behind

Bodface is the only thing you'll ever get in a default, since you have
no way of even predicting whether a user will be using a black-on-white
xterm or a white-on-black console.  I like "(%n@%m) %B%/>%(#/#/)%b".

>  * Extremely controversial: make a 'extract' command that
>    intelligently handles all sorts of file formats. There is one
>    argument, that says it is not zsh's place to do this. There is
>    another, that says this is something zsh could do trivially, is
>    very common, exists in virtually everyone's .zshrc in one form or
>    another, and could be done once, properly, for the last time,
>    upstream.

I'm not sure how zsh could do this in a way that an external program
(bsdtar, for example) couldn't do just as well, also allowing non-zsh
users to use the same command if they wished.
 
>  * A good intro doc on using zsh interacitvely that goes over things
>    it does differently from other shells, such as good completion or
>    the above default aliases. The intro on the zsh website is ok, but
>    it could use some work.

Are you referring to http://zsh.sunsite.dk/Guide/ ?  It's probably just
waiting for someone to finish it.

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Nikolai Weibull]

Dan Nelson wrote:

> In the last episode (Jul 10), Keir Mierle said:

> > Ideas:
> > 
> >  * Add colors or at least boldface to the default prompt. The
> >  reasoning behind

> Bodface is the only thing you'll ever get in a default, since you have
> no way of even predicting whether a user will be using a black-on-white
> xterm or a white-on-black console.  I like "(%n@%m) %B%/>%(#/#/)%b".

No guarantee that the shell supports boldface either,
        nikolai

-- 
Nikolai Weibull: now available free of charge at http://bitwi.se/!
Born in Chicago, IL USA; currently residing in Gothenburg, Sweden.
main(){printf(&linux["\021%six\012\0"],(linux)["have"]+"fun"-97);}

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Dan Nelson]

In the last episode (Jul 11), Nikolai Weibull said:
> Dan Nelson wrote:
> > In the last episode (Jul 10), Keir Mierle said:
> > > Ideas:
> > > 
> > >  * Add colors or at least boldface to the default prompt. The
> > >  reasoning behind
> > Bodface is the only thing you'll ever get in a default, since you have
> > no way of even predicting whether a user will be using a black-on-white
> > xterm or a white-on-black console.  I like "(%n@%m) %B%/>%(#/#/)%b".
> 
> No guarantee that the shell supports boldface either,

%B and %b will simply expand to empty strings in that case, and no harm
done.

-- 
	Dan Nelson
	dnelson@allantgroup.com

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Travis Spencer]

On Sun, Jul 10, 2005 at 06:37:10PM -0400, Keir Mierle wrote:
> With one problem.
> 
> Defaults. Or lack thereof. 

If this goes forward and defaults are reworked, I vote for adding
`unsetopt PROMPTCR' so output of programs that forget the new line
character will still show their results as users seem to expect
judging from the numerous times that questions about this come up.

-- 

Regards,

Travis Spencer

Re: Good, easy to use, upstream defaults for zsh (i.e. improving usability)

[Stephen Rueger]

On Mon, Jul 11, 2005 at 08:23:06AM -0700, Travis Spencer wrote:

> If this goes forward and defaults are reworked, I vote for adding
> `unsetopt PROMPTCR' so output of programs that forget the new line
> character will still show their results as users seem to expect
> judging from the numerous times that questions about this come up.

Yeah, let's sacrifice features for the benefit of incompetent
programmers. Who needs multi-line editing?

And why stop there? Let's think about a few logical next steps.
How about getting rid of the distinction between stdout and stderr by
default, because sometimes "randomcommand --help | less" doesn't work?
Oh, and let's not forget about SH_WORD_SPLIT, that's should definitely
be on by default, it surprises too many people. And have you ever
noticed how intimidating the completion system is? I think something
less arcane like the one bash uses would allow a lot more people to
contribute.

-- 
Stephen Rüger
stephen.rueger@rechnerpost.org