zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: "zsh-workers@zsh.org" <zsh-workers@zsh.org>
Subject: Re: In Vi mode, show whether "insert" or "command" state is active
Date: Fri, 26 Dec 2014 11:21:01 -0800	[thread overview]
Message-ID: <141226112101.ZM17094@torch.brasslantern.com> (raw)
In-Reply-To: <27275.1419593532@thecus.kiddle.eu>

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.


  reply	other threads:[~2014-12-26 19:20 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-22  0:07 Fwd: " Jason Spiro
2014-12-22  1:57 ` Bart Schaefer
2014-12-22 18:25   ` Peter Stephenson
2014-12-22 18:44     ` Ray Andrews
2014-12-22 18:44   ` ZyX
2014-12-23  4:40     ` Bart Schaefer
2014-12-25  4:15     ` Jason Spiro
2014-12-25 20:34       ` ZyX
2014-12-25 23:18         ` Bart Schaefer
2014-12-26 11:32           ` Oliver Kiddle
2014-12-26 19:21             ` Bart Schaefer [this message]
2014-12-26 21:58               ` Christian Neukirchen
2014-12-27  0:31                 ` Bart Schaefer
2014-12-29  3:43 Jason Spiro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=141226112101.ZM17094@torch.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).