ideas, questions, and bugs (?)

[Quinn Dunkan <quinn@xxxxxxxxxxxxxxxxxxxxx>]

Well, I'm new to this list, and here I go posting a big huge long suggestion
list.  I looked through the archives and didn't find other people mentioning
any of these things, though.  It could very well be many of these suggestions
require applying existing features in ways I haven't thought of.
So, I ask your patience in reading this, it's kinda long.

according to the zshmisc man page, a sublist is `one or more pipelines seperated
by && or ||'.  Then it says a list consists of one or more sublists optionally
terminated with ;, &, &|, &!, or \n.  So it should be possible to do:
command1 && command2 &
and have the whole conditional execute in the background.  Unfortunately, zsh
runs command1 in the foreground, and if command1 returns 0, runs command2 in
the background.  Bash handles this command properly, btw.  Even csh does this
right, for goodness sake.  Ok, so
(cmd1 && cmd2) &
works, but according to the man page I shouldn't have to do that.

I had a few problems compiling zsh 3.1.2.  Of course, it is an alpha release,
so I didn't expect a pain-free installation, but my difficulties seemed
unusually great.  I wound up changing the configure script (dlopen is in -ldl
on my linux system), and altering zshxmods.h and bltinmods.list to get a
modular binary.  I probably should have just altered the .conf files, but
the comments seemed to indicate they were already right, and my changes didn't
have any effect anyway.

When chaselinks is off, there is a problem that the shell's idea of .. is
different from another program's idea.  So if you do 'cd symlink', zsh's pwd
(and the %~ PS1 escape sequence) reports you as being in /old/path/symlink.
However, you are _really_ in /path/symlink/points/to.  So if you do 'ls
../foo', zsh looks for /path/symlink/points/foo.  If you do 'cd ..; ls foo',
zsh looks for /old/path/foo.  What I would like is an option that makes it so
that when chaselinks is off, zsh acts as if you really are in the fake zsh
path, so it would 'expand' /old/path/symlink/../foo to /old/path/foo.  Since
programs being run have no idea if chaselinks is on or not, zsh would have to
do this expansion itself.  It seems it wouldn't be hard to just have every '..'
in the path cancel out its parent.

Here's a random idea:  it would be interesting to generalize the $PATH facility
so one could set up user defined path vars, and use a compctl-like command to
assign them to commands and parts of commands.  So, for example, you could do 

GFXPATH=".:$HOME/gfx/jpg:$HOME/gfx/ppm"
assignpath GFXPATH /usr/local/bin/pbm/*(:t) djpeg cjpeg

Then, if you type 'djpeg foo.jpg >foo.ppm', zsh will search through $GFXPATH
for foo.jpg.  Of course, we'd use a zsh-style $gfxpath array.  I'm not sure
how useful this would actually be.

A nitpick:  in the COMMAND EXECUTION section of zshmisc, it would be nice to
mention the pathdirs option, I read that and assumed zsh couldn't do rc style
path searching, then found pathdirs in zshoptions later.

A $LASTPID or something parameter, which is the pid of the last command run.
Yes, I know about $!, but that only works if the process is &ed and not at all
if it forks like a daemon (or maybe daemons pitchfork() ?).  Many daemons don't
make nice .pid files, and it can be hard to figure out what you just started if
there are many by the same name (the only thing I can figure out is to stat
/proc/pids_of_a_certain_name for one with a timestamp that matches with one
when I started the daemon (if you have a procfs), but that's not ideal).

As much as I try, I can't figure out a good way to have zsh execute some
command at startup and stay in interactive mode.  What I mean is, I would
like a command-line switch like -c but for interactive shells.
E.g. one could set up special zsh sessions with 
% zsh -fr '. $HOME/.special.zshrc'
where
% zsh -c foo
is equivalent to
% zsh -r 'exec foo'
I thought +t might do something like this, unfortunately even with -s it
doesn't seem to consider a pipe `standard input', so
% echo '. $HOME/.special.zshrc' | zsh -s +t
is a no go.

well, I had a description of zsh's autorepeat freezing like Paul Janzen
mentioned a while ago, and then found some comments about $BAUD, setting it to
0 fixed the problem.

if zsh gets a parsing error in an rc file, you get something like:
zsh: unmatched ' [97]
with no indication of what rc file bombed.  Would it be possible to include
the name of the file it came from (how it works for .), so you get
~me/.zshrc: unmatched ' [97] ?

instead of just beeping when the user attempts to scroll the history past the
current line, zsh should just predict the user's next command, so you could
have a forward 'history' as well.  Of course, you could also use this for
command line completion: just hit <tab><enter> to complete your next command
and execute it, if you don't feel like typing the whole thing in.  The
prediction algorithm would be simple: just have the user scan in his brain and
run an emulation in a sub process.  Use dup() to copy all the user's input and
pipe it to the simulation, it ought to think the same thing he's thinking of.
This might not work for non-determinists, though.  Another approch for those
too cheap to buy a brain-scanner (or for ancient unices without /dev/brain
support) would be to construct a markov chain.  It would take a little while to
get reasonably accurate, but after a month or so of learning it might work
ok.

oh, and to Jose Unpingco who mentioned dvorak, it's much easier to change the
keymap at the terminal driver level, instead of individual apps.  various
unices have different methods of changing keymaps at the console, but xmodmap
always works for X, of course.  I use dvorak exclusively, especially in vi, I
have no problems.  In fact, I find vi keys (especially hjkl) awkward under
qwerty (having right-left on one hand and up-down on the other keeps me
un-confused).  'zshrc' is tons of fun to type in dvorak, but not as much fun as
'fvwmrc'

To add some more confusion to the rc file thread, I don't quite understand the
reasons for zprofile/zlogin.  Ok, so you could use zlogin to override commands
in zshrc for login shells... but is this really useful?  I can't think of any
situation that would require this (how many people have non-interactive login
shells?), but it's obviously there for a reason, so maybe someone can help me
out here.  Also, is it better to stick vars in zlogin and export them so future
shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in
zshenv?  I tend to go for the zshenv route, since I don't want different
behaviour from scripts run from cron, for instance, but is this a bad idea?  In
fact, my zlogin is empty, everything that non-interactive zshs may want is in
zshenv, everything else in zshrc.  Is it better to let progs inherit their
enviroments rather than rescan a large /etc/zshenv every time?  The only thing
I can think of to put in zlogin is things like `fortune'.

I kept wondering where these run-help and which-command aliases were coming
from...  took a look in hashtable.c and found out that they're hard coded!  I
don't think they should be (since if you make a run-help function it will
mysteriously not work right until you unalias run-help, despite the fact that
you never set it in the first place), but in any case, it would be nice if the
man pages were a little more explicit about that (they're defined even when
zle is unloaded!), and any other surprises that may be lurking in the name
space.

My zsh 3.1.2 segfaults when it can't find PATH.  This seems like a bug.
% unset PATH;/bin/zsh-3.1.2 # always segfaults on my system.
% unset PATH;/bin/zsh       # works fine


In zsh 3.0.0, PATH always reflecs path, and vice-versa.  In zsh 3.1.2, PATH
reflects path only if PATH is set.  That means that given:

% unset PATH
% path=(/bin /usr/bin)

zsh 3.0.0 % echo $PATH
/bin:/usr/bin

zsh 3.1.2 % echo $PATH
(nothing)

However, given:

% unset PATH
% PATH=
% path=(/bin /usr/bin)
% export PATH

Both 3.0.0 and 3.1.2 work correctly.  So for now I have PATH= in my zshenv as
a workaround.

Oh, and does anyone know a way to reprint the prompt?  I want to make a widget:

function vi-cmd-mode-boldps { PS1='%B%#%b '; zle redraw-line; zle vi-cmd-mode }

and according ones for a, A, i, I, etc. that unbold the prompt, the idea being
that I can have a nice reminder of what keymap I'm in.  I tested this with
zle clear-screen instead of the (nonexistent) redraw-line, and the prompt
came back mangled (spaces and high chars), but if I hit enter it's like it
should be.  Also, there's a little pause whenever I invoke the widget, which
would make it unusable (too annoying), even if clear-screen didn't already.
So what am I doing wrong?