Keyboard Intents

[sffjunkie]

Currently the action associated with a key press or combination of keys is hardcoded and may not match the mental model of the user e.g. on some OSes the 'end' key moves to the end of a line and on others command + right arrow performs the same function.

It would be nice to have a preferences pane in which the user can match key combos with the desired intent à la SpicyKeys.

This could be done by introducing a set of B_ constants for such things as B_END_OF_LINE which the input server could map from the user's preferred key combo.

BView could respond to these constants instead of hardcoding the key combo.

[jscipione]

I have thought about this feature a bit already and I think the best approach is to extend the BTextView class to just have more keyboard options and not have a preference pane. Any class that derives from BTextView would also inherit the keyboard options from it. Here are the keyboard options that I propose:

Beginning of line is home key and Alt+left, end of line is end key and Alt+right. Beginning of document is Alt+up, end of document is Alt+down. Back a word is Ctrl+left, forward a word is Ctrl+right. Up a paragraph is Ctrl+up, down a paragraph is Ctrl+down. Add shift the each of the above shortcuts to highlight. Page up and Page down would go up a page and down a page respectively of course.

A mnemonic to remember the above is that the Alt key makes global step, working on the level of lines and documents, whereas the Ctrl key makes local step working on the level of words and paragraphs. This jives with the Haiku philosophy because Alt is the dominant key and Ctrl is the subordinate one, opposite of Windows. Remember that we have already made a provision for Windows people have to option to switch Alt and Ctrl in the keymap preference pane.

Also emacs keybindings would be another nice addition. Ctrl+A for beginning of line, Ctrl+E for end of line, Alt+F to go forward a word, Alt+B to go back a word, Ctrl+K to delete to the end of the current line. There are probably a few other common ones people can suggest as well. I guess Alt+B already means bold most of the time so Alt+B should go back a word only if no text is highlighted, otherwise it is reserved for applications to implement bold. Yes emacs key bindings are a bit on the nerdy Linux/sysadmin/programmer side of things but we are talking about keyboard shortcuts for text editing here, the kind of thing that nerds need to do an awful lot.

I am not sure how much benefit there would be to making this all configurable, adding a preference pane for it, and putting it all in the input server. But, if you really think that it would be worthwhile and you can convince me of why, I would be willing to put some work in to make this happen. I think that extending the BTextView class with more options is enough. For those who want the Home and End key to respectively go to the beginning and end of the document (Mac style) instead of to the beginning and end of a line (Windows style), well, screw those people. They'll just have to use Alt+up and Alt+down.

[axeld]

I don't really see why Emacs keybindings would be useful, besides that you must not reuse any Alt-* combinations since those may break applications (Alt-F is usually "find" btw).

But the fact that you find Emacs keybindings useful (while I might prefer Vi style) shows that intents like suggested might be a good idea. And indeed there isn't a single useful text editor that I know of that isn't completely configurable to the user's needs (wants). BTextView is a good example of why such a mechanism might be useful system wide, and it would already serve as a solution to use for applications that wants to have their shortcuts configurable. If done properly, all text editors could make behave the same by default (including BTextView) which alone would be a very nice thing to have.

Another reason for having such a system are different keymaps and keyboard layouts - what works well in one combination, might be very annoying in another. And best of all, you wouldn't need to use it at all, if you see no value in it ;-)

[jscipione]

Replying to axeld:

I don't really see why Emacs keybindings would be useful, besides that you must not reuse any Alt-* combinations since those may break applications (Alt-F is usually "find" btw).

Well, forget the Emacs keybindings in BTextView then.

I guess a configuration settings panel would be okay then. As long as the defaults are sane.

[leavengood]

I have thought of the concept in this ticket before myself, except for more than just text editing. Things like switching applications (currently Ctrl-Tab, though I started a discussion to change it to Alt/Cmd-Tab), changing workspaces, changing input methods and keymaps, and maybe even things like cut and paste could be abstracted out into "actions" which could be configurable at the input_server level.

I think it could be very useful, but things like cut and paste or undo/redo which are currently handled inside applications would require a lot of code changing to work. And then third-party apps might still have their own shortcuts which would not respect what the system setting was. There certainly are issues.

But I think we could certainly start with system level actions, and I may take a stab at implementing this for application switching soon. When I do that I'll take ownership of this ticket.