Support alt + arrow keys for moving by word on Mac

[henderea]

Description

On Mac, the normal keyboard shortcut for moving the cursor one word at a time is alt + left/right arrow keys. However, pgcli does not seem to support this when entering a query (it inserts characters instead of moving the cursor). Instead, I have to use the control key with the arrow keys, which is a windows/linux shortcut. Please support the proper shortcut on macOS.

Your environment

OS: macOS 10.14.6 CLI Version: 3.0.0 pip freeze:

agate==1.6.1
agate-dbf==0.2.1
agate-excel==0.2.3
agate-sql==0.5.4
appdirs==1.4.4
applib==1.2
arrow==0.13.0
b2==1.4.2
b2sdk==0.1.8
Babel==2.8.0
certifi==2020.4.5.1
chardet==3.0.4
cli-helpers==2.0.1
click==7.1.2
cmdln==2.0.0
CodeIntel==2.0.0
configobj==5.0.6
csvkit==1.0.5
dbfread==2.0.7
esprima==4.0.1
et-xmlfile==1.0.1
funcsigs==1.0.2
future==0.18.2
humanize==2.4.0
idna==2.9
Inflector==3.0.1
isodate==0.6.0
jdcal==1.4.1
leather==0.3.3
libclang-py3==3.9.0
logfury==0.1.2
openpyxl==3.0.3
parsedatetime==2.5
pgcli==3.0.0
pgspecial==1.11.10
prompt-toolkit==3.0.5
psycopg2==2.8.5
Pygments==2.6.1
pyobjc-core==6.2
pyobjc-framework-Cocoa==6.2
pyobjc-framework-Quartz==6.2
python-dateutil==2.8.1
python-slugify==4.0.0
pytimeparse==1.1.8
pytz==2020.1
requests==2.23.0
setproctitle==1.1.10
simplejson==3.17.0
six==1.15.0
SQLAlchemy==1.3.17
sqlparse==0.3.1
tabulate==0.8.7
terminaltables==3.1.0
text-unidecode==1.3
tqdm==4.46.0
Unidecode==1.1.1
urllib3==1.25.9
wcwidth==0.1.9
xlrd==1.2.0
zope.cachedescriptors==4.3.1

[catherinedevlin]

I wasn't able to duplicate this bug - that is, the Option key plus right or left arrow on my Mac moves the cursor left or right by a full word, as you were expecting.

I'm also on dbcli version 3.0.0 and OS X 10.14.6 (Mojave), so I can't explain the discrepancy that way.

Also, I think that this functionality is inherited from prompt-toolkit, so whatever issue you're experiencing probably traces back to there. I tried out https://github.com/prompt-toolkit/python-prompt-toolkit/blob/master/examples/tutorial/sqlite-cli.py and saw the same cursor movement behavior there. Do you want to try that out and see if your bug persists there?

[j-bennet]

To be fair, pgcli has its own keybindings as well, but those are for pgcli-specific things (such as function keys):

https://github.com/dbcli/pgcli/blob/master/pgcli/key_bindings.py

Other keybindings are provided by prompt-toolkit, and there's a lot of them:

https://github.com/prompt-toolkit/python-prompt-toolkit/tree/master/prompt_toolkit/key_binding/bindings

So yes, this is the issue for @jonathanslenders.

[henderea]

After looking into some stuff, it was probably an issue with iTerm2 key configs. It looks like alt+left was set to send ^[B and alt+right was set to send ^[F. I've switched those to use the ^[[1;5D and ^[[1;5C that were set for the left and right arrows with the control key, and it works as expected. I'm guessing the ^[B and ^[F escape sequences aren't as common, but I've never had any trouble with them in anything that uses the system or homebrew-installed readline library like zsh, NodeJS, and Ruby.

On the topic of the system readline library, one really nice config I found online for ~/.inputrc is

# Use the text that has already been typed as the prefix for searching through
# commands (basically more intelligent Up/Down behavior)
"\e[B": history-search-forward
"\e[A": history-search-backward

This sets it up so that if I start typing, the up and down arrows that navigate the history will navigate only between commands that have the same content before the point my cursor is at. For example, if I type echo, then the up and down will only navigate between history entries that start with echo. Also, if I type echo "hi", then move my cursor to right after echo, it will only match based on echo since that's what's before my cursor. It would be really awesome if pgcli could have functionality like that, though that should probably be a separate github issue. I'm guessing some aspects of the tool, like the autocomplete, prevent the standard system readline library from being used, since my ~/.inputrc is normally respected when the system readline library is used.

[henderea]

Let me revise that statement. After looking at the built-in terminal app, I found that the intended escape sequence is ^[b and ^[f. The iTerm2 app was using capital letters, which seems to have been the issue. Switching it to lowercase works fine.

[jonathanslenders]

@henderea : Is that the default configuration for iTerm2? It's easy enough otherwise to add the capital versions to the default key bindings in prompt_toolkit. A bit weird though.

[henderea]

@jonathanslenders I had never changed any of those configs, so the capital versions are definitely the default, at least for whatever version of iTerm2 I started off with.

[lordlycastle]

This is not something for this tool to handle! This is based on your terminal client. I already have Meta+<L/R> working to jump words in pgcli in iTerm.