4 ms·
Revolutionizing Text Editor Navigation an Altarnative to Vim and GNUEmacs
I'm attempting to develop a smarter and more user-friendly keyboard-centric navigation system for text editors. I'm aiming to make it as easy to use as arrow keys, yet accessible from the comfort of the home row, blending ergonomic ease with the cool factor of only using the keyboard.
I firmly believe that the strength of editors like Emacs or Vim isn't just about gaining marginal speed gain in navigation at the cost of a steep learning curve. It's about their command-based approach, scripting capabilities to manipulate text files, and the extensive customization they offer. Complex and non-intuitive navigation systems only serve to gatekeep widespread adoption of these editors.
I'm embracing human-centric design principles from the book "The Design of Everyday Things."
I want to clarify that the system I'm designing is program agnostic, just like many folks integrate Vim keybindings into Emacs with Evil mode. My idea is adaptable to any text editor by tweaking keybindings. Let's delve into the flaws of both Vim and Emacs navigation systems.
Vim's shortcomings:
Unintuitive mapping of HJKL to (left, Up, Down, Right).
Distinct modes for navigation and text input.
The HJKL mapping in Vim isn't intuitive. People argue that once you're used to it, it's fantastic. However, I'm striving for something as simple as using the arrow keys. No one ever struggled to adapt to arrow keys.
Another issue is Vim's modes. Personally, I find the concept of modes less intuitive. I'm not an expert, but the idea of shifting modes to insert or perform tasks and then returning to 'normal mode' seems peculiar.
Emacs' problems:
Poorly mapped navigation keys.
Complex keybindings deviating from the standard.
CTRL+F (forward), CTRL+B (backward), CTRL+P (previous line), and CTRL+N (next line) were designed for easy recall but suffer from a mapping perspective. Let's break it down:
Using CTRL+F, CTRL+B involves moving fingers down and left to move the cursor right! And vice versa!
You even use different hands to move up or down.
The distinction between mnemonic 'previous' (CTRL+P) and 'backward' (CTRL+B) isn't clear.
My current concept involves using Ctrl as a modifier key and adopting the intuitive and widely known WASD system or my preferred IJKL keys to replace the arrow keys:
CTRL+W or CTRL+I
CTRL+A or CTRL+J
CTRL+S or CTRL+K
CTRL+D or CTRL+L
I aim to keep existing shortcuts intact, such as CTRL+C for copy, CTRL+V for paste, CTRL+F for find, and CTRL+R for replace. This configuration aims to offer familiar functionalities while enhancing navigation, tapping into the familiarity of the WASD system used in games or the standard arrow keys layout. This system leverages the widespread adoption of the WASD system in games or the standard arrow keys.
The only disadvantage is that you lose the CTRL+arrow to move a word at a time feature of the standard arrow movements, but I'm convinced most people (using editors like Obsidian, Notion, Word, or Google Docs) don't actually use this feature. And we could create it by adding a second modifier key (CTRL+Shift+F) to move a word to the right.
I'm planning to implement this in Emacs as it's easy to do so editing the .emacs file and I won't have to think about modes. But eventually, I may code it into Gedit and even create plugins...
I look forward too feedback and ideas.
- pwg 3y ago> Unintuitive mapping of HJKL to (left, Up, Down, Right). Provided one's keyboard is labeled in the way the ADM3a keyboard was (https://en.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg https://en.wikipedia.org/wiki/File:KB_Terminal_ADM3A.svg) they become perfectly intuitive. :) All joking aside, you may want to look at WordStar key bindings as part of your research. WordStar used a similar mapping to wasd, only it was control+e for up, c+s for left, c+d for right and c+x for dow (creating what came to be known as the "WordStar diamond"). Other movements were mapped to adjacent keys. Less often used movements and other functions were mapped to two key sequences. You may find some further inspiration for your project from what WordStar used years ago.
- 1oooqooq 3y agoAlso, nothing ticks all the usability boxes from actual HCI papers as vim's edit mode. It's confusing because the UI around it never evolved. But one can argue that even moving your hand to the mouse to select text, click menus etc is exactly that same pattern with a physical component. That's why removing this from a vim expert is like removing the mouse from an excel office worker.
- carlosmartins 3y agoThank you for your response! I'm truly amazed by this website and the wonderful people here. Everyone is so knowledgeable and kind-hearted, it's really great. I will look at WordStar immediately =).
- leejoramo 3y agoI am all for your efforts. I am very keyboard centric. My sweet spot is macOS keyboard shortcuts. Especially those as defined by BBEdit. But I have learned from all the platforms I have worked on. (TRS-DOS, MSDOS, OS/2, macOS, Windows, Linux) I never get into Vim primarily because of HJKL. I have spent many hours trying. But I do use IJKL as arrow keys via hardware keyboard macros, AutoHotKey, Karabiner Elements, or the like. I have mostly bent Windows and KDE Linux to my Mac-like keyboard standards. (And my Mac’s are heavily customized too) I do heavily use CTRL and arrow keys for word by word navigation, and all the other arrow key bindings. So that is a personal deal breaker for me. You should take a look at the Micro editor. It shares many of your ideas. https://micro-editor.github.io https://micro-editor.github.io I would like to follow your work. Please post a link to a blog or git repository