Re: idea for new feature (was: Re: sticky-note and zle bindings)

[Andy Spiegl <zsh.Andy@spiegl.de>]

On 2008-01-16, 19:11, Bart Schaefer wrote:
> Of course this is what share_history and inc_append_history are in
> part intended to accomplish.
Only for the command history, though.
I was thinking about the directory stack.

> The problem is that zsh can't do it by iself.  So, your X server has
> crashed and 20 shell windows went kablooie.  Even if every zsh has
> faithfully been recording its state somewhere, how does each new
> xterm you launch on the retarted X desktop know which one of the 20
> saved states it should restore?
You're right - that's too complex and depends heavily on the user environment.
But zsh could start the cooperation by providing the saved data and some kind
of mechanism of reading it back in to restore the directory stack.

Having that, it will be up to the users/terminal-guys/xserver-guys to use
that data.  When they know that zsh provides this they might be interested
in using it.

> The upshot is that this isn't a zsh feature -- it's a cooperative
> feature that requires effort from both the shell and whatever other
> user interface environment it's running inside.
Right, so let's start. :-)

> It's pretty simple to dump state somewhere from the precmd() function
In a separate file for each zsh instance?  Using the PID?  Or a counter?
Or maybe some unique identifier for each instance, say shell1, shell2, ...
That way zsh could check at startup whether there is a state-file for
its name and read it back in.  The unique name should probably be in
an environment variable.  Hm, then in .xsession you would start several
xterms with shells like that:
 ZSHNAME="shell-1" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-1"
 ZSHNAME="shell-2" /usr/bin/xterm -geometry 90x45+89+212 -T "Shell-2"

How about that?

Bye,
 Andy.

-- 
 To err is human. To really screw it up takes a computer.