Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

vi modal indicator #208

Open
shanemikel opened this issue Apr 8, 2019 · 7 comments
Open

vi modal indicator #208

shanemikel opened this issue Apr 8, 2019 · 7 comments

Comments

@shanemikel
Copy link

Readline supports the vi editing mode, with these options in ~/.inputrc

set editing-mode vi
set show-mode-in-prompt on
set vi-cmd-mode-string :
set vi-ins-mode-string +

The show-mode-in-prompt feature is a really helpful bit of user feedback for a modal editing system like Vi. You can test this feature by writing the configuration above, and running Bash.

@AdminXVII
Copy link

I think a good way would be to follow NVim's way: using a line cursor ('\033[6 q') for insert and emacs mode and switch to a block cursor for command mode.

@shanemikel
Copy link
Author

I disagree @AdminXVII. The issue is that not all terminals support cursor modes.

The default behavior of iPython (which doesn't use readline anymore) is to show [ins] in insert mode, and [nav] in normal/navigation mode. I think that's pretty good and self explanatory.

@shanemikel
Copy link
Author

I should also say that the default indicators of readline are (cmd) for normal/command mode and (ins) for insert mode. Maybe it's better to use the readline defaults given the library's lineage.

@max-sixty
Copy link

FWIW this is the config I use for IPython, to get cursors:

   3import sys
   4from prompt_toolkit.key_binding.vi_state import InputMode, ViState
   567def get_input_mode(self):
   8return self._input_mode
   91011def set_input_mode(self, mode):
  12shape = {InputMode.NAVIGATION: 2, InputMode.REPLACE: 4}.get(mode, 6)
  13raw = u'\x1b[{} q'.format(shape)
  14if hasattr(sys.stdout, '_cli'):
  15out = sys.stdout._cli.output.write_raw
  16else:
  17out = sys.stdout.write
  18out(raw)
  19sys.stdout.flush()
  20self._input_mode = mode
  212223ViState._input_mode = InputMode.INSERT
  24ViState.input_mode = property(get_input_mode, set_input_mode)
  25c.TerminalInteractiveShell.editing_mode = 'vi'
  26c.TerminalInteractiveShell.prompt_includes_vi_mode = False

@pjetherton
Copy link

The issue is that not all terminals support cursor modes.

Well can't we have a graceful fall-back for those that don't? Or allow this as a configuration option somewhere?

@gwenn
Copy link
Collaborator

gwenn commented Nov 7, 2021

For reference, replxx uses a callback to update prompt dynamically:
https://github.com/AmokHuginnsson/replxx/blob/master/examples/cxx-api.cxx#L228-L232

dmlary added a commit to dmlary/rustyline that referenced this issue Apr 6, 2024
rustyline doesn't currently support changing the prompt while in the
core readline loop.  There are a number of open PRs and issues for this
functionality, but all of them appear to be stalled for more than a
year.

Looking at kkawakam#696 and 4ec26e8, the traditional appoach to this is to
provide a reference to a trait object (`Prompt` or `ToString`), but with
that appoach there's no way to cause the prompt to be redrawn for a
change without user input.  This means for these appoaches the prompt
could change without being displayed to the user.

There's an existing mechanism to allow another async task/thread to push
input into the core readline loop, the `ExternalPrinter`.

In this commit, I expand `ExternalPrinter` to add `set_prompt()`.  With
various plumbing, this function results in `wait_for_input` to return
`Cmd::SetPrompt(String)`.

One of key change here is `State.prompt` changes from `&str`
to `String`.  There is a performance hit here from the copy, but
rustyline would need to prompt and receive input hundreds of times per
second for the copy to have a noticable performance inpact.

Added examples/dynamic_prompt.rs to demonstrate the functionality.

Closes kkawakam#417

Related kkawakam#208, kkawakam#372, kkawakam#369, kkawakam#417, kkawakam#598, kkawakam#696
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants