monitoring the shell prompt

monitoring the shell prompt

[Paolo M. Pumilia]

I would like to monitor the command line editor status and perform
some action as a change happen.
Since i use to switch often between vi-cmd and vi-ins modes, it would 
be useful to get the current vi mode displayed within the prompt 
As an example:
In command mode:  PROMPT='(@%m) %n - %% '
In insert mode:   PROMPT='(@%m) %n + %% '

Is it possible with the current version of zsh?

Thank you for your suggestions


Paolo Pumilia
---- cstc -

Re: monitoring the shell prompt

[Bart Schaefer]

On Oct 2,  3:03pm, Paolo M. Pumilia wrote:
} Subject: monitoring the shell prompt
}
} Since i use to switch often between vi-cmd and vi-ins modes, it would 
} be useful to get the current vi mode displayed within the prompt 

Unfortunately the prompt is not recomputed while the editor is active, so
it can't be changed based on the editor state.  You can almost do it by
forcing the editor to be interrupted and restarted, but you may not like
it much.

Here's a sample, using $psvar and the %v escape to track the mode; widgets
require at least 3.1.6, of course, and maybe something later.  I've used
colon-commands instead of comments so you can cut'n'paste to zsh without
setopt interactive_comments.  Oh: Be sure that whatever you stuff into
psvar[1] in each function has the same number of characters as in all the
other functions, or redisplay may be messed up; similarly, try not to have
a prompt that changes width with the time of day and so on.  Put any of
that kind of stuff in RPROMPT.

# --- cut here ---
vi-ins-prompt () {
    psvar[1]=ins 
    zle .$WIDGET		;: For correct cursor placement etc.
    zle .push-input
    bindkey -A viins main
    zle .accept-line		;: The line is empty at this point
    echotc up			;: Draw the new prompt over the old
}
zle -N vi-ins-prompt
zle -A vi-ins-prompt vi-insert
zle -A vi-ins-prompt vi-insert-bol
zle -A vi-ins-prompt vi-add-next
zle -A vi-ins-prompt vi-add-eol
zle -A vi-ins-prompt vi-change
zle -A vi-ins-prompt vi-change-whole-line
zle -A vi-ins-prompt vi-substitute
: zle -A vi-ins-prompt vi-open-line-above	;: See remarks below
: zle -A vi-ins-prompt vi-open-line-below	;: See remarks below
: I may have missed some widgets that change to insert mode ...

bindkey -N cmdmap vicmd

vi-cmd-prompt () {
    psvar[1]=cmd 
    ((--CURSOR))
    zle .push-input
    bindkey -A cmdmap main
    zle .accept-line		;: The line is empty at this point
    echotc up			;: Draw the new prompt over the old
}
zle -N vi-cmd-prompt
zle -A vi-cmd-prompt vi-cmd-mode

vi-fix-prompt-and-call () {
    psvar[1]=ins
    zle .$WIDGET
}
zle -N vi-fix-prompt-and-call
zle -A vi-fix-prompt-and-call accept-line
zle -A vi-fix-prompt-and-call accept-and-hold
zle -A vi-fix-prompt-and-call accept-infer-next-history
zle -A vi-fix-prompt-and-call accept-line-and-down-history
: I may have missed some of these, too ... which-command, perhaps ...

PROMPT='(@%m) %n %v %% '
# --- cut here ---

I said "almost" for several reasons.  First, the "bindkey -A ..." stuff
is a nasty hack to force the editor to restart in command mode after the
send-break; send-break stops all zle processing (including the current
user-defined widget function) and returns to the prompt with the `main'
keymap active, and you can't "bindkey -A vicmd main" for safety reasons.

Second, if you're not at the PS1 prompt (e.g. you're editing a function
or a control construct like an "if"), executing a send-break will not
have the desired effect.  You'll end up back at a PS1 prompt in command
mode, but the contents of the editor buffer (while not lost) will not
have been yanked back.

Third, and for similar reasons, vi-open-line-{above,below} are sometimes
going to behave strangely.  That's why they're commented out right now,
but you can experiment to see if it's not too confusing for you.

Fourth, I'm not entirely confident that messing with zle's head by moving
the cursor with echotc isn't going to get you into trouble sometimes.

Finally, if the editor ever restarts itself because of an error, the prompt
may not reflect the correct mode.  I think that's pretty unlikely, but I
haven't exhaustively tested this ...

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: monitoring the shell prompt

[Bart Schaefer]

On Oct 2,  5:33pm, Bart Schaefer wrote:
} Subject: Re: monitoring the shell prompt
}
} is a nasty hack to force the editor to restart in command mode after the
} send-break; send-break stops all zle processing

Ahem.  To explain about that: I was at first using send-break instead of
accept-line, which beeped horribly, and forgot to edit the description
after I realized that accept-line would also work and work silently.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com