Vim ergonomics

[seL4cious]

A lot of what you are saying resonates with me.

I love vim because of the amazing level of power that comes to you effortlessly when editing a file.

Others have mentioned spacemacs, and that's what I use. Not only do you have that same Vim power when editing a file, it manages to extend that power to controlling the IDE as a whole.

Mouse controll? check

Context menus to facilitate discovery? BIG CHECK!

* `spc-f-f` (menu-find-file) and you can quickly go through filepath, with real-time updates on matches.
* `spc-p-f (menu-projectile-file) will start a text search for files in project tree (detected by .git file by default)
* `spc-spc` gives a live-update search of commands (very rarely had to go to google to find a command that does what I need)

[eekee]

Huh! Maybe I should switch my operating system to Emacs. What? Emacs is an operating system, look at all you can do with it. People are even writing text editors for it.

[Schol-R-LEA]

Huh! Maybe I should switch my operating system to Emacs. What? Emacs is an operating system, look at all you can do with it. People are even writing text editors for it.

I'll admit that when I was starting out using a *nix (Ultrix, on a diskless workstation - and yes, even the female CS students spelled that with a 'c'), the old joke 'Eight Megabytes and Constantly Swapping' - remember when 8 MiB was an unimaginably large amount of RAM even for a VAX? - was still pretty common. By the standards of modern IDEs, though, Emacs looks positively lightweight, especially when running in NoX mode (which I know is an issue for those who do a lot of editing over SSH, or simply prefer terminals over GUIs).

OTOH, ed(1) is still THE STANDARD EDITOR!!!1!!!1!!

[linguofreak]

I use vigor, because vim sorely needs Clippy. How's that for ergonomics?



More seriously, I use Kate and vim fairly interchangeably. Generally vim when I've got a terminal window open, and Kate when I'm working in a file browser or creating a new file. Every once in a while I'll use Emacs. When editing very large files, I *definitely* use Emacs, because everything else I've tried becomes unusable more quickly with large file sizes (but that's a corner case, though now that I've tested Kate in that scenario, it isn't half bad. Gedit shows about as much distress at 1 MiB as Kate does at 1 GiB).

EDIT: It's actually fairly ironic that Emacs, having had a reputation of old for being heavy enough to swap a hefty machine to its knees, is now one of the go-to editors for file sizes that are a non-negligible fraction of RAM size.

[rant]Up until very recently, I had been using gedit instead of Kate, but finally got fed up with the client-side-decorations. My desktop is MATE, but pluma lacks most of the gedit plugin library, and MATE recently switched to GTK-3 (read that "GTK minus three"), so Pluma retains little of what had attracted me to GTK+2 era gedit, and I figured if Iwas going to be switching, I might as well try out something from a different environment entirely. The chances are actually high that I'll be switching to KDE sometime soon. It actually hasn't improved much that I can see since I first started using Linux, but GNOME, which was (IMHO) the gold standard in desktop environments (on *any* platform) a decade ago, has completely disintegrated, and as GNOME controls GTK, it's done some fairly bad damage to other DEs as they've decided that GTK2 is too long in the tooth to continue using.

I don't have a strong opinion in the editor Holy Wars, but I definitely do in the DE Holy Wars.[/rant]

[nullplan]

OTOH, ed(1) is still THE STANDARD EDITOR!!!1!!!1!!

I'm guessing this one will be escalated.

1. Real hackers write in ed.
2. Real hackers write with cat.
3. Real hackers use a hex editor on their disks to manipulate the file system structure manually
4. Real hackers manipulate cosmic radiation to cause bits to toggle on the medium in such a way that source code appears on the disk

Etc. pp.

To be honest, my biggest problem with emacs is in fact its other nickname, Escape-Meta-Alt-Control-Shift. While I did learn the piano when I was younger, I do not have the necessary dexterity for some of the more esoteric key bindings.

[eekee]

Good old jokes. Vigor actually exists now? Hahahaha!

The first machine I used Emacs on had 4 megabytes RAM. I didn't notice any swapping, but that's probably because I was just experimenting with this thoroughly unfamiliar system. I frequently rebooted and probably never edited more than two or three small files at once. It probably helped that I couldn't have X and Emacs installed at the same time due to disk space. I was surprised when I heard the "Eight megabytes" joke a few years later, but I later learned Emacs had memory management issues, if I understood right. It would explain the Emacs user tradition of selecting the smallest possible sections to change, rather than retyping whole lines as might be common with ed.

KDE... Does anyone remember the time KDE had an option to use KVim for any multiline text field? I thought it was a really cool idea, but barely tried it because KDE at the time was faaar too big and sluggish to put up with for long. (Also it was rotten horrible GUI. After a year or so of using Windows, I've had to come back to launching everything from the command line because icons are just too distracting.)

@nullplan: spacemacs may have different keybindings altogether. Not sure.

On topic, (wow!) I don't find the traditional tty keybinding set to be any worse than vi, ergonomically. The home row is a bit of a myth with my hands, and the "hjkl" sequence isn't even in the home position; that would be "jkl;". And having all 4 in a row is uncomfortable for my hands. Anyway, this "traditional tty keybinding set" is often called "emacs keys" in its modern extended form, and was sometimes called "wordstar keys" in the last century, but its roots are older than either program. I've forgotten parts of it now, though, and in any case vi is better by having bindings for scrolling a full page, a half page, or one line, and to move the cursor to the top or bottom lines of the window. Vim has recently broken these by trying to keep the cursor away from the top or bottom. In my world, this is the final nail in Vim's coffin; I need to filter information, which is often easily done by scrolling especially with vi keys, and I cannot easily get used to such arbitrary offsets.

Unfortunately, I'm finding my present choice of editor, Watcom VI, to have some awkward issues. regexp `^$` doesn't match a blank line although it should. It lacks vim's `{` and `}` which makes some things a bit slower, especially without `^$` regexps. Command entry always starts in overwrite mode. `~` and `@` are interpreted as case toggles in regexps, which is peculiar. Backspace at the beginning of command entry doesn't cancel the entry, unlike perhaps every other VI, although I think I've got used to this one in the last few days. I'm sad about these issues because I otherwise like it very much. It has menus but they're not too large at all; the right balance for my sanity. It has a normal-for-DOS windowing system too, but that sadly doesn't do anything in Win10. OpenWatcom also includes a GUI "viw", but I can't see how to set the font to something remotely readable. (It doesn't even default to "VI emulation", but that setting is easy to find.) Also it looks like WinXP.

I forgot to mention how good I think Windows keybindings are, as far as basic text editing goes. Text selection makes them so much more regular than either VI or traditional keybindings. On the other hand, they just require too many keys for many situations; the extra keys just become too un-ergonomic. I even find that to be the case at my desk.

[Schol-R-LEA]

Good old jokes. Vigor actually exists now? Hahahaha!

IIRC, the fans had started on VIgor the same day the first comic of that story arc was posted, and the first release came before the arc ended. Because that's how the UF fanbase rolled back then.

[klange]

I think anyone who is really interested in this stuff should take a crack at writing their own editor. I also think it's a very good thing to include in your OS.

[Schol-R-LEA]

I would recommend (again) Craig Finseth's The Craft of Text Editing as a starting point for anyone looking to write an editor, since even though it is almost 30 years old now, it covers most of the techniques and design considerations which come up in writing an editor. While the printed book is outrageously expensive today, there is a free version available on Finseth's own web site.

I suspect that even for a keyboard-focused text-mode editor the Common User Access bindings would be the best starting point for any new design, if only because most of the hard design decisions are already worked out, and you can be certain that most people using a computer would already know them. However, I know that the CUA is significantly biased towards US English (even in the various versions for other languages and countries), so others may disagree based on that. Also, I wouldn't want to discourage anyone from experimental layouts if they really thought they could build a better mousetrap.

Though looking at the history a bit may be called for first.

As has been mentioned before, the default Emacs bindings go back to TECO, and more specifically a set of macros for TECO - hence the name Editng MACros. It may be noted that the TECO command structure - and hence it's scripting language, which was basically just TECO controls batched together - has often been compared to line noise. TECO was a line editor, and my understanding is that a lot of the macros which made up the EMACS library were, in fact, screen editing extensions rather than editing commands. Both Stallman and Gosling started off porting TECO for their respective versions, but both independently decided to replace the editing core entirely instead, and focus on re-implementing the interface itself - which sounds really weird today, but TECO EMACS was well known enough that it must have seemed to make sense to them.

Similarly, the vi command set came from ed, though it originated with QED, a line editor written in the 1960s which Brian Kernighan happened to be familiar with, though he decided to simplify it a great deal - most people would say too much. Just as EMACS started as a screen-oriented extension to TECO, vi began life as a screen-editing extension to ed, though unlike EMACS (which had lasted several years in its original form), vi was turned into a separate program almost immediately.

The WordStar bindings are different from either of them, and as the name implies, came from the 1974 word processor WordStar. They weren't all that good, TBH, being pretty counter-intuitive, but the basic commands were easy enough to learn and few people using WS actually needed the less frequently used ones anyway. Many CP/M and early MS-DOS programs used these, and - as a personal note - they were the first screen-oriented editing command system I learned (I'd only used Pr1me BASIC and Applesoft BASIC before then, both of which were line-oriented and had almost no real editing capability to speak of - you just manually replaced the line you were changing, typing the whole thing out over again with the changes).

There are a lot of other bindings possible, of course; for example, in the late 1980s when WordStar was on the wane but before CUA started to build momentum, the WordPerfect bindings were adopted by a number of other word processors, though the WordStar bindings tended to remain the preference for programmer's editors in the MS-DOS world (mainly because of their use in the Turbo Pascal and Turbo C editors).

Modern Emacs-es usually can re-bind any and all keybindings, and Both Gnu Emacs and XEmacs have modes for CUA, vi, WordStar, WordPerfect, and other common binding models including some really obscure ones, though you risk binding collisions and problems with some ELisp scripts which were hard-coded with the default keybindings in mind. A lot of Emacs users who also use vim prefer to use 'evil mode' (a vi compatibility mode), for example. As for Spacemacs, I only looked at it briefly, and IIRC it re-maps most of the common functions to the CUA bindings. Of course, a number of Emacs users also do most of their editing with Org mode and its derivatives, even for coding (as its hypertext functionality can be used for a quasi-Literate Programming style mix of code and code documentation, something which intrepid Elisp coders have made a suite of tools for).

And if you really wanted to you could write your own modes, bindings, and toolsets to make it do almost anything (e.g., there are modes for web browsing, image and sound editing, reading and sending email, playing music, interacting with VCSes, remote wiki editing, and playing any number of games, as well as 'window managers' which extend Gnu Emacs to behave more graphically), so that rabbit hole can go as far as you have the persistence to take it.

(Oh, this was also discussed at length here, though it pains me to mention it as I made a fool of myself quite badly with some of what I said in that thread.)

[klange]

I suspect that even for a keyboard-focused text-mode editor the Common User Access bindings would be the best starting point for any new design, if only because most of the hard design decisions are already worked out, and you can be certain that most people using a computer would already know them. However, I know that the CUA is significantly biased towards US English (even in the various versions for other languages and countries), so others may disagree based on that. Also, I wouldn't want to discourage anyone from experimental layouts if they really thought they could build a better mousetrap.

I think the CUA presents a lot of problems for terminal-based editors in a modern context, since many of its most well known recommendations are already taken by terminal emulators themselves, eg. Shift+Insert for paste or F10 to activate menus.

[Solar]

Vim has recently broken these by trying to keep the cursor away from the top or bottom. In my world, this is the final nail in Vim's coffin...

:set scrolloff=0

Seriously. Vim is about as configurable as an editor gets. If something doesn't quite work the way you like, change the settings.

I personally like scrolloff=3, which is enough to give me the context of the code line I am looking at, but not so much as to be annoying. I've been using that setting for ages (and copying my favorite settings from my homepage to the ~/.vimrc of any new machine is among the first things I do), so I didn't realize the default had changed "recently" (?).

[Schol-R-LEA]

I forgot to mention that the bindings for nano (well, pico to be technical) are nice and simple, and the core set are all continuously displayed on screen in a help bar at the bottom - there's a second set which can be brought to the fore with a control, but all told it is less than 30 operations, according to Wicked-Pedo.




It's pretty good for simple editing jobs, when you just need an editor right away and don't need much else (pico was originally made as the editor for the Pine e-mail client, and was deliberately kept simple), so modern nano fills more or less the same role in terminal work under Linux and *BSD that Notepad does for Windows.

But like with Notepad, any serious editing job is going to bog down very quickly using nano.

[linguofreak]

Similarly, the vi command set came from ed, though it originated with QED, a line editor written in the 1960s which Brian Kernighan happened to be familiar with, though he decided to simplify it a great deal - most people would say too much. Just as EMACS started as a screen-oriented extension to TECO, vi began life as a screen-editing extension to ed, though unlike EMACS (which had lasted several years in its original form), vi was turned into a separate program almost immediately.

Not quite: em was a visual line editing extension to ed (editing one line at a time interactively, instead of taking commands and then requiring a separate print command to see their effect), developed at the University of London. But unlike EMACS, which was a set of macros for the turing-complete interpreted language provided by TECO, em from the start was a set of extensions to the source of ed, so it was a separate program (though much more closely related to ed than vim today is to the original vi, containing source code from the original AT&T ed). The guy who created em brought a tape of it with him when he visited Berkeley in summer of '76. There he showed it to, and provided the code to, Bill Joy, who extended it further into ex. By the time that ex was released outside of Berkeley with 1 BSD, he'd added a full-screen visual mode to it. It turned out that most users were spending almost all their time in visual mode, so in 2 BSD, ex was hard-linked as "vi", and if invoked as vi, it would start up in visual mode. This remains the setup on modern unices: vi and ex (and the name of the vi clone used on the system) are links to the same binary. BSD eventually stopped using their original code as the vi distributed with the system, as it was encumbered by the original ed sources, and most modern unices use some clone or other rather than the original vi.

Going back to EMACs, I'm not sure it's actually accurate to say that it wasn't a separate program from TECO on the start, or that it was descended from TECO: TECO provided a turing complete macro language, so it would be more accurate to say that EMACS was a program for TECO. We wouldn't say that Linux wasn't a separate program from the 386 (or even more jarringly, that it wasn't a separate microprocessor from the 386) in its early years, just because Linus did his original work on a 386.

[Solar]

em was a visual line editing extension to ed (editing one line at a time interactively, instead of taking commands and then requiring a separate print command to see their effect)...

Hence its name, em -- "editor for mortals". To be fair, QED / ed had to work on teletypes, where "interactive" had a bit different meaning.

It turned out that most users were spending almost all their time in visual mode, so in 2 BSD, ex was hard-linked as "vi", and if invoked as vi, it would start up in visual mode.

You've got to love how much meaning is in those two-to-four-letter executable names (like grep, which is derived from the QED-command g/re/p which it effectively emulates: "global, <regular expression>, print").

[eekee]

IIRC, the fans had started on VIgor the same day the first comic of that story arc was posted, and the first release came before the arc ended. Because that's how the UF fanbase rolled back then.

I remember now, I heard of Vigor back then from someone who used or worked on it. At the time, memories of the screaming horror of bloated commercial monstrosities trying to be helpful were just too fresh in my mind, so my response, joke or not, was to load the bombers with Napalm. Kill it with fire!

I think anyone who is really interested in this stuff should take a crack at writing their own editor. I also think it's a very good thing to include in your OS.

I think so too. I pretty-much have to as part of my premise is putting a good text editor into the GUI and the console and every other paradigm where text editing might be imaginable.

I would recommend (again) Craig Finseth's The Craft of Text Editing as a starting point for anyone looking to write an editor, since even though it is almost 30 years old now, it covers most of the techniques and design considerations which come up in writing an editor. While the printed book is outrageously expensive today, there is a free version available on Finseth's own web site.

Thanks! I've started reading it. I agree with its division of components; I'd pretty-much come to the same conclusion regarding the internal sub-editor. (This helps my confidence.)

Thanks too for the CUA link and other clarification. I was evidently quite wrong about WordStar, which is an interesting set of bindings.

I have been told some of the Emacs keybindings predate Emacs, but never found out which. I'm fairly comfortable with its basic cursor movement keys actually, although I did use a heavily customised viper-mode when I used Emacs. (viper-mode replaced vip-mode which obsoleted vi-mode if i remember right, and now there's evil-mode. Change goes on.)

Similarly, the vi command set came from ed, though it originated with QED, a line editor written in the 1960s which Brian Kernighan happened to be familiar with, though he decided to simplify it a great deal - most people would say too much.

Interesting you should write that last bit. vi's command set is actually that of ex, which is more complex than ed. Meanwhile, the originators of Unix were going the other way: sam's command set is simpler than ed's, but more regular and arguably more powerful.

The WordStar bindings are different from either of them, and as the name implies, came from the 1974 word processor WordStar. They weren't all that good, TBH, being pretty counter-intuitive, but the basic commands were easy enough to learn and few people using WS actually needed the less frequently used ones anyway. Many CP/M and early MS-DOS programs used these, and - as a personal note - they were the first screen-oriented editing command system I learned (I'd only used Pr1me BASIC and Applesoft BASIC before then, both of which were line-oriented and had almost no real editing capability to speak of - you just manually replaced the line you were changing, typing the whole thing out over again with the changes).

Mm. I'd say VI's bindings are just as counter-intuitive as WordStar's. Emacs's slightly less so. I don't think VI's keybindings were given very much thought. The HJKL set is merely where the arrows were printed on the budget terminal Bill Joy used (ADM-3A).

Now I'm wondering why I put all that effort into configuring viper-mode all those years ago. Did I really find VI keys better, or was I just taken in by the home row hype? I don't remember, but I do remember I was very happy with the result. I very much like VI's bindings for scrolling; all 6 of them. I don't think Emacs has keys for single-line scrolling, and I very dimly remember not liking its half-page bindings. Oh, VI's bindings for moving the cursor to the first and last lines of the window are great too. And Vim's move-to-paragraph keys, which I think Viper had. So basically, VI bindings have a lot to offer, with the much-praised HJKL being the least part, IMO.

Regarding BASIC, I thought Ataris were a bit good because you could move the cursor around and wherever you pressed Return; the line the cursor was on would be entered. You could list a line and change rather than retype it. However, it was slow and flawed. It didn't work with multiple lines unless you worked from the bottom up: when you pressed Return, the line below would be overwritten with "READY". The cursor moving and related editing features were built into the operating system as the editor device. As flawed as Atari's implementation was, I was very surprised, even a little disturbed when I learned Unix had no such feature at all. Acme and Emacs might have the closest similar features, with shell windows of Plan 9's window system being about half-way there.

Rebinding Emacs keys... yeah, the problem with that has always been clear, which is why I'd rather get Spacemacs or whatever than do it myself. Or modify my keyboard so it has ctrl shift alt down the left edge in place of caps shift ctrl; this helps a lot.

Of course, a number of Emacs users also do most of their editing with Org mode and its derivatives, even for coding (as its hypertext functionality can be used for a quasi-Literate Programming style mix of code and code documentation, something which intrepid Elisp coders have made a suite of tools for).

Interesting! Hypertext was essentially what made Acme so useful to me. I don't think org mode had been written when I was using Emacs, or I didn't imagine the value of it. I tried to use outline mode, but found the keybindings too clumsy, and mouse was barely an option back then. Also, outline mode is strictly hierarchal.

And if you really wanted to you could write your own modes, bindings, and toolsets to make it do almost anything (e.g., there are modes for web browsing, image and sound editing, reading and sending email, playing music, interacting with VCSes, remote wiki editing, and playing any number of games, as well as 'window managers' which extend Gnu Emacs to behave more graphically), so that rabbit hole can go as far as you have the persistence to take it.

As people have been saying for... oh, maybe 2 decades now, maybe more: Emacs is an operating system.

I think the CUA presents a lot of problems for terminal-based editors in a modern context, since many of its most well known recommendations are already taken by terminal emulators themselves, eg. Shift+Insert for paste or F10 to activate menus.

Indeed. Contrast Apple who added another key to the keyboard, as did literally everyone else but IBM, and had no conflict with terminals. Apple were even able to support some traditional (Emacs-like) keys in their GUI apps, only dropping it this decade. IBM had the excuse of retaining compatibility, and good keyboards weren't cheap in those days so people would have hated them if they'd demanded an extra key. I imagine it's possible they aimed to retain compatibility only with their own terminal software. Some IBM terminal keyboards I've seen have only a single small control key in a separate block, suggesting it was very rarely used and thus 'free' for the CUA. The computing world was very segmented, so although the basic Emacs keybindings might have been as much as 10 years old at the time, it's possible nobody on the CUA team had ever used them.

A programmer I knew who must have started his career in the 70s and quit in the 00s once told me, "I used Unix once. It had this text editor, what was it... Vi?" He really didn't sound happy with it, almost wrinkling his nose as if it smelled bad. At the time, I was too astonished to ask questions because I hero-worshipped Unix & thought it was much bigger than it actually was.

Vim has recently broken these by trying to keep the cursor away from the top or bottom. In my world, this is the final nail in Vim's coffin...

:set scrolloff=0

Seriously. Vim is about as configurable as an editor gets. If something doesn't quite work the way you like, change the settings.

I personally like scrolloff=3, which is enough to give me the context of the code line I am looking at, but not so much as to be annoying. I've been using that setting for ages (and copying my favorite settings from my homepage to the ~/.vimrc of any new machine is among the first things I do), so I didn't realize the default had changed "recently" (?).

My problem is I got into the habit of discarding config when changing machines or operating systems. I'm not sure why, I think depression might have had a part to play. Then there was the 10-year period when I used Plan 9, which didn't require much configuration to be fairly comfortable in the first place, so I thought I could do without. Worse, on the odd instances when I have tried to configure Vim or Elvis or anything else during this long period, it's variously been very difficult to find clear instructions (esp. Elvis) and/or has just failed to work, usually without an error message.

The options I'm looking at now are A: setting up some flavour of Emacs and keeping the configuration this time, or B: finishing my own editor. Setting up Emacs would be a project in itself; perhaps a larger project than setting up Vim, but I'd much rather have Lisp than an ad-hoc language. For instance, if I want to load my Forth files in fundamental mode in Emacs, I can just remove the filename association from the a-list or prepend an overriding entry. I already know these things and they're part of the e-lisp language. In Vim's configuration language, is it even possible to remove associations? Is there a frill-free mode named in the configuration language so I can set to override associations? If I set it, would it actually override or is Vim's language "first setting wins"? So many questions! Just give me a real language. And then there are all the other configuration changes I'd like to make. (At one point I considered writing a sort of Emacs in Python, but Lisp and Forth are so much better for DSLs.)

As for my editor, the internal sub-editor is essentially done, although it lacks undo. The command language is 3/4 done, but I've changed my mind about namespacing and want to revise all the names. To start using it, I need to finish file i/o and write a visual interactive (ahem) front end. Then to be really comfortable, I'd need to add undo. I basically know how to do these things, it's just a matter of concentrating and keeping my neuroses under control. OpenWatcom's VI is good enough to help with concentrating, and I have Sam for the mass changes. Sam's command language is more powerful than VI's and sometimes easier to type. To be honest, that's all overkill. Forth's syntax is so simple and this editor core so small that Notepad was not a bad choice. If I remember right, I abandoned Notepad only because I wanted infinite undo.

I forgot to mention that the bindings for nano (well, pico to be technical) are nice and simple, and the core set are all continuously displayed on screen in a help bar at the bottom

I do like it when the keys are displayed at the bottom. I always found it a huge time-saver in DOS programs.

But like with Notepad, any serious editing job is going to bog down very quickly using nano.

Perhaps more so; does nano have a selection feature? Shift-click and the CUA selection controls are a big help. Emacs's alt-space might be better still but it's been years since I used it.

em was a visual line editing extension to ed (editing one line at a time interactively, instead of taking commands and then requiring a separate print command to see their effect)...

Hence its name, em -- "editor for mortals". To be fair, QED / ed had to work on teletypes, where "interactive" had a bit different meaning.

Indeed. I can certainly understand the name. I spent about 2 weeks setting up a system with just ed and sam -d to try to get used to it. It wasn't impossible, but there was this constant feeling of medium-level stress whenever I was editing text. Not fun for long. It makes me wonder if I'm in the wrong hobby because it's basically working blind, and programming always involves some degree of working blind. Sam and the version of Ed I was using (Plan 9's) make it easier than normal to see the changes you've just made, but it was still stressful.

It turned out that most users were spending almost all their time in visual mode, so in 2 BSD, ex was hard-linked as "vi", and if invoked as vi, it would start up in visual mode.

You've got to love how much meaning is in those two-to-four-letter executable names (like grep, which is derived from the QED-command g/re/p which it effectively emulates: "global, <regular expression>, print").

Yes. There was a time when ls bothered me because it couldn't list everything. Plan 9 went a long way toward solving this, but not all the way... but as i realized when I tried to write something brief about it, that's another big topic on its own!