Re: PATCH: Add $ZLE_STATE in zle widgets

[Frank Terbeck <ft@xxxxxxxxxxxxxxxxxxx>]

Frank Terbeck wrote:
> This is the $OVERWRITE idea converted to a string $ZLE_STATE, that may
> contain more than one attribute. Currently it only handles the status of
> the overwrite bit (!insmode).
> ---
>  Doc/Zsh/zle.yo       |    7 +++++++
>  Src/Zle/zle_params.c |   22 ++++++++++++++++++++++
>  2 files changed, 29 insertions(+), 0 deletions(-)

So, about this.

I was thinking about adding support for signaling whether or not a
minibuffer is currently active. Turns out, that's not so easy. And even
if I had the information I'd still need some sort of hook-widget to be
called (like `zle-keymap-select()') to solve my particular problem.

Then I was thinking about adding a few more status strings, like
`isearch', `search' `execnacmedcmd' and `statusline' to be able to
figure out in shell code, if a minibuffer is active (the idea is to see
if isearch and a statusline are active, to conclude, that a minibuffer
is active). While that's easier, it still requires some widget to me
called automatically at the right times. And that's not the case.

So, I started to write a number of wrapper widgets that keep track of
zle's state entirely in shell code. That works surprisingly well. I
could even call "zle reset-prompt" from a TRAPINT(), which seems to
work. It just prints the following message to stderr:

      zle_thingy.c:649: line metafied

I'm ignoring that for now (2> /dev/null), since the widget does its
work.

What *is* the problem I'm trying to solve? Well, I'm trying to keep
track of what keyboard mode is currently active. I am keeping the
information in psvar[1], which I then use in my $PS1. The possible
values currently are:

       "i"  - insert mode
       "c"  - command mode
       "im" - insert mode, with a minibuffer being active
       "cm" - ditto, but for command mode
       "r"  - replace mode: insert mode with the overwrite bit set.

This works pretty well for all widgets I'm using, except for
`execute-named-command', because I cannot seem to create a wrapper
widget for that. I found this about the problem:

       http://www.zsh.org/mla/workers/2005/msg00384.html
       http://www.zsh.org/mla/workers/2005/msg00390.html

...so, I'm now settling to wait until 2012 about that. :-)

I'm pretty happy with my current setup anyway. It would be cool to have
a way to add a "V" mode to my prompt when `vared' is active. That could
probably be done with {pre,post}-vared hook widgets. I didn't look into
that yet, though.  (Actually, since I wrote this mail while being on a
train, I did look at this by now. This is not as trivial as I had hoped,
since zle cannot be run recursively. Oh well, I'm rarely using `vared'
anyway.)


Now, back to the patch at hand. Personally, I don't really need it
anymore. Since in vi-mode, I'm switching from one keyboard mode to
another directly, it's pretty hard for my code to get confused.

Still, when overwrite/non-overwrite mode is changed by toggling, like in
emacs mode, screwing up once, permanently confuses the state. And that's
as easy as "M-x .overwrite-mode RET".

So it might be worth committing this patch after all, since if
$ZLE_STATE contains "overwrite", you can be sure that's the state you're
in.

I'm not sure if the code is okay, though. I think using `dupstring()'
and `dyncat()' is correct, since the zle-widget is wrapped in
`pushheap()' and `popheap()'. That shouldn't leak, if I'm reading the
code correctly.  I am also not sure if that description of the new
variable in zshzle(1) is clear enough.

To cut a long story short: I'd like someone more competent to comment on
whether it's okay to commit this or not. :)

Regards, Frank