the most fast code to emulate vim's h/j/k/l behavior ?

[Brendan]

Hi,

I completely agree with Schol-R-Lea here. You need to tone it down, Brendan. Seriously.

I express my opinions in a direct and honest manner. If you can't handle that you need to grow up, seriously.

Speaking your mind is not an excuse for unnecessary abrasiveness.

That's why I don't continue this discussion -- not because I don't think I could make interesting points for you and the general audience, but because you're talking down on people and do not even consider taking other people's view into consideration.

Which is a very poor thing to be said about a moderator.

Oh my, you've used the word "very" and now I'm all offended and I'm going to sit in the corner and cry for 6 hours while I blame everyone else for the fact that I'm a fragile whiny little baby...

If it really matters this much to you, I admit that Schol-R-LEA was right and I did spell "puss" wrong. I don't know why I've developed this habit, and will try to spell it correctly in future.

For clarification: All I have done is indicate that I am the sort of person that doesn't mind the idea of surrounding himself by "smart people that disagree". You (Solar) have grossly over-reacted to this. This is not my problem, it's your problem. If you don't not like that, that's also your problem. Reporting my post will not change you and will not change your problem.


Cheers,

Brendan

[glauxosdever]

Hi,


Would you rather both of you please stop fighting this way?

Let me acknowledge the points both of you make. Brendan, you sure have great ideas that could improve computing. Solar, you are right Brendan shouldn't be arrogant and abrasive.

Let me acknowledge the faults both of you make. Brendan, you, like Solar and Schol-R-LEA say, shouldn't be aggressive and, like I'll say now seeing your last post, you also shouldn't be overly sarcastic. Solar, you maybe are influenced by how current tools handle various jobs and maybe cannot consider anything different. But perhaps I'm mistaken about this, I don't know, thus the "maybe" in there.

Either way, let's return to civilised discussing?


Regards,
glauxosdever

[Schol-R-LEA]

I will note that Brendan's comments about UI and UX are, if not entirely valid, ones worth discussing; the hand movement one in particular should be addressed, but not for the reason he seems to expect*. However, this probably should have it's own thread, or even it's own sub-forum.

Also, I only mentioned vim because that was what the OP mentioned; I have never thought it was particularly good myself. I do have a love/hate relationship with Emacs, however, with plenty of abusive co-dependency.


* The idea that keyboard controls are faster than mouse controls for experienced users, in particular, is an illusion, albeit one borne of basic neuroanatomy. GOMS studies consistently show that using a mouse for even repetitive actions is faster than keyboard controls, even for expets. This is because they require less time to think about the action taken; but the mental activity needed to choose keyboard action fills time whereas moving the mouse is time spent with much less thinking, skewing the perception of time passing. The time needed to choose a keyboard command that isn't a repeated action is generally longer than the time to grab the mouse, find the appropriate menu item or icon, and return your hands to the home row of the keyboard.

[Solar]

One of these days I'll whip up a YT video showcasing some of the things I routinely do with Vim, nine-to-five, that you won't be doing anytime soon with a mouse.

But that's a pointless discussion, really, that's about as old as software: Something that has a steep learning curve is often only really appreciated by those beyond the learning curve, who have experienced the workflow-as-intended, and even if showcasing it to someone on the other side of the learning curve, he'll usually say "yes but it certainly took you a long time learning that".

Both sides are correct, but sometimes the learning curve is worth it, and sometimes it isn't, and it entirely depends on what you're doing.

To make a point, I am a maintenance system coder. I spend virtually all my time poking around in server / backend code written by other people, cleaning up, finding out, refactoring, that kind of stuff. I wouldn't want to do that in any other editor than Vim, because {reasons}.

Someone who expects to do new development all day in a given project, possibly including setting up a GUI for the software as well, he'll probably benefit from an IDE more than from the advanced features of Vim.

Chose the right tool for your job, but don't bash on tools that aren't the right ones for your job, because they might be just what somebody else needs.

[Schol-R-LEA]

Well, that is sort of my point, though. You may think vim is faster (just as I might feel that Emacs ke6board controls are faster), but if you measure the time out, it is actually slower. A lot slower. Regardless of skill or experience. This borne out by hundreds of experiments involving thousands of people, many of them programmers who have used vi or Emacs or whichever keyboard based tool for a decade or more. They were all faster with the mouse, regardless of their time using one over the other.

The reason for this disconnect is simple: with a keyboard, most of the time is spent on recall, followed by a very quick fingers action. Recall is slow, but active, so you feel as if it accomplishes more in that time.

Using a mouse, conversely, involves two mental actions that the human brain is very fast with - visual recognition and hand-eye coordination - and about three manual actions. Most of the time is spend waiting for your hand to move, so the largely unoccupied attention thinks is is very slow and tedious.

The structure and behavior of the brain itself becomes misleading. It is a temporal illusion, one our brains have as much trouble with as any of Escher's optical illusions.

OTOH, which is less fatiguing over long stretches of continuous use (3+ hours) is less clear, as is the relative risk of RSI.

[Solar]

Well, that is sort of my point, though. You may think vim is faster (just as I might feel that Emacs ke6board controls are faster), but if you measure the time out, it is actually slower. A lot slower. Regardless of skill or experience. This borne out by hundreds of experiments involving thousands of people...

Link one, I'm curious.

They were all faster with the mouse, regardless of their time using one over the other.

Faster doing what? Marking a line? Perhaps. Marking a paragraph? *Maybe*. Marking the next 5 paragraphs, or the next 10? I doubt that.

Renaming all occurrences of a particular string in the definition of a function currently under the cursor? Adding the source for a LaTeX table, with placeholders to fill in width, layout, and caption? Hm.

[Schol-R-LEA]

Well, that is sort of my point, though. You may think vim is faster (just as I might feel that Emacs ke6board controls are faster), but if you measure the time out, it is actually slower. A lot slower. Regardless of skill or experience. This borne out by hundreds of experiments involving thousands of people...

Link one, I'm curious.

I'll have to look some up. I will get on that ASAP.

They were all faster with the mouse, regardless of their time using one over the other.

Faster doing what?

Firing off a specific command. What that command does is beside the point.

Marking a line? Perhaps. Marking a paragraph? *Maybe*. Marking the next 5 paragraphs, or the next 10? I doubt that.

Renaming all occurrences of a particular string in the definition of a function currently under the cursor? Adding the source for a LaTeX table, with placeholders to fill in width, layout, and caption? Hm.

Yes, but there you are talking about command set design, editing mode design, and maybe scripting and the binding of scripts to commands. I know it sounds odd, but that's an orthogonal issue (mostly). It does highlight the big advantage of keyboard bindings, though, as having a hundred different keystroke and key chord combinations has a minimal cost compared to having an equal number of menu items.

We really should move this to a dedicated thread. The OP was talking about editing operations, not the specific application of them to text editors, and certainly not about editor UI We are way off topic now. I admit that I fouled things by discussing vim, my point about editing algorithms and data structures wasn't really isn't specific to text editors even if I made it seem so, sorry for that.

[Sik]

I'm subconsciously spending all the time determining whether it's faster to do something with keystrokes or by clicking and picking accordingly (and note that it's not just "how long it'd take" but also "how likely it's for me to make a mistake" and even how much of a slog the system is being at the moment). In practice neither is better because it depends entirely on the current context. Note that this is all in a fraction of a second.

And doing either of them regularly is going to destroy your hands. Find a better position =P

PS: by the way I can't stand vim controls. Being way too different from the norm is just asking for trouble. This is not even a case of whether the way vim works is better or not, it's a case of them having picked the wrong keystrokes to be used.

[Schol-R-LEA]

That's contexual too, though. When ed was designed, IBM's Common User Access standard was about 20 years in the future; for TECO, it was even longer. Since vi was originally just a whole-page editing front end for ed (and the same holds for Emacs vis a vis TECO), they couldn't know that most people would expect the CUA keybindings later on.

Of course, one might ask whether using the older keybindings makes sense more than 20 years after CUA became nigh-universal... which is why both vim and Gnu Emacs have alternate CUA binding maps in their default packages, though they both tend to collide with other bindings which don't get reset by those maps. Still, the fact that they don't default to the CUA bindings does tend to be off-putting to a lot of people who are trying them for the first time. And that's not even getting into what happens with those bindings when using a non-US keyboard map... (I understand that the default keymaps do have good key bindings for most international keyboard layouts, as far as that goes, but apparently the alt bindings are a mixed bag.)

[Schol-R-LEA]

Sorry for back-to-back posts again, but as with the last time, I thought that too much time had passed between updates.

I am, as I said earlier, looking into the specific studies which discuss the speed difference between mouse commands and keyboard commands (without reference to how much the individual commands accomplish, mind you). I will, however, point you towards two books I know discuss the topic: The Design of Everyday Things by Donald A. Norman, and The Humane Interface by Jef Raskin. I will also point out this article by Bruce Tognazzini.

Now, some disclosure is in order to put those works in context. Norman is a psychologist specializing in human-machine interaction; his book is considered a classic, but in this context, his bias against text based command systems is notable. Also, I have not personally read the 2013 updated edition, so I don't know what was added or removed since the 1988 edition.

Similarly, both Raskin and Tog are well-known as both PARC and Apple alumni. Raskin was the lead designer on the original Macintosh project (before Jobs took it over in a fit of office politics), and while he got pushed aside on it and much of his input ignored, he did have a major impact on the project. He was one of the early proponents of the (single-button) mouse, though curiously, his next big project, the Canon Cat (basically the Mac as he originally envisioned it) was not mouse-oriented and used a text interface and modified keyboard. He remained an advocate for careful design for both mouse and keyboard interfaces until his death in 2005.

There will be more to come as I find it. However, I repeat that this probably should be Jeffed out to another thread.

EDIT: OK, I found a few, though the results aren't as unanimous as I had been led to believe by Tog and Raskin. I have not read these yet, so I don't know what conclusions they give.

• Categorization costs for hierarchical keyboard commands
• Hidden Costs of Graphical User Interfaces: Failure to Make the Transition from Menus and Icon Toolbars to Keyboard Shortcuts
• Comparison of Mouse and Keyboard Efficiency

[Schol-R-LEA]

Yeah, another sequential post, but I wanted to mention that I made a GH repo for the editor benchmarks. Pull requests and critical comments welcome.