I never really felt faster eliminating mouse from my coding workflow. Point and click to navigate things is pretty powerful. Why some devs try to avoid the mouse?
I’m always a bit disappointed that people making the case for mouse-lite workflows stop at “it makes you faster.” In many cases, this is patently false at a global scale - I’ve been using Emacs for a month and I’m certain that I’ve already spent way more hours customizing and researching than I’ll ever make back from saving a couple deciseconds every time I use a keyboard shortcut instead of a mouse.
For me, using Vim keybindings and Emacs shortcuts is valuable because reaching for a mouse or navigating menus adds mental overhead. I view the moment-to-moment practice of programming as largely being an exercise in working memory. You’re trying to hold an abstraction in your head and implement it in an existing codebase that’s filled with other abstractions and interacting parts. Personally, removing a mouse from my workflow does wonders for ensuring that all my mental resources are dedicated to the task at hand. Going mouse-lite might save a trivial amount of time in the moment, but (for me) it makes programming more seamless and natural - which makes it not only more fun, but more productive.
I agree. It's not so much "saving time" as when you are in a state of flow, you want to remove anything that slows you down from converting what's in your head to code.
I notice that when I am totally in the zone, I start to get frustrated quickly when tools take longer than normal or stop working correctly. You have a map of where you want to go and have the mental acuity to do it, but when tools get in your way, it takes you out of the flow.
To add to this, some shortcuts favorite to some users are used millions of times. Think of all that mental overhead that is saved in the long run.
I am a heavy user of shortcuts and a lot of the times I don't even know what the shortcut is, it's all muscle memory. Intent turns into an action and feedback is both tactile and visual and there is usually an easy way to get back of that also with shortcuts. Using the mouse in some scenarios is like looking through a keyhole. That is not to say that using the mouse is bad all the time, because the mouse beats shortcuts in other scenarios.
To me scrolling using the mouse scroll wheel or using keyboard keys are somewhat similar. Where the mouse workflow is eating the mental overhead is aiming a fly on a small landing 200th the size of the screen thousands of times or more daily.
Yeah, in a work year writing just 400 lines of code per day will net >100k lines of code in year. That's.. A lot of new code. Greenfield, best-case kind of scenario. Keyboard shortcuts aren't going to be the secret sauce to writing a measly 2k lines of code, much less 400. Just thinking about this and discussing it probably wastes more time than a lot of those shortcuts would ever save.
As long as somebody isn't being a huge detractor because they refuse to use the tools everybody else on the team does I don't really care. Not even enough to engage in a discussion about it. Unless there are beers.
For me, tracking the mouse cursor and moving it visually is harder than moving a text cursor, since with a text cursor I can generally look at a piece of text and summon the cursor directly to that location. I have trouble seeing and distinguishing the mouse cursor a lot, and I'm much more likely to overshoot it (or move it frustratingly slowly) than a text cursor.
It just feels better for me to use. I do less squinting. :)
I'm not sure if Emacs qualifies as an editor for saving time. As you say yourself, Emacs people tend to play a lot with customization (and Emacs didn't seem useful with default config to me; what the hack is C-x 2?). At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.
Try a text editor that does something for text editing, not scripting. Vim is an option. I personally used Kakoune with (almost) default config for some 3 years and I'm sure it saved me a lot of time. I never redefined default keys, they were good enough, I only added a few user mode bindings. (Although I felt a lack of some features over that time; Kakoune with no plugins is a bit too minimalistic.)
Recently I spent a few days setting up LSP and some useful plugins, now I'm going to forget about customization for few more months again.
> At the same time, it doesn't add anything useful to editing itself. It's basically scriptable MS Notepad.
I don't know, fill-paragraph (M-q), the sexp commands, transpose commands, upcase-downcase-capitalize commands, indent-rigidly are all built-in, bound by default and I use them a lot. And let's not forget Macros.
Vim provides a different, more efficient modal language for talking to the editor (which Kakoune further improves). Emacs on the other hand doesn't, it just gives you some ad-hoc shortcuts. Emacs's language is no different from the one of Notepad or VS Code. It's the language of insert mode + scripted shortcuts.
Shortcuts can improve your experience, yes, but not in such a fundamental way as a new model of editing.
UPD.
For example, the Emacs way of dealing with tables in markdown/latex is to have a custom plugin which will have a separate shortcut for each action one might want. As a consequence, you need to remember the keys for each of them.
Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Give me M-q any day over gqap (or, if you're inside a multiline comment, 3gqq; or, if you're inside a multiline comment starting on the same line as code, just giving up).
Edit: though I have to admit that I'm missing 'dt.', 'd/something', etc.
> 'd/something' is doable with C-s something RET C-w
Doesn't this need to be C-s something C-r RET C-w? Because C-s positions the cursor at the end of the search match.
What do you mean by ad-hoc? They seem to me be chosen and bound by default, because they are useful in practice.
> Kakoune, on the other hand, gives you a language that can express most of those operations naturally. And the language is no different than the one you use for other everyday tasks, no need to memorize new shortcuts.
Could you point me to some example?
And I am not sure if what you say about Emacs is necessarily true, you could have a minor mode that modifies the default keys to work with text tables. Org-mode's table implementation is a good example for that.
I mean that in Emacs you have one ready to use action for everything you might want to do. One shortcut covers exactly one use case; if you want more use cases covered, install plugins or write scripts. M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
In Vim-like editors you have some small atomic terms that you can combine to build the actions. You can have a small number of atomic terms, which can be combined in a multitude of ways and therefore cover a multitude of use cases. In Vim the gqap is not a single take it or leave it action, it's a sentence with verb gq and noun ap. If you want the verb to act on something different, you replace the ap part with something else.
Think of keybindings as a language you speak to your editor. In Vim the language has a number of words that you can combine to build sentences. In Emacs you have only a given number of ready to use sentences, and you have to memorize each one. This is a big distinction if we're talking about a text editor for efficiency, because it defines the ratio “time spent customizing” / “time saved editing”.
> Could you point me to some example?
You can cut and paste columns in Markdown tables using Kakoune's multiple selections. Like this:
- <a-i>p -- select the paragraph
- <a-s><a-;>; -- this creates a cursor at the beginning of each line
- <a-f>| -- move cursor to the next pipe symbol (selecting everything as it moves)
- <a-.> -- repeat the last move command (do this to select the column you want)
- d -- delete the selected (by each of the selection)
- <a-f>| (or <a-b>|) -- again to move cursors where you want to paste things
- p -- paste the deleted column
In this example, I haven't used a single command that I don't normally use while editing, say, Rust or Haskell. And you can manipulate Org, Latex tables with similar commands. In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Kakoune.org has more videos where they show what it can do (without plugins).
> M-q is an example, it formats the current paragraph. What if I want to format something other that a paragraph? In Emacs, you will need a new shortcut and a new keybinding for that.
You'd usually have a DWIM command, e.g. that it formats the region, but default to the paragraph if nothing else is selected. I have the feeling you are making this out to be a bigger difference than it actually is.
What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software. Emacs can steal anything that any other program does, and have it combined with it's existing strengths, like the ball of mud that it is. And even without emulation modes, there is inherently nothing in Emacs that is stopping it from using the same kind of sentence mentality you are talking about (and that I am familiar with, I have used both, but prefer Emacs).
> In Emacs, you'd need a separate plugin for each of these, wouldn't you?
Plugin is the wrong word, you mean package, but not necessarily. Emacs has syntactic commands, that can operate on a major-mode specific definition of expressions, sentences, top-level definitions (defuns).
To do what you did in your example, I'd just use macros, recording this sequence:
C-a M-SPC C-s | (repeat C-s to select the column you want) C-w (again move cursors where you want to paste things) M-w
and then repeat that for all the following lines. Multiple cursors are just visualized macros, after all.
M-spc just inserted a space for me. Do I need some package for it to work? What does your sequence of commands mean in English?
I have no doubt that what I've shows can be done in Emacs. How natural is it to express? How much scripting and packaging does it require? How much extra memorizing does it require?
> What I think is the mistake is that vim/kak are all just interfaces, while Emacs is software
Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default. Of course, you can script anything in it, but it's a meaningless argument; Linux kernel allows you to implement any program you want, but it doesn't make Linux a good text editor.
And in particular, I was talking about interfaces that are efficient, take little time to setup and save you a lot of time when you use them. My claim is that Emacs is not one of them. (Which doesn't make Emacs bad in the ultimate sense. It can be good for other things.)
> Multiple cursors are just visualized macros, after all.
Yes and no. Any text editing operation can expressed in ex commands, but it doesn't make ex a good editor, and definitely doesn't make it an efficient one.
Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
> What does your sequence of commands mean in English?
This time I tested it to make sure that I say the right bindings:
1. Go to the beginning of the line (C-a)
2. Find the n'th column (n * C-s |)
3. Activate the mark (C-SPC)
4. Go to the next column (C-s |)
5. Kill the region (C-w)
6. Go to the column you want (m * C-s/C-r |)
7. Insert the region (C-y)
> How natural is it to express?
To me it is instinctive.
> How much scripting and packaging does it require?
None, these are all basic commands.
> How much extra memorizing does it require?
All you need to know is how to record a macro.
> Yes, I am talking about interfaces, not software. I was talking about the interface that Emacs offers by default.
But then you are comparing different apples to oranges? But even if we are comparing vim/kak the interface to Emacs' default interface, I still don't think the difference is that big. The main difference is that vim/kak are parts of the terminal workflow, while Emacs is a shell onto itself.
> Multiple cursors give instant feedback, this is a big advantage over blindly shooting macros at your text.
You have instant feedback while recording a macro too? You can even make it interactive, and insert a query into your macros to make it easier for you to distinguish between false-positives and the actual places you want to apply macros.
I see the point. The Emacs way can also be seen as object-verb, it's just that object is given via selection. I don't have any objections to what you said, maybe I was wrong about Vim/Emacs difference.
But. Kakoune is still something bigger for me. It does take text editing to a new level and it does make it more efficient. It is similar to Emacs in the sense that both follow the sequence “select and apply an action”. But Kakoune has richer selection primitives and has actions that work on multiple selections at the same time; this can be done with macros, but it's by far less convenient.
In your example, you can record a macro and apply it to all the lines of a table. Will you have to do it for each line one by one? Can you say, “run the macro on each line of this paragraph”?
> You have instant feedback while recording a macro too?
Sure, but not on all the places where you're going to apply it at the same time. And your macro may not work correctly on some of the lines, you will not see it while recording it. With multiple selections you see it immediately and can undo the last action and try again.
Multiple selections stay there after you apply actions on them. After you apply something, you can see the result and slowly think of the thing to do next with them. With a macro, you will have to type in the whole sequence when you record the macro.
Macros can achieve the same things, but they require more mental effort and are harder to get used to. And when you're focused on your code, the mental effort it takes to used your editor matters.
In the same way, multiple selections are an improvement over Vim's tradition of shooting regexes at your text; for the same reasons: interactiveness and instant feedback.
Emacs and Vim are both equally efficient at text editing, I don't think you gave Emacs a fair shot. OTOH, VSCocde is frustrating to use if you are proficient at vim/emacs.
> Emacs people tend to play a lot with customization
I used to do that when I was young. Lots of elisp. Then I threw away a lot of customizations I didn't use anymore, added packages for the languages I'm using now and I think I ended up with a straightforward configuration.
There's a benefit to reduce stress on your hand in my experience too. Constantly switching from keyboard to mouse and back again, or even worse keyboard to trackpad, can really get aggravating after a while for some folks. I sometimes like a happy medium of VS code or other fancy editor with a VIM key mapping plugin.
Vim and neovim do not have support for multiple cursors. The vis editor, is a vim-like editor that does support multiple cursors (and also structural regular expressions, if that's your thing).
You've received so many replies already, but mine is different. The older I get, the less I want to deal with the video game-like elements of hand-eye coordination, intense visual attention, and timing. I'm tired of things going wrong because I clicked a few pixels off or clicked on the wrong thing because I was surprised by a UI element appearing in a slightly different place or with an unexpected delay or with slightly unexpected contents because of a software update or just something I didn't predict.
With keyboard commands, I don't have to verify the accuracy of my mouse movements, and I don't have to react to the timing, location, content, and focus changes of UI widgets. I just press the keys in the right order. It requires so much less vigilance, it's a big relief.
Surprise OS update popup with focus on "OK", you press enter at just the wrong moment and you're now rebooting. OK, that wouldn't happen as far as I know, but there have been plenty times where I was typing away, glancing over, and the focus had changed and now I'm typing into nothingness (or something worse like in my not too likely example). With the mouse at least I'm actually looking at the screen.
This. Using both (and touch as well sometimes), the right tool at the right time for the job at hand, is what is the fastest for me. Doesnt matter whether it's editing or browsing or ...
What do you mean with older FF? I've been using mouse gestures for decades (Opera anyone?) and I still use the same ones today on FF. Different extension/plugin of course, but works the way it should?
Agreed! I have a keyboard full of OS-level macros and I've rebound the extra buttons on my mouse to ctrl+c, ctrl+v, and enter. If I'm leaning back and browsing through docs, I want to be able to move text around and execute commands without reaching for the keyboard.
I found a nice solution to this with an MMO mouse. I have a Logitech G600 with 12 keys on the side and I mapped them to my most common operations like opening and closing tabs or moving between workspaces.
Most of the time you are using a browser, I can almost guarantee you’re not typing text. Likewise, but to a lesser extent, I bet most of your editor time is spent reading and doing minor tweaks instead of pure insert mode.
Automatic refactoring etc is still a long way off being good in Vim.
But I’ve recently started using a combination of Neovim + treesitter + LSPs, and have found it incredibly powerful. Extremely responsive automatic compilation that feels instantaneous, good inline error messages, very good and fast syntax highlighting through treesitter... At what it does, I’d go as far as saying as it achieves more than any other IDEs I’ve tried. But of course, what it does is more limited.
At the moment I rarely even touch a mouse. I work primarily in Vim, with DWM as a window manager and a Vim extension in the browser. When I have to work in a different environment and use a mouse again, I find the constant context switching very distracting
Just by following the instructions I had a pretty good setup already, but I made a couple of further changes, like setting up autoformatting on save, which was a bit trickier. `vim.lsp.buf.formatting` was useful there, but I had to do a bit of research to figure out how to use it (it wasn't immediately available on the READMEs).
This is a fair thought. It's why some wonder why people use Vim, emacs, or keyboard shortcuts in general...
However, one of my reasons is that I work out of coffee shops a lot. Not having to bring an extra piece of hardware that takes up space is a big deal for me and not taking my hands off the keys is a big deal.
I was a gamer (Counter-strike), and as precise as I believe my mouse-clicking to be, it is far less precise than the correct sequence of keystrokes to get to some parts...
Readline shortcuts available in most shells, i.e., ctrl-a (beginning of line), ctrl-e (end of line), meta-b (back a word), meta-f (forward a word).
In Vim - I can delete entire code-blocks with a quick sequence and have my cursor ready to type, and I can move chunks of code with their delimiters far more easily than my fairly precise mouse clicking and highlighting then moving my hand back to the keyboard to hit backspace. I can also switch to a "tab" (buffer in Vim) with a few keys without having to cycle through tabs or use a mouse to find the tab I'm looking for with a mouse.
There are many benefits, it's why even though text editors have come so far, people still continue to write Vim plugins for them -- think VS Code, Atom, and all the IDEs that Jetbrains produces...
That's my main issue with terminal emulators. Why can't I click anywhere to put a cursor in there? Why can't I delete a selected text? Some hotkeys work as expected (e.g. Ctrl+Delete), but others don't (e.g. Ctrl+Backspace). Those are simple things from a user standpoint. Terminal could be so much more usable. I'm not even talking about integrating real GUI into terminal, for example pressing Tab should open dropdown list, not emulate it with text.
You can use the mouse to select things in the terminal. In vim/neovim `:set mouse=a` and you can scroll around, select things and move the cursor just like you can in a regular GUI editor.
Thanks for this, you finally got me to look at the mouse options in vim, which I've always preferred off, as it's extremely annoying when using multiple windows and a click to focus window manager (like explorer, for the most part) when it places me somewhere else.
Now that I know how to enable it for specific modes, I'll definitely be using it for visual mode, and maybe insert mode (we'll see how much that annoys me). Now I'm off to see if I can get the mouse wheel to work at all times but click to place cursor off except when I want it, which would be ideal.
In DomTerm, you can click to move the cursor. This is simulated by converting the click to a series a arrow-keystrokes. If you set up "shell integration" (https://domterm.org/Shell-prompts.html) it just works with a regular click (for bash, fish, or zsh). Otherwise you can can do Alt-click (to avoid risk of mass confusion if you accidentally click outide an application that can handle arrow-key movement).
Deleting selected text works if you're in line-editing mode. It could be made to work in normal char mode, but it's a bit tricky.
Setting mouse-reporting by the application (emacs, vim, mc, etc) works pretty well, but it means the application has to simulate the selection (which may or may not be integrated with the desktop selection), context (right-click) menus, etc.
What causes RSI is mostly centered around tendon and their sheath tension.
For example, if you use a straight keyboard (don't! Ergonomic all the way!) that is raised toward you as opposed to away from you, keeping your hands on that keyboard for multiple hours in a row without ever reaching for the mouse is pretty much guaranteed to give you RSI. Reaching for the mouse will actually bring relief to your tendons.
Another keyboard habit that will put a great deal of stress on your hands and wrists is leaving the Control key at the bottom left of the keyboard. Typing a control key with this configuration will bring great stress on your pinky and other tendons in your hand.
This was 10 years ago, but I remember reading up and something with the forces enacted on your tendons moving the mouse around were exponentially worse than typing on a keyboard.
I use a touchpad when possible knowing that, but I've never double checked myself. Anecdotally, I've only developed RSI in my mouse hand from gaming (same story for my friends who game as well).
One point to add to all of the great points here is consider getting a smaller keyboard (or an ergodox) especially if you're on the smaller side (for the same reason as the last point, stretching less tends to be nicer on the tendons).
I'm not saying RSI in your wrists, that's mostly on straight keyboard (dacman all the way folks), but I personally had pretty bad RSI in my shoulder from the keyboard-mouse switching.
omg I realized this recently after using Android Studio for a short while. Keyboard+mouse workflow is objectively horrible for the wrists. Unfortunately no other alternatives exist for these IDEs.
Android Studio is based on the Jetbrains IDE, IntelliJ, and you don't need the mouse to do anything with them. If you don't know how, I recommend you watch some guides on https://blog.jetbrains.com/idea/category/tips-tricks/ or find some presentations on Youtube (after I watched one many years ago, I've been feeling like I have superpowers and can do anything with a couple of shortcuts).
Modal editors in particular can be a mixed bag, they do seem a little out of place in the world of IDEs and Visual Studio Code, but I'd be lying if I said I don't use them heavily. The main appeal for something like this is to keep your hands on the keyboard so you can focus on writing.
> Why some devs try to avoid the mouse?
Because a keyboard is a much better peripheral to use when you're SSHing into your server. A mouse also has a much higher latency ceiling to execute most commands because it requires much more spacial awareness and brainpower to perform the task than just invoking the keybind. When you move your mouse to hover over a "send" button on an email client, your body is performing subconscious inverse kinematics to try to figure out how far to push the mouse, and when to stop. You can then only click once your mouse successfully lands in the designated area, at which point an additional 50-500ms of latency will ensue, depending on what UI framework your text editor is based off of.
For me the appeal of Vim-type editors is that I do not need to learn new shortcuts when switching between Mac, Linux and Windows that I have to do at work periodically. This is a reason I use a Vim plugin with VS-Code with few custom keybindings to minimize the usage of Ctrl key.
Even though I'm a big admirer of keyboard-driven interfaces, I don't think mouse should be eliminated. Mouse can be better than keyboard for some tasks.
The problem I see is: a lot of things that non-modal, GUI interfaces use mouse for can be better done with a keyboard.
For example, all sorts of drop-down menus and icons that you click on to launch programs. This kind of interface is inherently synchronous: the computer suggests, you pick. To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has (sometimes those actually make me forget what I was trying to do in the first place). I love the related metaphor ESR came up with in his Unix Coans [1].
> To me, it's way more natural to asyncronously type in what I want without having my attention hijacked by whatever suggestions my machine has
Yes, especially when the suggestions change all the time, like when you go to click something and the icon is replaced by something completely different.
And a bunch more. I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
I don't know how fast you are with the mouse, but I've watched my co-workers jump into source and they can be so slow. I believe that I can answer questions I have regarding the codebase faster than they can, I don't have to rely on my memory for trivialities.
> I'd like to have an analogue to jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
If you use Xref UI for "Find References/Implementations/Type", M-, should work in those cases too.
There is a more general question: how to "jump forward" again, without re-invoking the previous navigation command with the exact arguments. IDEA, already mentioned in comments, has key bindings for that.
There are several third-party packages which attempt to solve it as well. I'm using this one:
Jumping "forward" is sort of built into Emacs with C-x C-SPC, pop-global-mark.
The objective and this command are fairly but not completely aligned, so it may require multiple presses of C-x C-SPC. To be clear, you only need to press C-SPC after the first invocation to repeat the command.
"sort of" and "not completely aligned" are just right: IMO, the mark navigation feature is just clunky/broken compared to the alternatives.
You don't want to iterate between the marks in the current buffer in a loop, or somehow keep track of whether each of the last three navigations changed the buffer or not (which would affect which one of the mark rings you'll have to use to go back or forward).
I don't find them particularly good. All these \C-x that emacs forces on you introduce extensive risks of RSI, especially if your Control key is still at the bottom left of your keyboard.
Better chords would be simple shortcuts for actions you do often (for example, "Go to symbol" in IDEA is \C-b).
I'm not sure there's a surefire way of jumping back with your C-x commands that's built into Emacs, but here are two options:
C-x C-SPC will pop the global mark which, depending on what you've done in the buffer you're visiting, can pop you right back to where you started, functioning as the equivalent of M-,.
C-x b RET (C-x b with no input) should take you back to the most recently used buffer, which will usually be the buffer you started from.
Not built in: It's also fairly trivial to write some defadvice that stores your point (pre-jump) to a register, so you can jump back to the register with one key.
> jump back with my C-x stuff like I do with M-. and M-, - any emacs people have suggestions on how to do that?
Using builtin commands, `C-x <left>` will switch to the previous buffer if you've jumped to another file, or `C-u C-SPC` (popping the mark) should work if you're in the same file. Not sure if this is sufficient for you, but it's a simple option to try.
Because we don't want to move the hand around. With keyboard-only solutions your wrist stays pretty much put. That's mechanically more fluid and faster.
Have you tried a MacBook with its trackpad right in front of the keyboard? I like keyboard-only too, but some jobs are faster when you can point at the screen
I have, and it's much better than a mouse, especially since I've got used to working the trackpad with my thumb.
But I still prefer keyboard shortcuts, they juste feel more natural while the hands are already in "typing mode". I feel like there's a question of "waiting around". Even though I've always found the mac trackpad to be very precise, even for quick movements, you still have to aim for an icon, move the cursor to it, click, etc.
Now in the particular case of a macbook, where the windows will probably be maximized or not move around a lot, you may get some kind of muscle memory. But you still have to look around for the icon, etc. Whereas a shortcut is always the same, you press the keys and you're done, it doesn't matter where your cursor and / or window happen to be. I also prefer hidden icon toolbars, this allows me to gain some vertical space.
But, as another commenter said, some actions are easier with the mouse and wouldn't throw mine away. In my case, that's web browsing.
I’ve tried the vi-like plug-ins for browsers that let you press a key then choose a link/button on the page by letter(s). I haven’t quite got ‘into’ them, however.
File management is also something that I find a lot easier with a pointing device. Also drawing diagrams, unsurprisingly!
"pointing at the screen" can be done a lot better, a number of different ways. My personal favorite is the Trackpoint, IBM's nifty little nipple that lets you use a joystick from the home row. You can actually type while using your mouse, and it's a a very jarring experience. Barring that, a touchscreen is also a great interface for quickly interacting with specific UI elements. I like Apple's trackpads, but the rest of their input peripherals are pretty terrible for ergonomics.
I've been a huge fan of the Trackpoint for many years, but unfortunately it's always been plagued by annoying drift issues, where the cursor keeps moving in one direction and you have to fight with it to make it stop. This has been an issue on older IBM ThinkPads as well as modern Lenovo models. It's a disgrace the technology hasn't improved much (at all?) in the last 20 years that this is still a recurring problem.
The trick is: as soon as you notice it drifting, take your finger off it and let it come to a stop. If you keep pushing opposite the drift it'll never stop.
Also, if you haven't in a while, replace your cap. I replace mine every year or so and it makes it perform much better. You don't have to push as hard, which also reduces the drift problem.
Yeah, I do this as well, but it's still annoying as it takes it a few seconds to stop. And then usually happens again soon after, so I often just force push it in the direction I want.
I don't replace the cap often, but I do take it out and clean it, blow out the dust, etc. I'll give a fresh cap a try soon, thanks. It's just ridiculous this highly disruptive behavior is still a thing after all these years...
There was also just shy of a dozen different Trackpoint designs, I don't doubt that one or two were seriously faulty, and I certainly have my preferences (the lower profile ones definitely don't track as well). In any case, the positioning and design of it is pretty ideal for people looking to reduce context switching at any cost.
I've not used a MacBook, but I've used laptops with trackpads. Either way, I'm a vim user, so I really don't have a reason to use the mouse for editing.
I don't get why you are being downvoted. A good trackpad under a keyboard (like on the Macbooks) is probably the (or at least, my) best input method. I would pay high price for a desktop keyboard with a qualitative touchpad right under the keyboard.
Indeed. If the challenge is to move to an arbitrary location visible on screen, then it’s logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts. Keyboard shortcuts can be more efficient in some specific cases of course (e.g. moving to the beginning of the next word, or something like that). But I see no point in memorizing the more obscure shortcuts when the trackpad works so efficiently and requires no thought or memorization.
The difference is that with a pointer device you need to control the input very carefully and precisely, which wastes time and brain cycles. A misclick could result in either maximizing or closing a window. Consecutive clicks can be interpreted differently depending on the configured period. Dragging and dropping is awkward, etc.
On any trackpad other than Apple's this becomes even more difficult. Gestures are nice but also require nuance and IME don't become part of muscle memory as quickly as keyboard use does.
Keyboard-driven workflows have no such issues. A keyboard shortcut is an immediate command to the computer to perform an action, and if that's something you do often, it will save you time and effort right away. You'll memorize it soon and forget about it since it will become part of muscle memory.
> If the challenge is to move to an arbitrary location visible on screen, then it’s logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts.
But moving "to a location on screen" is never a challenge worth using keyboard shortcuts for. If moving a cursor is your only UI option then a trackpad will be more efficient than doing the same with a keyboard of course. What you should do is use hotkeys to perform the action you would with a pointer so that you don't have to move it to begin with.
I’m not really sure what you’re getting at. I find my MacBook trackpad to be a fast and precise method of placing the cursor at an arbitrary location within a text buffer. Outside of certain special cases it is faster for this purpose than fiddling around with keyboard shortcuts. There should not be any significant mental overhead associated with using a pointer device if you are sufficiently practiced at it.
If trackpads don’t work well for you then don’t use them. I believe you, and have no interest in proving that your favored working methods are suboptimal. However, having tried the ‘keyboard first’ approach, I know that it is less efficient for me.
I do tire of the ritual haranguing of anyone who notes that they find the use of pointer devices an aid to their working efficiency.
I'm disagreeing with your assertion that "it's logically almost certain that a good trackpad is more efficient than any combination of keyboard shortcuts".
I thought you were talking about moving the cursor to a general area of the screen, not within the context of a text buffer, but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it. There are plugins like vim-easymotion[1] that make this faster, but I've found plain motion bindings to be efficient enough for me.
In any case, my intention wasn't to dismiss your personal preference, so apologies if it came out like that. At the end of the day we all have a specific workflow we prefer for whatever reason, and that's fine. I just objected to the general statement that a trackpad is more efficient.
As a developer, eventually, the raw task of "writing code" is really not where I feel losing time. Tbh, most of my time developing software is reading code and thinking about what needs to be written and "doing nothing" waiting for build/test to complete.
Fast switching between tools using touchpad gestures is more important to me than being able to type faster (but I acknowledge you can do both). As a sidenote, I absolutely love macOS fullscreen mode combined with 4 fingers swap. It's such a productivity marvel that I don't understand why Windows never copied it.
It's not so much about saving time for me as it is about avoiding the context switch. If I'm typing on the keyboard moving my hand away to the mouse or down in the case of a trackpad and then carefully positioning the cursor on the screen and clicking, is disruptive to my workflow when I just want to think about what I'm typing. For daily use I use a Trackpoint to at least avoid the hand movement, but moving the cursor around still takes me out of whatever I was doing to focus on the UI (in addition to the annoyingly persistent Trackpoint drift issue).
But I agree that Apple's touchpad gestures are awesome and from the few times I've tried it it worked much more reliably than on any other device. Still, I haven't found a more comfortable setup than a ThinkPad keyboard + Trackpoint. The insanely short key travel on Macbooks is unbearable to me.
>but there I still think using the keyboard for motion is more efficient once you build up the muscle memory for it.
I think a lot of people underestimate how fast a good trackpad can be with practice. I can move the pointer to an arbitrary location on screen in less time than it typically takes me to make a key chord. However long and hard I might train on Vim (and I did use it for ~10 years!) there's a hard limit on how much time that could save me when the trackpad is already so damn fast.
True, but it's much more precise than an analog pointing device sensitive to subtle movements, click timings, etc. Keyboard input can be trained and ingrained in muscle memory. Mouse movements always require focus to at least ensure you're clicking on the right UI element.
In my experience, a good work environment let's you go a really long way without even thinking of the mouse (or trackpad). So discussing which pointer device is most comfortable is sort of foreign to me. For context, I use shells and vim in tmux. If I don't need a web browser, I'll often not even start an X server (so no mouse at all).
Obviously it's possible to just use the keyboard if that's how you want to work.
The point is that using a good quality trackpad positioned below a keyboard doesn't actually require you to move your wrist much, if at all. With this set up, there is not really any cost associated with switching between the trackpad and the keyboard. Thus, there is really no benefit to using the keyboard for tasks which can also be accomplished efficiently using the trackpad (as you are not paying any significant penalty for switching between the two input methods). For example, I was able to move my mouse cursor to the 'update' button to submit this form faster than I would have been able to use the relevant keyboard shortcut.
I'd say that pointing is inherently slow because it involves checking where the cursor is, where the target is, moving it in that direction, then stopping at the right time. With a typical keyboard-based browser interface clicking the update button would have been a 2 key combination. Two discreet steps without any timing or measurement nuances.
I guess which is better for me doesn't have to be so for someone else. Mouse interfaces do have a certain simplicity to them.
You say that you hardly ever use the mouse. If you’re out of practice then you’d probably be slow at it.
On a good trackpad you don’t actually need much visual feedback because the response is very predictable. You can make a short movement and click more quickly than you can press a couple of keys.
Saka Key looks to be both slower and more complex than navigating using a trackpad (especially once you take scrolling into account).
With a pointer you treat the screen as a continuous space. With Saka Key's link clicking method (for the lack of a better term) you're selecting out of a discreet set of keys. I'm not sure what the implications are, but I feel like the difference is qualitative.
I would buy such a keyboard too. Or a touchscreen. I can raise my hand, touch the screen to place the cursor close to where I want and probably be faster than with a touchpad, surely much faster than with a mouse. Unfortunately I would have to clean my screen as often as my glasses.
I use the equivalent of "easy motion" aka "ace-jump" or "avy" under Emacs to move to any character on screen about 4 to 5 keypresses. Two to invoke that "jump to any character on screen" command, one to tell which character I want to jump to, then one or two depending on how many occurrences of that character there are on the screen.
I'll put it simply: my cursor is where I want it before you have even grabbed your mouse. And that is the reason why I avoid the mouse.
Same for "menus" and commands: shortcuts are faster than using the mouse. Once a list of potential candidates shows up, I use the same "select any candidate using the minimal possible amount of keypresses" command.
I have always used a "gaming" mouse, eg. high precision, high refresh rate and super smooth, with a mouse mat with just the right amount of friction. It however broke a few month ago and I got a cheap replacement, since then I have been subconsciously avoiding using the mouse, because the experience with the cheap replacement mouse is so bad. So I think the reason people don't like using the mouse is because they don't have a good mouse and mouse pad, and because they haven't spent years playing first person shooters - making it possible to hit a spot on the screen with pixel-precision using just muscle memory...
No... it's because it's just a LOT faster not to have to move your hand between the keyboard and the mouse.
Unless you are typing one handed then there is inherent inefficiency in using a mouse vs. a keyboard command. Example: ctrl/cmd+c ctrl+v vs right click copy/paste.
Context: I've competed at a high level in CS/Valorant and voltaic platinum... mouse accuracy is not my issue.
Once you achieve relative fluency with using a given text editor or IDE then it is natural to gravitate towards using keyboard shortcuts.
Eventually, if you type decently fast (70wpm+, though that's slow by my standards but I'm not here to boast about the size of my epeen) many will find it frustrating moving between keyboard and mouse constantly.
I don't find it's about speed, but rather about staying in the zone. vim enables very intricate navigation and editing that is much more tedious to pull off with a mouse. Since I have these commands memorized and very strong muscle memory, I just do them by instinct and my focus on what I'm doing never drifts.
I hate the analog-like nature of the mouse - having to move where you want, then slow down until you get to the right spot, then click, then click again because the cursor is a character or two off; and going through menus is a pain. And it's worse when you are hungover or tired. I just want a discrete and quick way to move around, and after using vim for a long time, it's not even a question that it's way faster and easier than a mouse. A mouse is a huge drag once you are strong with key bindings
IMO part of the reason is cultural. Computing became mainstream only after the mouse and GUI were invented, but programmers have been at it since well before that. So now it's somewhat of a badge of honor that you can be as productive without the newer conveniences. This apples to any new tools or processes like IDEs or linting as well. There was a very distinguished engineer at my company who chastised young engineers for using graphical step-through debugging.
In Plan 9's Acme, the mouse is your edit mode, the keyboard is your insert mode. I find I'm about as fast for most tasks in Acme as I was in Vim (after using it for years).
Using the mouse to highlight text in order to copy/paste it has always been a pain for me. Especially if the text is wider than the screen. I'm constantly highlight too much or too little. For me its way easier to use vim commands to grab the text I want. Its just one small example, but I can say for certain that I'm faster at editing text in vim than I ever was in a Jetbrains or VSCode editor.
Many editing operations involving the the mouse can be reduced to a few key strokes in Vim and become second nature. As an example, how many coders reach for the mouse when they cut text in "modern" editors? I don't think they need to be convinced Ctrl+X/Cmd+X is faster than the mouse.
There's no muscle memory in point & click, and it is a lot slower for a lot of things.
For instance, you wouldn't type on an on-screen keyboard with point & click. Once you've been using VIM for a while, pretty well any mouse interaction feels like doing just that.
I'm not familiar with Dota, but I'd guess that like other games whatever interface elements a player has to click are always in the same place and they're probably already having their hand on the mouse so know exactly where the cursor is.
Now compare this with an usual "desktop session", where you may have multiple windows which aren't always in the exact same place, the cursor moves around, maybe even hidden because you've been typing, etc. Now you have to spend some extra time to 1. locate the cursor, 2. locate the button to click, 3. move the mouse over. It will probably not be slow but it clearly takes you out of the flow compared to keeping your hands where they were and knowing that whatever your shortcut you have to press will do what you expect.
Point and click to navigate is pretty slow compared to keyboard driven approaches. Realized after switching to vim. Probably because, after certain point, it just the reflex which drives vim.
you wont know until you know. if two people can both use a mouse, but only one can do it all with the keyboard, you have to decide if they are being pretentious or if its actually better. i personally think its better for almost all code related tasks, but the mouse still has uses elsewhere
