search

spyder-ide / spyder

Official repository for Spyder - The Scientific Python Development Environment
https://www.spyder-ide.org
MIT License
8.28k stars 1.61k forks source link

Inconsistencies between the Home builtin action and the custom "start of line" shortcut action #7884

Open jnsebgosselin opened 6 years ago

jnsebgosselin commented 6 years ago

Background

Actions for the Home and End keys are currently hard-coded in the Editor here.

The reason for this was to provide consistency with macOS (see Issue #495), because Home and End do not corresponds to the builtin MoveToStartOfLine and MoveToEndOfLine shortcut in this OS, as you can see in the table below.

image

Later, the custom start of line and end of line shortcuts were added to the keyboard shortcut preferences.

Problem Description

The hard-coded action for the Home keypress event do a Smart HOME feature (cursor is first moved at indentation position, then at the start of the line) while our custom start of line shortcut calls a standard MoveToStartOfLine action.

Also, I'm not sure that the hard-coded actions for Home and End are required anymore after the changes introduced in PR #7768.

I think we should :

ccordoba12 commented 6 years ago

Your plan seems very thorough. Please go ahead with it.

jnsebgosselin commented 6 years ago

ok, now I understand. The current command for the start of line and end of line shortcuts are Meta+A and Meta+E. Those are the Emacs command for these shortcuts!

However, the mistake we did is that we should have translated the Meta key to the Alt key in Qt. Here is a citation from the Emacs tutorial I'm currently following:

M- means hold the META or EDIT or ALT key down while typing . If there is no META, EDIT or ALT key, instead press and release the ESC key and then type . We write for the ESC key.

The problem I see with our current set of default shortcuts is that it mixes commonly accepted command in Windows and Linux with Emacs command.

For example, most people, I assume, use the End key in Windows to go to the end of the line while our current command for this shortcut is the Emacs one Alt+E. Conversely, our default command for the copy shortcut is the commonly known Ctrl+C key combination, while in Emacs it should be Alt+W.

So bottom line, we need to have two sets of separate shortcuts as the original plan was. Until now, I think we should provide the most commonly used command in Windows and Linux for our shortcuts and avoid mixing Emacs with default Windows/Linux/macOS command in our default.

I'm going to open an Epic to list what I think needs to be done regarding the shortcuts in the Editor. We started a discussion about this somewhere, but I can't find it anymore...

jitseniesen commented 6 years ago

ok, now I understand. The current command for the start of line and end of line shortcuts are Meta+A and Meta+E. Those are the Emacs command for these shortcuts!

Actually, on Emacs the short cuts for start/end of line are Ctrl+A and Ctrl+E. The short cuts Meta+A and Meta+E go to start/end of sentence (in English text).

jnsebgosselin commented 6 years ago

ok, now I understand. The current command for the start of line and end of line shortcuts are Meta+A and Meta+E. Those are the Emacs command for these shortcuts!

Actually, on Emacs the short cuts for start/end of line are Ctrl+A and Ctrl+E. The short cuts Meta+A and Meta+E go to start/end of sentence (in English text).

Yes, so double confusion on our part! Thanks for your comment.

jnsebgosselin commented 6 years ago

Actually, I think I was wrong.

Meta+A and Meta+E were not defined based on Emacs keybindings, but based on the keybindings for the MoveToStartOfBlock and MoveToEndOfBlock on macOS instead where there is actually a Meta key.

Edit: So we should have 3 sets of keybindings: Windows/Linux, Emacs and macOS

jnsebgosselin commented 6 years ago

After looking a little bit into this, this is not going to be as easy to fix as it seemed.

So I think the start of line, end of line, previous line, next line, previous char, next char, previous word, next word, start of document and end of documents shortcuts were added in anticipation for Emacs keyboard commands support.

However, all of these shortcuts are semi-broken in Spyder currently. For example, if we assign the Ctrl+F command to the next char shortcut, doing the Ctrl+F key sequence will indeed move the cursor forward by one character. The problem is with text selection, i.e. that doing Shift+Ctrl+F will do absolutely nothing.

So I think we need to add one layer of complexity when handling shortcuts of the type "Cursor motion". First of all, when creating a shortcut of the type "cursor motion", we need in fact to create two shortcuts: one with the key sequence assigned by the user and another one that adds that Shift modifier for text selection.

This also means that in the Shortcut Editor, we need to blacklist the use of the Shift key as a modifier for "cursor motion" type shortcuts. We also need to take that into account when checking for conflicts with other shortcuts.

jnsebgosselin commented 6 years ago

@ccordoba12 is it ok to wait for PR #7929 to be merged before working to fix this?

ccordoba12 commented 6 years ago

Sure, no problem with that.