Vim ergonomics

[StudlyCaps]

I have a question for the vim aficionados. Personally I'd use vim if it had mouse control, and context menus which facilitated discovery. These two things are, in my mind, the most important innovations in GUI design and the only things that are unambiguously better than anything that came before them.
Do you prefer to do without these, or do you not consider them to be important?
Also, has anyone experimented with adding these features to vim? My understanding is that vim is meant to be extended, so these seem pretty common sense things to add. I mean sure, maybe you couldn't use them on your teletype connected to a VAX mainframe, but considering I'd bet that 99.999% of developers today do all their work on an IBM pc based platform it doesn't seem like a big problem.

[klange]

I have a question for the vim aficionados. Personally I'd use vim if it had mouse control, and context menus which facilitated discovery. These two things are, in my mind, the most important innovations in GUI design and the only things that are unambiguously better than anything that came before them.
Do you prefer to do without these, or do you not consider them to be important?
Also, has anyone experimented with adding these features to vim? My understanding is that vim is meant to be extended, so these seem pretty common sense things to add. I mean sure, maybe you couldn't use them on your teletype connected to a VAX mainframe, but considering I'd bet that 99.999% of developers today do all their work on an IBM pc based platform it doesn't seem like a big problem.

Vim already has excellent mouse controls, and the GUIs all have menu interfaces.

[StudlyCaps]

Vim already has excellent mouse controls, and the GUIs all have menu interfaces.

Are you referring to stuff like gvim?
I'm not having a go, I used vim exclusively about 7 years ago because the the PC I was using for work didn't run any kde application properly. Then when I moved to a new job we had to use eclipse (which I hated) now I use VS because I do Unity dev at work and VS on Windows is much better than Mono. I'm legitimately curious how others are using it though that it's better than newer IDEs.

Context menus - give Spacemacs a try!

Thanks! I've not seen that, but yeah my main problem with vim and emacs is that if I want to do something I haven't done before on (for example) VScode I can just look through the menus and usually find it, but with vim it's off to google!

[nullplan]

I have a question for the vim aficionados. Personally I'd use vim if it had mouse control, and context menus which facilitated discovery. These two things are, in my mind, the most important innovations in GUI design and the only things that are unambiguously better than anything that came before them.
Do you prefer to do without these, or do you not consider them to be important?

Given a decent terminal, even vim without the g has mouse support. Some editing tasks can be made very quickly with it: Left hand on n and dot, right hand on the mouse.

Context menus though, not very useful in vim. Discoverability is provided with the help command (e.g. look at ":h :set" to see all possible configure options). Or if you want something and know a similar command, the helps are going to be close by.

Also, has anyone experimented with adding these features to vim? My understanding is that vim is meant to be extended, so these seem pretty common sense things to add. I mean sure, maybe you couldn't use them on your teletype connected to a VAX mainframe, but considering I'd bet that 99.999% of developers today do all their work on an IBM pc based platform it doesn't seem like a big problem.

There are vim packages. For example, look at https://www.vim.org/scripts/script.php?script_id=1397. This improves on vim's ability to edit XML files. And I do think it would even work via teletype to a VAX mainframe.

Other than that, vim is plenty configurable already.

[Solar]

Personally I'd use vim if it had mouse control, and context menus which facilitated discovery. [...] Do you prefer to do without these, or do you not consider them to be important?

Vi(m) is working without menus, so having them would not "facilitate discovery", because you would not be using them in the first place. This is part of why Vi(m) has -- admittedly -- such a steep learning curve: You are not really "shown" what Vi(m) can do, unless you study the documentation, read relevant forums, or have a sensei teaching you the Art of Vi(m).

I do not, actually, disagree with the benefits of having menus, if they are good. Yes, you can "find out" what else a program could be doing for you. I certainly welcome them in a browser, and a graphics suite, and in many, many other applications: Those where you hold the mouse anyway.

But I think that there is a viable alternative(*) way when it comes to text editing, and that's the way Vi(m) has taken; stop using the mouse altogether.

This means your hands remain on the keyboard. Your eyes remain on the text you are editing. Your thought process does not get interrupted. And -- once you master the art of the macro -- all the operations you could be doing become trivially repeatable and programmable.

There are mouse controls available for Vi(m), via :set mouse=a, and of course there is gVim. But, on the whole, I think that going down that road is doing you a disservice, because you are trying to make one tool work like another, in a way it is not meant to be used. That's like... say, using C++ but in the way you'd be using Java. Going "new ..." every time you create a new object, and then complaining about how cumbersome C++ is with all those pointers flying around. The problem is not C++, but the fact that you are using it wrongly. Same for Vi(m) and mouse controls.

I've seen people creating elaborate mapping configs for Vi(m) to make it behave like "normal" editors, Ctrl-X and Ctrl-C and Ctrl-V and everything. That's just misuse of the tool. If you're looking for a "normal" editor, use a normal editor, trying to use Vi(m) that way will only bring you pain. Vi(m) needs to be embraced fully, or avoided.

That being said, I -- personally -- used Vi(m) without really "getting" it for a long time. I did neither love it nor hate it. It was a bit cumbersome, but it was available on every Unix server I connected to, so it was the go-to editor on Unix systems for me. Elsewhere, I much preferred GoldEd on the Amiga, and later UltraEdit on the PC after that -- "normal" Editors.

Then came a project that involved LaTeX source for a 500+ pages book, lots of reformatting, automated source generation via external tools, editing in various parts of the same source file, etc. etc.. And I went through many, many editors, generic ones with LaTeX capabilities and specialized ones, looking for one that actually helped me getting it done without getting in the way.

And without getting into details, Vim with the latexsuite plugin was eventually the one that "floated my boat". I learned so much about Vim in that time, and came to fully embrace it because I finally made all the little pieces connect that make working with it a joy instead of a burden. I now use it for everrything text-related. Even on my smartphone (through termux), as touchscreen "control" and text don't really mix.

And I absolutely understand the frustration that is Vi(m) before you reach that point where it suddenly all makes sense. I've started working on a tutorial to make it easier for others to "get there", but unfortunately I just don't have the time to make it happen.

Just, believe me, you do not want "mouse controls and context menus" when you're using Vi(m). Not having to lift your hands off the keyboard is the whole point of Vi(m).

---

(*) Note that I do not claim that Vi(m) is the end-all, be-all of text editors. There are good reasons why you might prefer a full-blown IDE, or write your text in some other app. All I am saying is that Vi(m) offers an alternative, that it works, that it is enjoyable to use if done correctly, and that it doesn't involve the mouse.

[StudlyCaps]

Vi(m) is working without menus, so having them would not "facilitate discovery", because you would not be using them in the first place. This is part of why Vi(m) has -- admittedly -- such a steep learning curve: You are not really "shown" what Vi(m) can do, unless you study the documentation, read relevant forums, or have a sensei teaching you the Art of Vi(m).

Thanks for this well thought out post, I've not seen the case for vim put so straight forward before, and I must admin it's pretty persuasive.

I'll be perfectly honest, I've never had a role where I found myself spending a lot of time typing. I would say that I probably write 100 lines of code for every 10k I read most days. Your post made me think of how I work in excel though, when I'm entering data; or when I'm writing or editing raw XML. Maybe I'm writing test cases for an automated harness or doing a budget or something.
In these cases I almost always find myself trying to find a workflow and set of controls where I am only using the keys, not the mouse. Every time I have to reach for the mouse when I'm filling out a long list of parameters, or populating a table, I am annoyed, it breaks my flow, it takes me out of the zone so to speak.
In this case I can totally understand the vim philosophy. If I have a set of operations which I can pretty much commit to muscle memory, and I am doing them time and again while also writing a lot, I can totally see how vim is the right tool for the job. I can also see the PoV where if you have already learned the basics of vim, then using it would be no slower than using any other text environment.

Honestly I think I've never had the right "job", so vim never seemed to be the right "tool". I guess I'll keep an open mind to it, or at least to the idea that GUI theory doesn't have the best answer to every problem.

[Combuster]

While sensei-tachi are admittedly the best training source, you can get some "quality" vim education right here.

[Solar]

For 25$? I'd rather people got a good book for that. Especially since I can't even tell what they teach in the paywalled levels (and what they leave out -- I don't expect they show you how to use multiple windows, buffers etc. just for example).

[Combuster]

I didn't expect people to pay for it either, but the demo is a nice gimmick and gets people started.

[Solar]

But it only gets to the point of "well, that's certainly not as comfortable as with my usual editor". All the things that make Vi(m) fly are either beyond that paywall, or not included.

Stuff like '" (jump to where you were when you last saved the file), '. (jump to where you were when you last edited the file) and '' (jump to where you were before the last jump). Stuff like :!myprog (send the marked text area as stdin to myprog, and replace it with the stdout of myprog). Or the why behind the many different "move" commands of Vi(m) -- when you are setting up a macro to do hundreds or thousands of similar edits, when you need that particular "move to the end of the word that's four words from where I am now, and then replace everything up to the next comma with <this>...".

You know what I mean. That "hjkl, and w and e and b..." is not even scratching the surface, and I am somewhat appalled that they think it's enough of a "revelation" to make people part with serious money. I consider this a scam, really.

[Schol-R-LEA]

If this is a battle one thinks needs to be fought - and I am not convinced that it is - then it would be better fought in its own thread, rather than one dedicated to light social interaction (such as listicle threads like this one).

I have no intention of asking others to change their preferred editor; that's the stuff of holy wars, as people get passionate about their preferred tools. But I do recommend that others refrain from evangelism as well.

I use Emacs, but you'll notice that I not only decline to promote it, I actively discourage others from learning it. The reasons I do this apply just as much to vim, IMAO. For most newcomers, it is a bad idea to learn anything other than basic CUA editors, period - indeed, when you are starting out, the fewer features an editor has, the better. It is too easy to confuse the details with the substance if you are struggling with the peculiarities of your IDE (which was one of the things which infuriated me about Eclipse - but that's my experience with it, not yours).

As I have said before, most usability tests indicate that mouse controls are faster than control key combos; they only seem slower because even an experienced user with muscle memory on their side spends up to three seconds trying to think through which key combination to use, a mindful task in which all the time feels occupied. Mouse actions are relatively mindless, but even with having to move your hand off of the keyboard and back, they are generally going to be less than half a second for an item that is immediately visible, as they leverage the visual and tactile faculties - and those are a lot faster than human memory is.

True, once you start using commands which aren't immediately visible - which for mouse actions usually means drilling down a series of menus to find a rarely-used command - things are slower, but it is just as taxing doing that in memory as it is on the screen. Hell, chances are that if the command is that obscure, you'll need to reference the documentation regardless of how you are accessing the commands.

And as I said, for most common uses, a plethora of complex commands is actually counter-productive. As much as I like Emacs, the truth is that the vast tapestry of ELisp code is almost always wasted, and for general use, a good action macro recorder beats either coded macros or special-purpose command scripts. This isn't to say scripting is a bad thing, as such, just that it tends to get used ineffectively - most of the really useful scripting stuff is for either creating a task-specific framework (i.e., using modes to turn a general-purpose editor into a special-purpose one), or for a one-shot operation which is so long and repetitive that it is faster to make a macro or script for it than do it by hand.

But in the end, this is still a 'you do you' sort of thing - trying to convince someone that their favorite editor is worse than another one is like trying to convince someone that their native language is worse than, say, English, or Latin, or Mandarin. It's an absurd proposition.

[Solar]

I admit that this has gone a bit OT; could I ask some moderator to carve out the Vi(m) discussion into a thread "Vim ergonomics"? I would actually like to talk about these a bit more, to find which parts of Vim "lore" are unknown to casual users, and might be worth showcasing a bit more in a Vim tutorial I am still considering to write up.

This post by StudlyCaps looks like a good cut-off point to me, with this post by pat and this post by glauxosdever on the "Remain" list.

Trying to give the stage back to the actual thread subject, "What IDEs are you using?".

[eekee]

When Oyy were a laad, we 'ad t' use V I, an' we 'ad t' LIKE it. We couldn' afford Emacs, didn' 'ave tha disk space. Emacs itself were free, bless ol' Richard, but we couln' afford tha disk space. So we used V I.

There weren't no mouse, neither. There were for other things, but not for V I, nor Emacs either, from wot I 'eard, 'nless all ya wanted were copy 'n paste. But that were in X, wot were a great big crashy thing we di'nt use much.

We used V I, an' we learned it from a BOOK. C'n you imagine that, you youngsters, learnin' it from a book? 'Ave you ever even seen a book? Doctor Linux it were called, and a great big book it were! Big as a phone book, and then some! Good book, that were, ol' Doctor Linux...

So, we used V I, an' we LIKED it. Din' 'ave no Gee Vim, not in those days! Not any o' yer Nano either, not that Nano's anythin' t' compare to V I, oy jus' 'ear people sayin' it.

We only 'ad V I. We din' call it Vim, tho it were Vim. We called it V I because that were wot it were s'posed t' be called. 'Sides, there were other V Is. Elvis were one, made by ol' Richard's folk, but we never saw it. Guess that's 'cause ever'one wanted to support th' U-gan-dan or-phans; Vim's author 'ad a thing about them, at th' time. 'S all right by me.

So we used Vim. It din' 'ave no backspace before tha start o' what ya were doin'. Ya told it tha region ya wanted t' modify, an' then ya modified that region. No stepping out o' bounds. It were same wi' tha auto-indent. Ya got yer indent and yer LIKED it, or ya pressed escape t' get rid o' it. That were it, that's how ya worked yer indent.

Ya know, I've 'eard, I've 'eard that Red 'At company, they still 'ave tha old V I! Tha old Vim. Can ye believe it? Tha old V I, from when I were a lad...

[nullplan]

I do get the distinct impression you are English. Dunno, must be the haircut.

And believe it or not, I did actually learn my first programming language (Pascal) from a series of books. Even went to the public library to get a few more. And that even though I'm one of them dreaded Millenials, born in the last months of the GDR (You all remember, right? The iron curtain, the Stasi, the bananas, or lack thereof...). But I can't remember how I found vim. Or learned after finding it. But I do believe an online tutorial or two were involved.

Also, you don't have to work at redhat to get the old vi. There's a project based on keeping it alive. Have a gander: http://ex-vi.sourceforge.net/. They are so old-school, they still use CVS for their source code distribution. (OK, the better joke to make would have been: They are so old school that most of the current british government was privately educated there.)

[eekee]

I do get the distinct impression you are English. Dunno, must be the haircut.

You are entirely correct there. Haircut and all... not really.

And believe it or not, I did actually learn my first programming language (Pascal) from a series of books. Even went to the public library to get a few more. And that even though I'm one of them dreaded Millenials, born in the last months of the GDR (You all remember, right? The iron curtain, the Stasi, the bananas, or lack thereof...). But I can't remember how I found vim. Or learned after finding it. But I do believe an online tutorial or two were involved.

I was joking about books. I actually intended to contrast them with videos, but that part didn't make the cut. I remember the iron curtain, yes.

In Soviet Russia, vim keys bind YOU! (Not sure if good joke. )

Also, you don't have to work at redhat to get the old vi. There's a project based on keeping it alive. Have a gander: http://ex-vi.sourceforge.net/. They are so old-school, they still use CVS for their source code distribution.

I wrote "Tha old Vim." Ex-vi wasn't available to me when I used "Tha old Vim." I used ex-vi for a few years when I wanted to escape vim's bloat, but then I decided to stop worrying about things that didn't affect me. Besides, Vim has very convenient extensions in gg { and }.

(OK, the better joke to make would have been: They are so old school that most of the current british government was privately educated there.)

hehe!