Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Jason Spiro]

On Wed, Dec 17, 2014 at 2:58 AM, Nathan Schwarz <nathan@notwhite.ro> wrote:

> This is already possible.

I know that it's already possible.  The feature request was not asking
you to make mode indication _possible_:  it was asking you to make it
please happen _by default_.  :)

You don't have to make it happen using a cursor change.  You can
choose whatever method you like.  May I suggest that you do things the
same way Bash's 'show-mode-in-prompt' feature does things:  add a
colon to the beginning of the prompt in vicmd mode; add a plus sign in
viins mode.

> For the blinking-cursor-stuff you can use this:
> [...]

Good to know; thank you.

> Ps: Sorry for double-sending Jason, I replied to you instead of replying to the ml.

No worries.

On Wed, Dec 17, 2014 at 1:27 PM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:

> However, you will need to ensure that the cursor is always reset when a
> line is accepted. Most reliable place to do that appears to be POSTEDIT:
>   POSTEDIT+=$'\e[2 q'

Thank you Oliver.

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 21,  7:07pm, Jason Spiro wrote:
}
} I know that it's already possible.  The feature request was not asking
} you to make mode indication _possible_:  it was asking you to make it
} please happen _by default_.  :)

And my point was that *even vim* doesn't make it happen *by default*.
You have to configure it, and it functions in a terminal-specific
manner.  Attempting to build it in to the shell is just going to
result in frustration when it only works a fraction of the time.

Re: In Vi mode, show whether "insert" or "command" state is active

[Peter Stephenson]

On Sun, 21 Dec 2014 17:57:23 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Dec 21,  7:07pm, Jason Spiro wrote:
> }
> } I know that it's already possible.  The feature request was not
> asking } you to make mode indication _possible_:  it was asking you
> to make it } please happen _by default_.  :)
> 
> And my point was that *even vim* doesn't make it happen *by default*.
> You have to configure it, and it functions in a terminal-specific
> manner.  Attempting to build it in to the shell is just going to
> result in frustration when it only works a fraction of the time.

It can't be beyond the wit of person to make it easy to turn on when it
does work, and it should be possible internally to make it much more
convenient to use the terminal handling mechanisms than is possible in a
function.

pws

Re: In Vi mode, show whether "insert" or "command" state is active

[Ray Andrews]

On 12/22/2014 10:25 AM, Peter Stephenson wrote:
> It can't be beyond the wit of person to make it easy to turn on when 
> it does work, and it should be possible internally to make it much 
> more convenient to use the terminal handling mechanisms than is 
> possible in a function. pws 

Right.  Should the shell even attempt to do something that it can't do 
reliably, or that is not naturally it's business?

Re: In Vi mode, show whether "insert" or "command" state is active

[ZyX]

22.12.2014, 04:58, "Bart Schaefer" <schaefer@brasslantern.com>:
> On Dec 21,  7:07pm, Jason Spiro wrote:
> }
> } I know that it's already possible.  The feature request was not asking
> } you to make mode indication _possible_:  it was asking you to make it
> } please happen _by default_.  :)
>
> And my point was that *even vim* doesn't make it happen *by default*.
> You have to configure it, and it functions in a terminal-specific
> manner.  Attempting to build it in to the shell is just going to
> result in frustration when it only works a fraction of the time.

Vim does this if you happen to launch it with an empty ~/.vimrc, -N argument or whatever other method you can use to turn off Vi compatibility. Bram recognizes that this behaviour is rather frustrating, but due to backwards compatibility cannot use new behaviour by default, so it is only on by default when nocompatible is set. I think it may be adding as a question issued by zsh-newuser-install when user selects Vi keymap, but behaviour when `zsh -f` is run or when .zshrc exists because I am pretty sure that in the first case some tests rely on it and in the second case chances that user has already configured what he needs is higher then chances that he has failed to find the solution.

And this should be changed prompt/rprompt, not changing cursor because changing cursor shape is less likely to work. If zsh-newuser-install will ask for creating prompts changing depending on the mode then this should be done with a zsh script, not coded with C. The following shold work:

1. Add `[$ZLE_KEYMAP]` string to prompt:

	setopt promptsubst
	PS1='%m[$ZLE_KEYMAP]%# '

2. Define the helper functions:

	_set_true_keymap_name() {
		typeset -g ZLE_KEYMAP="${1:-main}"
		local plm_bk="$(bindkey -lL ${ZLE_KEYMAP})"
		if [[ $plm_bk = 'bindkey -A'* ]] ; then
			_set_true_keymap_name ${(Q)${${(z)plm_bk}[3]}}
		fi
	}

	_zle_keymap_select() {
		_set_true_keymap_name $KEYMAP
		zle reset-prompt
	}

3. Define conditions under which they are called:

	precmd_functions+=( _set_true_keymap_name )
	zle -N zle-keymap-select  _zle_keymap_select

Re: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 22,  9:44pm, ZyX wrote:
}
} [...]  I think it may be adding as a question issued by
} zsh-newuser-install when user selects Vi keymap, but behaviour when
} `zsh -f` is run or when .zshrc exists because I am pretty sure that in
} the first case some tests rely on it and in the second case chances
} that user has already configured what he needs is higher then chances
} that he has failed to find the solution.
} 
} And this should be changed prompt/rprompt, not changing cursor because
} changing cursor shape is less likely to work.

Then perhaps there should be a prompt escape for the keymap?  The letters
'z' and 'Z' are not yet taken.  (I hate requiring PROMPT_SUBST.)

Minimally:

diff --git a/Src/prompt.c b/Src/prompt.c
index 3552575..ef27699 100644
--- a/Src/prompt.c
+++ b/Src/prompt.c
@@ -404,6 +404,10 @@ putpromptchar(int doprint, int endchar, unsigned int *txtchangep)
 			    test = 1;
 		    }
 		    break;
+		case 'z':
+		    if ((ss = getsparam("KEYMAP")))
+			test = !!strcmp(ss, "main");
+		    break;
 		case '_':
 		    test = (cmdsp >= arg);
 		    break;
@@ -854,6 +858,14 @@ putpromptchar(int doprint, int endchar, unsigned int *txtchangep)
 		    promptpath(scriptfilename ? scriptfilename : argzero,
 			       arg, 0);
 		break;
+	    case 'z':
+		if ((ss = getsparam("KEYMAP")))
+		    stradd(ss);
+		break;
+	    case 'Z':
+		if ((ss = getsparam("ZLE_STATE")))
+		    stradd(ss);
+		break;
 	    case '\0':
 		return 0;
 	    case Meta:


This still requires one to write

zle-keymap-select() { zle reset-prompt }
zle -N zle-keymap-select

because the ZLE parameter set is only installed for user-defined widgets.

There's probably something more clever that could be done, particualarly
with ZLE_STATE and with the conditional.  The above is just an example.

Incidentally you have to "fix" the keymap name etc. in zle-line-init as
well as in zle-keymap-select.  Maybe zle-keymap-select should be called
just before (after?) zle-line-init, since the keymap is initialized at
that time.

Re: In Vi mode, show whether "insert" or "command" state is active

[Jason Spiro]

On Mon, Dec 22, 2014 at 1:44 PM, ZyX <kp-pav@yandex.ru> wrote:
> And this should be changed prompt/rprompt, not changing
> cursor because changing cursor shape is less likely to work

OK.  You could do things the same way Bash's brand-new
'show-mode-in-prompt' feature does things:  you could add one extra
character to the beginning of the prompt.  A colon in vicmd mode; a
plus sign in viins mode.

This should work reliably in every terminal emulator.

Re: In Vi mode, show whether "insert" or "command" state is active

[ZyX]

25.12.2014, 07:16, "Jason Spiro" <jasonspiro4@gmail.com>:
> On Mon, Dec 22, 2014 at 1:44 PM, ZyX <kp-pav@yandex.ru> wrote:
>>  And this should be changed prompt/rprompt, not changing
>>  cursor because changing cursor shape is less likely to work
>
> OK.  You could do things the same way Bash's brand-new
> 'show-mode-in-prompt' feature does things:  you could add one extra
> character to the beginning of the prompt.  A colon in vicmd mode; a
> plus sign in viins mode.
>
> This should work reliably in every terminal emulator.

I have read that this is readline 6.3 feature that has nothing to do with bash except that bash is using readline. Also [vicmd]/[viins] variant is clearer then colon and plus and also in case of %z one should not assume only vicmd/viins: zle is not as limited as readline and theoretically allows any number of modes (have never seen them actually implemented though).

---

Also regarding %z minimal implementation: in my example code $KEYMAP is checked for being an alias to something. Most likely your variant will make %z disappear in `viins` mode (as it is linked to main and if I am not mistaking exiting vicmd will bring up the main keymap) and in my variant it definitely (I have tested this with `zsh -f`) will show either `vicmd` or `viins` effectively avoiding changing prompt width which may be confusing.

Re: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 25, 11:34pm, ZyX wrote:
}
} Also regarding %z minimal implementation: in my example code $KEYMAP
} is checked for being an alias to something.

Yes, I was only providing an example / starting point.  For this to work
better we'd need another zleentry token or the like, to be able to query
the keymap and state without requiring getsparam() calls and without the
extra prompt redraw from inside zle-line-init.  Also keymap selection
and possibly other state changes should always redraw the prompt (as an
example, there currently is no hook when entering overwrite mode).

Re: In Vi mode, show whether "insert" or "command" state is active

[Oliver Kiddle]

Bart wrote:
> Yes, I was only providing an example / starting point.  For this to work
> better we'd need another zleentry token or the like, to be able to query
> the keymap and state without requiring getsparam() calls and without the
> extra prompt redraw from inside zle-line-init.  Also keymap selection
> and possibly other state changes should always redraw the prompt (as an
> example, there currently is no hook when entering overwrite mode).

Do we really want the whole prompt redrawn? It's annoying if conditional
parts of the prompt evaluate differently causing it to change size.

With my current setup, I have a number of things setup to preserve this
state. So for example. with the return status I also need zle-line-init
to contain:
  typeset -g __prompt_status="$?"
And zle-keymap-select has:
  () {
    return $__prompt_status
  }
  zle reset-prompt

Would a feature be somehow possible where a fixed set of characters are
marked for dynamic updating and made easy to update.

I'm not sure the keymap name is the most useful indicator for the vi
mode. local keymaps are not going to be indicated and keymaps like
menuselect have a longer name. Subtler indicators like cursor
shape/colour or something like the readline feature are perhaps more
useful. In vim, I would never read the '-- INSERT --' indicator: it is
a blob that appears in peripheral vision.

I should mention that I'm all for making this simpler to configure.

Oliver

Re: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 26, 12:32pm, Oliver Kiddle wrote:
}
} Do we really want the whole prompt redrawn? It's annoying if conditional
} parts of the prompt evaluate differently causing it to change size.
} 
} Would a feature be somehow possible where a fixed set of characters are
} marked for dynamic updating and made easy to update.

This would probably have to be handled like RPROMPT, that is, a separate
expansion.  Without doing a lot more screen management/mapping than we
already do, it's not practical to mark a range of PS1 and update only
that ... but if there were a separate "mode prompt" then it could be up
to the user to manage it properly.

(In fact this could probably be hacked by using RPS1 with some %{...%}
sections.)

The question would be where to put the "mode prompt" by default, whether
to allow it to be covered up by multi-line input or completion listings,
etc.

} I'm not sure the keymap name is the most useful indicator for the vi
} mode. local keymaps are not going to be indicated and keymaps like
} menuselect have a longer name.

I think local keymaps would in fact show up if the value were recomputed
upon zle-keymap-select.

My vague idea was to have the value of N in %N(z..) refer to something
about the keymap (where the example I gave is that %0(z) is true if the
"main" keymap is selected and false otherwise).  Assign 1 to the emacs
keymap, 2 to viins, 3 to vicmd, etc.; %0(z) and %2(z) might both be true
when main is an alias for viins.  Obviously this is not perfect, but I
haven't come up with a less grotesque alternative.

In any case you could then program your prompt to always use a fixed
width string for the mode.  The other issue of course is that the mode
is not entirely distinguished by the keymap name; you might also want
to know whether you are in overwrite mode, etc.

} Subtler indicators like cursor shape/colour or something like the
} readline feature are perhaps more useful.

If you have a test like %2(z) then you can program the prompt to change
the color or cursor or whatever instead of inserting the keymap name.

Perhaps having an additional "mode prompt" (PS5 ?) that is output when
something significant (keymap, overwrite, what else?) changes is enough,
leaving it up to the user to include necessary motion escapes if the
string is not simply a color or cursor-shape change.  There is still
the flexibility to fiddle around with zle-keymap-select instead if more
complexity is desired.

Re: In Vi mode, show whether "insert" or "command" state is active

[Christian Neukirchen]

Bart Schaefer <schaefer@brasslantern.com> writes:

> My vague idea was to have the value of N in %N(z..) refer to something
> about the keymap (where the example I gave is that %0(z) is true if the
> "main" keymap is selected and false otherwise).  Assign 1 to the emacs
> keymap, 2 to viins, 3 to vicmd, etc.; %0(z) and %2(z) might both be true
> when main is an alias for viins.  Obviously this is not perfect, but I
> haven't come up with a less grotesque alternative.

Perhaps %(z.viins.I.)%(z.main.N.)?

i.e. z.MODE.PRINT_IF_MODE.PRINT_ELSE.

-- 
Christian Neukirchen  <chneukirchen@gmail.com>  http://chneukirchen.org

Re: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 26, 10:58pm, Christian Neukirchen wrote:
}
} Perhaps %(z.viins.I.)%(z.main.N.)?
} 
} i.e. z.MODE.PRINT_IF_MODE.PRINT_ELSE.

That might work (except drop the trailing "."), but it's inconsistent as
compared to the other ternary constructions.  That is, parsing can't tell
without infinite lookahead whether you have %(z.MODE.true.false) or just
%(z.true.false).  Of course we could just disallow the latter in the
case of the 'z' token, but that's still a little icky.

If we did this, it should probably be a pattern match or a prefix match
so one could do %(z.vi*.notemacs.emacs) or %(z.menu*.this.that).

-- 
Barton E. Schaefer

Fwd: In Vi mode, show whether "insert" or "command" state is active

[Jason Spiro]

Dear list,

Here is a feature request forwarded to you from the Debian bug
tracking system.  You may also view the feature request on the Web at
<http://bugs.debian.org/772985>.

Kind regards,
~Jason Spiro

---------- Forwarded message ----------
From: Debian Bug Tracking System <http://bugs.debian.org/772985>
Date: Fri, Dec 12, 2014
Subject: Bug#772985: In Vi mode, show whether "insert" or "command"
state is active

Package: zsh
Version: 4.3.17-1
Severity: wishlist

Zsh includes a Vi emulation feature.  This feature lets you use the Vi
keys at the zsh command prompt.  Zsh's Vi emulation includes a
"command mode" and an "insert mode".

Zsh's Vi emulation does not show the user which mode is active.  This
is frustrating and confusing.  (It's like an electric oven with no
indicator to show whether the oven is on or off.)

The current state-of-the-art Vi implementation is gVim, maintained by
Bram Moolenaar.  gVim provides a few indicators to tell you which mode
you're in.  One of these indicators is the cursor.  gVim uses a
blinking block cursor in command mode, and a blinking bar in insert
mode.

It would be very good if zsh, too, would show the user which mode was
active.  You can do this any way you like.  I would like it if you did
this by setting the cursor style, just as gVim does.

Here is how to set the cursor style (in supported terminals):

Set cursor to blinking bar:  echo -en "\e[5 q"
Set cursor to blinking block:  echo -en "\e[1 q"

The above commands definitely work in recent versions of iTerm2 (for
Mac OS) and xterm.  I haven't tested them in any other terminal
emulators.  Surely some terminal emulators do nothing at all in
response to the above control sequences.  Luckily, since Debian is
open source, their users can submit patches to fix this.

P.S.  Thank you very much for helping to maintain zsh.  It's perhaps
the most featureful shell out there, and I like it.

Kind regards,
~Jason Spiro

-- 
Bug#772985: http://bugs.debian.org/772985
Debian Bug Tracking System

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Nathan Schwarz]

This is already possible. The guys haven't read the manual.

zle-keymap-select () {
    if [ $KEYMAP = vicmd ]; then
        PROMPT="$(setPrompt ':')"
    else
        PROMPT="$(setPrompt '>')"
    fi
    zle reset-prompt
}
zle -N zle-keymap-select

This is my personal setup, but you can put in anything you want (obviously).
For the blinking-cursor-stuff you can use this:

zle-keymap-select () {
    if [ $KEYMAP = vicmd ]; then
        echo -en "\e[5 q"
    else
        echo -en "\e[1 q"
    fi
    zle reset-prompt
}
zle -N zle-keymap-select

-Nathan

Ps: Sorry for double-sending Jason, I replied to you instead of replying to the ml.

--
/"\  ASCII Ribbon Campaign
\ /  - against HTML emails
 X   - against proprietory attachments
/ \  http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 17,  8:58am, Nathan Schwarz wrote:
}
} zle-keymap-select () {
}     if [ $KEYMAP = vicmd ]; then
}         echo -en "\e[5 q"
}     else
}         echo -en "\e[1 q"
}     fi
}     zle reset-prompt
} }
} zle -N zle-keymap-select

You don't even need the reset-prompt in that case because you're echo'ng
a nonprinting sequence that causes the terminal to change the cursor
shape.

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Oliver Kiddle]

Bart wrote:
>
> } zle-keymap-select () {
> }     if [ $KEYMAP = vicmd ]; then
> }         echo -en "\e[5 q"
> }     else
> }         echo -en "\e[1 q"
> }     fi
> }     zle reset-prompt
> } }
> } zle -N zle-keymap-select
> 
> You don't even need the reset-prompt in that case because you're echo'ng
> a nonprinting sequence that causes the terminal to change the cursor
> shape.

However, you will need to ensure that the cursor is always reset when a
line is accepted. Most reliable place to do that appears to be POSTEDIT:
  POSTEDIT+=$'\e[2 q'

I find the cursor shape is actually much better than the prompt (or
right prompt) for indicating the mode. Only problem is that it can be
hard to find a narrow bar style cursor in a screenful of text.

I'd also recommend configuring either the zle highlighting of the region
or the cursor to use some colour. If you take the defaults of both zsh
and most terminal emulators, the cursor is a large inverse block and the
region is highlighted in inverse video. This makes it hard to tell where
the cursor is and whether the cursor position is included in the region
or not.

Oliver

Re: Fwd: In Vi mode, show whether "insert" or "command" state is active

[Bart Schaefer]

On Dec 17,  2:13am, Jason Spiro wrote:
}
} ---------- Forwarded message ----------
} 
} Zsh's Vi emulation does not show the user which mode is active.  This
} is frustrating and confusing.  (It's like an electric oven with no
} indicator to show whether the oven is on or off.)
} 
} It would be very good if zsh, too, would show the user which mode was
} active.  You can do this any way you like.  I would like it if you did
} this by setting the cursor style, just as gVim does.

Check out this thread:

http://www.zsh.org/mla/users/2013/msg00534.html

(Requires ZSH_VERSION > 5.0.3 to avoid an infinite loop bug.)

} Here is how to set the cursor style (in supported terminals):
} 
} Set cursor to blinking bar:  echo -en "\e[5 q"
} Set cursor to blinking block:  echo -en "\e[1 q"

This should do it for you (note that I don't have a terminal that
supports the #5 cursor so this is only partly tested):

    zle-keymap-select() {
      case $KEYMAP in
      (vicmd) print -nR $'\e[5 q';;
      (viins) print -nR $'\e[1 q';;
      (*) print -nR $'\e[2 q';;
      esac
    }
    zle -N zle-keymap-select

You will also need to run zle-keymap-select from zle-line-init to
set up the cursor properly on entry to the editor.

} The above commands definitely work in recent versions of iTerm2 (for
} Mac OS) and xterm.  I haven't tested them in any other terminal
} emulators.  Surely some terminal emulators do nothing at all in
} response to the above control sequences.

Gnome-terminal displays garbage characters, so this is not something
one can do in general.  As far as I can tell even gVim does not have
this feature built in, you have to supply some .vimrc coding.