dbcli / mycli

A Terminal Client for MySQL with AutoCompletion and Syntax Highlighting.
http://mycli.net
Other
11.42k stars 660 forks source link

In vi editing mode '<' and '>' are not inserted #1087

Closed hunsakerbn closed 1 year ago

hunsakerbn commented 2 years ago

mycli version 1.26.1 MacOS 12.5 installed via homebrew

In vi editing mode I can't insert < and > characters. Also hitting one of them as the first character of a line causes a divide by zero error.

I fixed this by disabling the following 2 lines in key_bindings.py:

--- key_bindings.py~    2022-09-01 14:50:41.000000000 -0600
+++ key_bindings.py 2022-09-15 12:58:25.000000000 -0600
@@ -61,7 +61,7 @@
         else:
             b.start_completion(select_first=False)

-    @kb.add('>', filter=vi_mode)
+    # @kb.add('>', filter=vi_mode)
     @kb.add('c-x', 'p', filter=emacs_mode)
     def _(event):
         """
@@ -82,7 +82,7 @@
                 cursorpos_abs -= 1
             b.cursor_position = min(cursorpos_abs, len(b.text))

-    @kb.add('<', filter=vi_mode)
+    # @kb.add('<', filter=vi_mode)
     @kb.add('c-x', 'u', filter=emacs_mode)
     def _(event):
         """

If editing mode is emacs, there is no problem.

rolandwalker commented 2 years ago

Hi!

This arises from my change, and I will fix it.

The divide-by-zero is fixed but not released.

I thought the vi behavior was correct, because < and > could be inserted after pressing i to enter insert mode.

In the simplest case, since I apparently don't understand vi bindings, we can disable the prettification feature when in vi mode.

gimslab commented 1 year ago

Thanks, @hunsakerbn, I commented two line as you said above. I was freed from annoying symptoms. my macOS is 12.3.1, mycli is 1.26.1 and installed via homebrew

hunsakerbn commented 1 year ago

After a look at prompt_toolkit I believe this patch achieves what was originally intended:

--- key_bindings.py~    2022-09-15 12:58:25.000000000 -0600
+++ key_bindings.py 2022-10-11 11:23:03.000000000 -0600
@@ -1,6 +1,6 @@
 import logging
 from prompt_toolkit.enums import EditingMode
-from prompt_toolkit.filters import completion_is_selected, emacs_mode, vi_mode
+from prompt_toolkit.filters import completion_is_selected, emacs_mode, vi_navigation_mode
 from prompt_toolkit.key_binding import KeyBindings

 _logger = logging.getLogger(__name__)
@@ -61,7 +61,7 @@
         else:
             b.start_completion(select_first=False)

-    @kb.add('>', filter=vi_mode)
+    @kb.add('>', filter=vi_navigation_mode)
     @kb.add('c-x', 'p', filter=emacs_mode)
     def _(event):
         """
@@ -82,7 +82,7 @@
                 cursorpos_abs -= 1
             b.cursor_position = min(cursorpos_abs, len(b.text))

-    @kb.add('<', filter=vi_mode)
+    @kb.add('<', filter=vi_navigation_mode)
     @kb.add('c-x', 'u', filter=emacs_mode)
     def _(event):
         """

This makes '<' and '>' work normally in insert mode, but has a special meaning only when in vi navigation mode.

pdbg commented 1 year ago

@hunsakerbn: The fix works simply fine! Can we plan to include the change in the release to avoid manually patching the file?

bibli-alex commented 1 year ago

confirming this also works well for me.

gimslab commented 1 year ago

I visited this page again today after upgrading python. leave for memory until patch

/opt/homebrew/Cellar/mycli/1.26.1_1/libexec/lib/python3.11/site-packages/mycli/key_bindings.py

64c64
<     @kb.add('>', filter=vi_mode)
---
>     #@kb.add('>', filter=vi_mode)
85c85
<     @kb.add('<', filter=vi_mode)
---
>     #@kb.add('<', filter=vi_mode)

the thing I found today is after that fix, I can indent or de-indent with '>' or '<' keys in vi-navigation mode. unlike vi original behavior, blocking is not required.