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

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

[Jason Spiro]

On Fri, Dec 26, 2014 at 6:32 AM, Oliver Kiddle <okiddle@yahoo.co.uk> wrote:
> 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.

Hmmm.

In viins mode, you could show a bright-white '-- INSERT --' indicator
somewhere on screen.  (Last line, like Vim?  First line?)  In vicmd
mode, you could hide the indicator.  This way, you could take
advantage of users' peripheral vision to make them aware of which mode
they're in.

Or you could indicate the mode using cursor color, like Emacs Viper
does.  In insert mode, turn the cursor green.  In command mode, turn
the cursor back to its normal color.

Or you could do both.

ZyX wrote:
> 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).

Other modes are so uncommonly used that you don't actually need to
bother identifying them.  (Optimize for the common case, not for
uncommon cases.)  But if you insist, you could change the '-- INSERT
--' indicator to '-- name_of_mode --' or something.