Re: Implementation of simple newuser module (how to start?)

[Peter Stephenson <pws@xxxxxxx>]

Keir Mierle wrote:
> It appears there is some consesus on how we can start making zsh more
> usable. The idea of a 'newuser' module is great; there's tons of
> things we could put in to make it easy for new user while not
> frustrating zsh veterans.

We have to finalise what paths to search and what files to look for.
Bart suggested checking for autoloadable functions.  It's a bit fraught
checking for this in the normal fpath or even in site-functions,
however, unless we use a name that we can be reasonably sure won't
already exist.

I still quite like the idea of simply sourcing, say, the first of
<zsh-files-prefix>/$VERSION/newuser or <zsh-files-prefix>/newuser that
appears.  This can always define or autoload a function and then run
it.  The file also stands out---it's easy to see if you're system's set
up to support the feature, and remove it if you don't want it, and it's
easy to see if there's a file overriding the version-specific one.
The default version could then contain "autoload -U zsh-new-user-setup;
zsh-new-user-setup", for example, and the function could be in, say
Functions/Newuser and installed as part of the newuser module.  (We
would have to add something to the .mdd file to install the newuser file
itself.)

Another question is if zsh/newuser should be loaded before or after
/etc/zshenv (it can't be any later than just after that).

Presumably the code for zsh/newuser will be fairly small, so there's
some reason for it being linked in by default when it's in use (this
doesn't stop it being formally "unloaded" even though it's still
present in virtual memory).  That's easy to configure, however, and we
can mention it in the release notes, so I don't think we need to alter
it in the distribution.

> I know absolutely nothing about the zsh codebase, so I've started
> poking around. Now, in the interest in maximizing the amount of work I
> get done while minimizing the amount of time I spend (because I don't
> have much time to spend on open source stuff), could the list give me
> a brief synopsis of what files I should be looking at, and what files
> I should create?

There's an argument that only .zshrc needs creating.  It varies from
person to person how much people want transferring in .zshenv.  I set
options like extended_glob there so the environment is sane when I run,
say, grep from inside Emacs.  However, some people like a fairly clean
.zshenv.  It's usually OK to set variables there.

Probably just .zshrc would do for now.

> To start, I was thinking of just creating a zsh script to walk the
> user through setting up their prompt, turning on completion, and
> telling them about autocd and a couple other options.

That's probably a good idea, although it needs an easy way to abort and
ensure it's never run again ("touch ${ZDOTDIR:-$HOME}/.zshrc" will do)
and perhaps also to defer running it until the next time (simply
aborting will do).  Also, there are some advantages in having a function
rather than a script, as suggested it above (it can "unfunction" itself
at the end to remove it from memory).  Have you looked at
Completion/compinstall?  It serves as a model for one way of doing this.

-- 
Peter Stephenson <pws@xxxxxxx>                  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.

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