I wrote this mess, and didn't expect this to end up here. To clarify, I wrote the first section because polemics are fun, not because I am claiming to have discovered something radical. My imagined addressee is the kind of person who thinks that mice were a mistake, and keyboard-oriented terminal usage is the one and only truth. Partially a straw man, but a good enough approximation of some people I have met.
The main intention is to demonstrate how context-menu-mode works, how to extend it yourself and call for people to test it before Emacs 28 is released. Having written a few forgettable articles, I ended up forgetting that intentional provocation attracts unintentional attention.
> The denunciation of the mouse usually involves invoking concepts such as the “home row”, or the cumbersome migration of the hand between keyboard and mouse. These might all be well and good, if I were a typist and as such all I did was to type. But this isn’t the case, I ponder and perceive, more than I write.
This resonated so much with me :-) I still cannot believe how many people seem to think that the ability to type really fast is important to be a good coder, when we spend the vast majority of our time reading, re-reading and podering code instead of writing it.
I think it's not really the ability to type fast, or that you need to be typing all the time, but that when you're in a state of flow, where you have what you want to accomplish and put down on paper/screen clearly in mind, a context switch, even as one as small as from keyboard to mouse, might be slightly hurtful to that state.
When I'm in this state, I'm probably writing pseudo-code fairly close to the real language I'm working in, and not worrying too much about errors I'm not seeing, and just trying to quickly correct the errors I do see, such that I can express my intent on screen. Finding missed typos and other errors is for a second pass and with the help of a compiler/interpreter, for code I write in that manner. It may require some additional passes to tweak things that just don't work, as well, but that's fine. The point was to get what was very clearly in my mind transferred to another medium before something caused a corruption of my mental state.
That's not to say that's the only way I write. I also often devote time to carefully pondering what's on the screen and how to best interact with it to change it in the way I want, or whether there is a better way to do it entirely and that code should be rewritten. But when I'm trying to get what's in my mind onto the screen, little things like auto-indent and being able to accomplish something while keeping my hands doing what they've been doing all add up to help in small ways.
That's a valuable reason to have strong keyboard bindings. But there are many circumstances in which it is helpful and valuable to be in a state of float, observing your environment while allowing it to operate upon you until the merit of one direction clearly predominates over others.
This is how tiny bacteria with flagella operate; they whip their hairs furiously when they want to zoom towards or away from a particular stimulus, but tumble idly in intermediate zones. Having only one mode of operation isn't adaptive.
Definitely. There are advantages to both states, as they're optimized for different things. There are times for information gathering and eventually decision making, and there's times for acting on those decisions. While neither is generally a state of purely that type, there are reasons to believe that the optimal tools for one may not be the same as the optimal tools for another.
In that respect it's not whether keyboard binding or mouse context menues are better, it's about providing tools to support both contexts, so the appropriate one can be chosen at the appropriate time.
FWIW, UX research (perhaps in the 1980s) also suggested that while many people reported "feeling faster" with particular input/editing actions (compared to e.g. using a mouse), in some case the operations were no faster as observed, but they apparently involved enough cognitive load to produce a time blindness in the user.
TBH, my first reaction to this comment was "somebody's wrong on the Internet". But luckily, reflection won over reaction, and gave me enough pause to realize what's really happening.
I have no idea where this notion of "shunning the mouse" came from. The simple fact is that when you're "in the zone", the mouse gets in the way. After having read and re-read other peoples code, and occasionally also having read half a dozen research papers, you are finally ready to dump all the code that has been brewing in your head. At that point, you are a typist. All the for-loops and switch-cases and function calls are jostling around in your head, and you want to serialize them into source code as fast as you can. When you're doing that, forget the mouse even the arrow keys are too far away. All you want is "do what I mean" with "the thing at point". Everything else just disappears outside your region of focus.
So yeah, the mouse is awesome when you're browsing and reading code. But when you're typing code, the home row is the fastest way to get it all out.
> The simple fact is that when you're "in the zone", the mouse gets in the way.
On the other hand, I use the mouse a lot while coding and I would say you’re wrong here, for me. I prefer the ability to not have to think about memorized keys when coding.
I go into a state of flow based on what I believe is a combo between visualizing and imagining the code in an object form or something similar, so using a mouse is more natural since I’m still visualizing the mouse menu and the areas I have to click on instead of context switching into the mode where I try to remember keys I often look at the keyboard when typing, too, due to my way of flowing. I personally think it’s because my brain works a bit more visually and my imagination is pretty good, so I am able to map the imaginary code flow in my mind to the text version, so using a mouse to me is like navigating between the two. My mind takes the logic and is able to translate that to mouse movements easily to reach the part of the code I’m thinking about abstractly.
Personally, I’ve tried to be a better typist and tried to use emacs or vim, but I always go back to the way I do things and I’ve just decided my brain works a bit differently than many coders.
To each their own, I say; so do whatever works for you and I’ll keep using my way.
For me it's not going as fast as possible. The mouse just doesn't provide quick and accurate text navigation at the same time, and the arm moving between the mouse and the keyboard is just a nuisance. Same reason I roll with a tiling window manager. Why manually resize and position windows (and have some buried underneath others), when I can have a couple simple keyboard commands to accomplish certain layouts.
> The mouse just doesn't provide quick and accurate text navigation at the same time
It does both. And much faster than keyboard navigation if you're moving to a text at some distance away from where your cursor currently is. Mouse is literally a pointing device. If you need to go to a point in text 10 lines above your current cursor, moving the cursor there with a mouse is definitely faster than figuring out which of the ten arcane commands will get you there.
Maybe it's faster for you. For me, I can move to any line with Meta+G+G and the line number. That's faster than reaching for the mouse, aiming to the line, clicking, and returning to the keyboard to type, for me personally.
There are other shortcuts like Ctrl+Direction to skip chunks of text. Ctrl+Left or Ctrl+Right skips words and symbols, Ctrl+Up and Ctrl+Down, in some of my language configurations, skips to the next starting point of a code block in the same branch.
Movement is very straightforward with the keyboard, and depending on the editor, does not take long to get used to. If the mouse works for you, great. It did for me too, up to a point.
For me, it is usually that the keyboard affords more symbolic exploration. And that is usually more inline with my thinking.
A mouse can afford spacial exploration. Moving text from there to here, style thinking. Versus the keyboard of jump to there, copy text, jump back, paste.
Hard to see either as superior for text. Hard to see how to use the symbolic for spatial data. (Images and such)
For me it is not about the speed of typing or not breaking the flow.
But after experimenting with home row mods and (split) keyboards with multiple thumb keys, regular keyboard layout usage just feels terribly inefficient.
While fast typing is not a bad thing it is definitely not necessary skill of good coder. But coding and using the terminal requires frequently using special keys and combinations, which on regular keyboard require constantly moving hands to access hard to reach keys.
Using home row mods (with a special keyboard) the hands are almost resting.
I spent time typing in a setup with very dim ambient light (think of a photo room with dim red light). I still cannot touch-type, but after some time I discovered I can type in QWERTY on any keyboard layout.
I spend many hours of my professional life writing prose. Sending emails, code review, issues, typing in the group chat, documentation, design documents, tutorials, you name it.
When I'm writing prose, the speed I can type is the speed I can write. There are no downsides to being a competent touch typist. It's a bit much to say it makes me a better "coder" but there's no question it makes me better at my job.
I absolutely believe you and agree, there is no downside. My comment was about an existing (in my opinion wrong) perception in popular culture, were many aspirants get their ideas from, that being a good typist is somehow a requirement to being a good coder.
The title, both here on HN and on the article is missing an s. Currently, it reads as "Emacs 28' context menu", which implies that the context menu is 28 feet tall. It is probably meant as "Emacs 28's context menu".
For some reason I thought that you don't have to add a possessive "s" after 28 (in the same way you wouldn't after Emacs'). As I only use metric units, I would have never seen the "28 feet" thing. Thanks!
Was also expecting this to be about an absurdly over-populated menu, though if enough people act on the author's suggestions we might attain that goal.
I don't really buy the home row argument very much. I get why if you can touch type, that this is important to some extent, but mostly I think that when you start having to find and click on icons, or navigate menus, there's an interrupt in your cognitive flow.
Watching the graphic and motion graphics designers at work, they're dominant hand rarely leaves their mouse, while the other hand hammers at shortcut keys to switch tools. They don't care about the home row, just using the fewest actions to complete a task.
When I'm using a piece software maybe a few times a month, I'm grateful for icons and menus to help me remember how to do anything. When I use a piece of software on a daily basis, then I learn the shortcuts until it's muscle memory, an keep my hand away from the mouse as much as possible.
> the cumbersome migration of the hand between keyboard and mouse
This is one of the reasons I love the TrackPoint and use it exclusively. There is no physical context switching between mouse and keyboard. If you are a touch typist, it is always right there on the home row.
I am such a TrackPoint nut that on the rare occasions when I've had to work on a computer that is not a ThinkPad (a desktop or a different laptop), I use a ThinkPad wireless keyboard to give it a TrackPoint:
One job I had issued Dell laptops, and I found that I could put the ThinkPad keyboard right on top of the laptop keyboard. It even left the Dell's touchpad accessible. I do use two-finger touchpad scrolling once in a while.
Something I don't like about modern ThinkPad keyboards is that they took away the Menu key and replaced it with a PrtSc (screenshot) key. The Menu key is such a nice way to bring up a context menu based on the current keyboard cursor location (rather than the mouse position). These AutoHotkey rules fix that:
; Remap the PrtSc key:
; PrtSc -> Menu (like an old ThinkPad keyboard)
; Windows+PrtSc -> Screenshot of all monitors
; Windows+Alt+PrtSc -> Screenshot of current window
PrintScreen:: AppsKey
#PrintScreen:: PrintScreen
#!PrintScreen:: Send {Alt Down}{PrintScreen}{Alt Up}
This is for Windows, of course. I imagine there must be a way to do something similar on Linux.
Another tip for Windows users: if you have a keyboard with a numeric pad that you don't use much, enable MouseKeys in the Windows accessibility settings. This lets you use the numpad as a "keyboard mouse" for precise mouse movement. Or if you have a ThinkPad keyboard, try my JKLmouse program (another AutoHotkey script) which gives you MouseKeys-style mouse control using the IJKL or HJKL keys (and neighboring keys for diagonal movement). It will work on other laptop keyboards too, but you really want physical mouse buttons like a ThinkPad for it to be useful.
I don't think the argumentative tone was warranted. No one is suggesting that anyone be forced to use a mouse or that accessibility solely using the keyboard be limited in any way. But there is definitely the appearance of an aversion to the mouse in some a older (and things that want to seem old-school) Unix/Linux tools.
For _some_ people, the mouse is easier to use, so increases accessibility for _them_. I think the OP was implying that better mouse accessibility could be added on-top of the existing keyboard support.
This is a very good argument for making keyboard one of the devices that can be used for UI interaction. And, indeed, keyboard-navigable UI is a hard accessibility requirement for products that I work on.
But then there's this whole subculture in Unix that basically claims that keyboard should be the only device used for interaction. The software that they make makes it deliberately hard, or outright impossible, to use the mouse. And there's a cult following around this, based solely on the notion that it's somehow better in general.
Does your keyboard have a num pad? If so, then you're likely extending your arm to to far, bending your wrist at an odd angle, and relying on your shoulder to bear the weight of your arm when you use your mouse.
Thank you for your suggestion. This is certainly a contributing issue when it is the case that I'm using a keyboard with a numpad and a mouse together, but not the only one.
I use many different keyboards and pointing devices (not just mice) and the general trend I described holds true.
Disagree highly, the x11 select/middle click paste is the best way to copy/paste by far. To the point I start to get visibly upset when trying to copy and paste on windows. you would think ctrl+c ctrl+v is easy and simple, but it is infuriatingly slow compared to the x11 method.
To really throw gasoline on the mental fire, middle click on window usually puts you in some sort of stupid alternate scroll mode.
I don't like the select = copy idea. When I browsing, I'd like to select a few words for no reason (well, more like a hight light, or reminds me to focus on them). I just want to select it, not copy them at all. And mid click paste? Little hard to control somehow: looks the mouse easily move a little when I do so.
I'm also a compulsive highlighter, but fortunately x11 has distinct concepts between "primary selection" and "clipboard"
middle click is "query for the most recently selected thing and paste" while the clipboard requires an explicit copy action. In vim (even terminal vim) with X support they are the '"' (double quote) and '+' (plus sign) registers respectively. Most other applications let you copy and paste with CUA (or for terminals shift-modified CUA) keybindings.
So for something I plan on pasting longer term (or multiple times) I will typically use the clipboard. For quick "this thing needs to go here" with the mouse I use the primary selection.
I also agree that middle-click is nearly useless on a scrollwheel. Many mice have more than two buttons these days so you can always remap a function button though (as I mention in another thread, my trackball actually has 3 legit full-size top buttons, but prior to that I remapped the "browser forward" button to be middle).
I find I only use SELECTION if I'm going to paste whatever I copied immediately, but in those situations I do think it's a bit faster. If need to do anything else between copying and pasting I'll use CLIPBOARD instead.
I think this is the key insight. The old way makes selection a first class citizen of the windowing environment. If you view it not as copying, but taking advantage of the last selection, it makes a whole lot more sense.
This is not to say that explicit actions on the clipboard aren't useful. But, as an emacs user, I'm used to way more control over the kill ring than I typically see exercised on the clipboard.
For me it usually goes, select some text, try and paste, get a stupid scroll mode, try ctrl+v don't get what I want, go back to original document, select the text agian try and paste...
Eventually I remember to ctrl+c but it just flows so well, select then paste that it feels like a real step backwards going to a system that does not have it.
I do agree that the middle mouse button should be divorced from the scroll wheel.
I use the elecom EX-G trackball[1] for this reason. The default button mapping is middle-click on the scroll-wheel but it has 3 full-sized buttons on top as well and remapping is easy. There's nothing worse than middle-clicking to paste and having the scroll wheel scroll the screen slightly.
I prefer to just use a normal mice (In fact mine is not that normal because it is vertical). I'm on macOS and why bother to shop an old school one for rare usage? That's why I prefer the context menu too.
Sharing middle click between paste functionality and it's other popular functions makes it error prone and impractical at least for me. Copy paste is faster in a vacuum but the overall experience is worse. I think using thumb mouse buttons is more practical, and auto copy is better just avoided altogether.
Maybe that's why the "Un*x dogmatists" avoid adding functionality to mouse buttons. Middle click already has a great X11/Wayland feature and should stay that way.
I may have something on my clipboard already. I "compulsively" highlight things as a reading aid and it's frustrating when I lose trust in my clipboard because it always contains fragments of text I don't care about.
I'm somewhat sympathetic, but I'm not sure that "I want to be able to give the machine input without it reacting" is a great objection to doing something with that input.
> middle click on window usually puts you in some sort of stupid alternate scroll mode
It's just badly implemented there. Internet Explorer had a completely brain-dead implementation, and every embedded webview inherited that.
Firefox always had a very nice implementation of middle-click scroll. It may sound silly, but this one of the major reasons I always hated chromium-based browsers — they do have it, but it's not nearly as nice (you can't, or at least couldn't easily scroll inside scrollable elements, the acceleration profile feels very weird, and other small things like that).
I disagree when a trackpad enters the mix, because there are no clearly defined tap areas. I often copy a url, click in the navbar to select the current url, and paste in the copied url — and nothing happens! That's because I unintentionally middle-clicked the navbar, clobbering the clipboard with its contents.
Why? You can tap with three fingers for the middle click. It may not be the default, though. Even my ancient HP ProBook's abysmal touchpda supports this.
If you like tapping, one finger, two finger, and three finger taps seem pretty much equivalent. If you like buttons, clicking the left button, right button, or both buttons together seems about equivalent. What's awkward about any of this?
I can't remember the last time I had a mouse where middle-click wasn't really awkward to use. Probably in the time before scroll-wheels, when there was an actual middle button that was just a button.
Trying to click the mouse scroll-wheel is on par with the "push the joystick straight down" click mode that some modern game controllers have in awfulness.
I swear by the Logitech MX Anywhere 2. So much so that I recently hacked in usb-c support to my ancient ones.
It has a scroll wheel, which if you press down toggles between free-wheeling and line-by-line scrolling. It also has a physical middle mouse button just below the scroll wheel.
Originally in the 1990s when there were 3-button mice without scrollwheels, especially on Sparcs and whatnot, middle clicks were good.
But then mice standardised on scrollwheels and the middle button being the depression of the scrollwheel - and it's not so good anymore. It's way too easy to accidentally scroll when clicking a mouse wheel, and few people would disable the scroll wheel or get 90's type straight 3 button mouse.
The middle click in windows for "scroll mode" (or something) as you say, is useless. And I can only assume that's a mode that exists precisely because people without scrollwheels still need to scroll so it emulates the wheel. Poorly.
FWIW I agree when it comes to copy/paste, because there select/middle click is established. The context menu comes in handy for those operations that are just used seldom enough that you don't want to waste a single click on them, but often enough that you'd like to have an easy way to use it. For me these are mainly stuff like calling occur on a word, jumping to a reference, opening a dictionary definition, etc.
I'm in the middle of redoing my 5 yo config from the ground up for emacs'29 to take advantage of byte code compilation* -- and there's a lot happening in that accessibility of features space!
there are new better completion frameworks and new better ways of handling, thinking about and using key-maps .. so it look as if we're just one breakthrough away from having keymaps and menus attain some kind of parity with what M-x and M-: can deliver.
my emacs, being more of a computing environment than an editor, had 11 k org'd loc. I'm dumping that for small elisp files editable with outshine so i can nimbly add customizations to these menus and the other three dozen breakthrough (for me) packages that have appeared over the last few years.
The byte code compiler uses gccjit to compile elisp to elf files. That, in conjunction with the use of libjansson for json handling, makes emacs substantially, noticeably faster for lsp (language server protocol, which most editors at least have support for now).
If you haven't looked at lsp yet either, I'd highly recommend it. It provides a common set of language server apis so you can have a unified completion experience between languages. I can remember all the unpleasant tricks to getting jedi mode for python, meghanada for Java, and having to memorize two totally separate apis. This is so much nicer.
I only got into Emacs last year or so, but I’ve never used anything but company-mode. I’m also curious if this is what they are talking about or if there’s something else I’m missing.
They are talking about frameworks leveraging and extending the builtin Emacs completition mechanism [1]. The most well known ones are Ivy and Helm, I believe, but there are now many others.
I realized this after it was too late to edit my comment. Apparently a year of using Emacs is not enough to stop confusing “completion” and “auto-completion” in my head..
Which is kind of ironic given the UIs of traditional UNIXes like CDE, NEWS, OpenLook and NeXT, with keyboard shortcuts alongside three button mouse usage.
Somehow down the line the FOSS UNIX generation decided that the ways of twm were what one should aim for.
I guess there is some romanticism to work as on the early UNIX years.
There are some exceptions to this though, e.g. Window Maker (which is what i use) feels like everything is made primarily to be used via the GUI and using a mouse (it even has a WYSIWYG global menu editor where you work with it by drag and dropping items on it instead of editing text files like you'd find in the vast majority of window managers or providing some barebones tree editor with add/remove/etc buttons like you'd find in most DEs - and AFAIK it is the only WM or DE to provide a WYSIWYG theme editor).
I find it amazing that Window Maker is both among the most powerful window managers i've used and the most convenient and graphical (FVWM is probably more powerful but it certainly isn't as convenient to configure/set up).
It looks like NeXTSTEP but it isn't really following its concepts beyond those looks. I did use NeXTSTEP for a bit some time ago, after years of using Window Maker and NeXTSTEP's window management felt very primitive in comparison.
> Nowadays it seems mostly stable, to put it on a nicer way.
Sadly it has some bugs, though it is largely external stuff (RandR support was never implemented properly and is so broken that i don't think it is even compiled in by default, mouse settings do not work since it uses some old APIs, EWMH support is buggy/incomplete and some applications that assume it is always there have issues under it), but UI-wise it is stable (in that it doesn't try to reinvent itself - a 1997 screenshot of WM looks pretty much the same as a screenshot from a current PC, aside from increased resolutions, at least unless you are on a cheap laptop :-P).
I do try to fix some bugs myself and implement features whenever i get too annoyed by something though.
Used to be the dogmatist: "mouse is bad!"
Now I'm a pragmatist, do 90% of my work on a Thinkpad using keyboard shortcuts, but use the little red trackpoint mouse whenever it's more convenient. As long as I don't have to move my arms.
Yep ! The mouse isn't a mouse if it's on the home row. :)
Not enough people got behind the trackpoint in its day and it makes me sad that it's not the default mouse input for programmers.
If you want to be "that person" in your office, Unicomp makes buckling spring Model M keyboards, and they have one model with a trackpoint (the Endurapro). Looks like it's out of stock until sometime next year due to tooling issues though.
> When debugging code or studying a program, it is quite comfortable to depend on only one hand, and have the other free to scribble or relax.
I wonder if the OP is ambidextrous? If using the mouse gave me a hand free to scribble some notes, I'd be a much more enthusiastic mouse user. Alas, both writing and mousing require my right hand, and there aren't many good uses for my left.
It's easier to train your non-dominant hand to mouse than to write.
It's awkward initially, but for most people takes only a few days to be comfortable with it. Then they switch back and forth easily (I do it several times a day).
As an analogy, a lot of people (including me) started writing on a keyboard with only one hand (or at least hitting most buttons with one hand). We had to train our brains to use both. That was a lot more challenging than learning to mouse with the other hand.
I tried to train myself to become ambidextrous at one point.
I failed, but in the process, I learned a few interesting things - one of which was that it was far easier for me to train myself to competently use my left hand for mousing than for writing.
This might be the case for you, too - try using your left hand to mouse for a day or two and see if you can get the hang of it.
EXACTLY! I just came back to add this observation. I started to code at 14.
At 20 i was consulting and ran across my first system with a mouse. I quickly realized that there was no profit in using it with my right hand since that was needed for numpad and shift selects etc.
So I moved the mouse to the left and never looked back. My hand just goes there when it makes sense -- never breaking my focus or the close-contact my right has with the keyboard. That has made this entire discussion about mouse good/bad a non-issue.
It may take some time to train yourself if you're not a puppy anymore, but its worth stepping out of that argument and into something else.
"for crying out loud", "they even moved the f-keys to the top row so that you can have the mouse on the left of your keyboard!" /<smiles>
(p.s. op .. at 36 i learned to play the conga and that allowed me to go crazy with the ambidexterity like nothing else, ever. just buy a set and give it a go!)
I'm left handed and use the right hand for the mouse. I can also use it just fine with the left hand but see no benefit. And yeah, writing is a different story entirely, although as another bizarre anecdote, I can write text on the chalkboard pretty much equally as well with my left and right.
I often find when I'm not actively writing code and am just scrolling up and down reading, it's nice to just pick the mouse up off the table and sit or stand with my arm and hand in a more neutral position, with my finger somewhere near the scroll-wheel/surface. I'll sometimes even switch it over to my left and give my right a break.
But also, as a left-handed person I still use my right for the mouse when using it more actively, so I could scribble thoughts simultaneously with my left if I wanted to. I think I might have only done that like, once.
I'd imagine you can use a keyboard shortcut as well to open this menu, but based on the text cursor, rather than the mouse one.
I do this a lot is vscode to auto-fix issues and automatically add imports for the identifier under the caret. It's however frustrating in that it sometimes uses the underlying platform's dropdown widget, which doesn't respect my key bindings (Emacs-like, using C-p, C-n for up, down etc).
The best UIs IMO tend to be those that allow operation with the left hand on the keyboard home row, and the right hand on the mouse. Keyboard shortcuts should be preferentially towards the left side of the keyboard. Quite a bit of CAD & graphics software works this way.
Keyboard-only is decent for text, and particularly good for text where everything that needs to be edited will be on the screen at the same time.
I switched to using the mouse with my left hand because of this. One day in the middle of a long coding session I noticed I was moving my right hand back and forth a lot between the keyboard and the mouse, so I picked up the mouse, moved it to the other side of the keyboard, and started using it that way (still in right-hand configuration). I've been using it that way for over 30 years now.
Because I kept the mouse in right-hand configuration, I can use any mouse with my left hand without having to switch the buttons, and I can also still use the mouse right-handed.
I call this model the "MOBA interaction model", because in those games (which include League, Smite, and Dota) you must place do exactly this.
I, too, wish that more interfaces worked this way - but there's a fundamental problem, which is that many tools (including all Unix ones) are more efficient when you can input text, which necessitates the use of both hands on the keyboard.
Not quite the case, thankfully. I'm left handed and greatly benefit from this style of keyboard layout. I tend to notice that I'm more finger-agile with my left hand, which helps with quickly chained left hand shortcuts (C-z/x/c/v/a/s/tab, M-x, anything with shift or windows) and WASD movement.
As for the right, as some other commenters have noted it really isn't that bad to use your non-dominant hand with a mouse. Most of the movement precision comes from the wrist and elbow, rather than finer finger control.
Has anyone ever used blackbox or open/fluxbox? The context menu can be very amazing and minimalistic. I don’t use those DEs today, but they did change my mind in terms of what is needed in a desktop for effective interaction.
You say that but the 28 foot context menu with every possible action from every application in Windows' File Explorer (and in file selection dialogs) is the thing I miss in Linux.
I was hoping someone had made a context menu that is 28 feet long when you scroll through all the options. Sadly, no such hilarity presented itself. :)
If hands-on-keyboard-and-mouse (HOKAM?) is important, I would suggest looking at the digital content creation apps like Blender and Maya context menus and pie menus for inspiration.
I know with my use of Emacs, I'd probably use or configure it like a fancy which-key: use the mouse to navigate / filter the available choices but then use the keyboard for final selection.
The #1 reason to use a mouse for me is to do input you can't easily do any other way. The first is hover info for things that are't anywhere near the cursor. I don't want to move the cursor in order to hover an identifier 20 lines and 40 columns away. Because once I have hovered it for info, I still have the cursor in the right spot.
BUT, that I can also do with a trackpoint/ball/roller/whatever. The most important mouse thing is for freehand input like drawing. It's just not ergonomical to do that kind of thing with a trackball.
Using any kind of pointer to move a cursor in text or navigating to a different window or a different textbox isn't really a good idea. That's done better with a keyboard. But the thing most keyboard purists overlook is the thing they don't do at all (draw, hover), so they don't miss it.
Hahaha, like you are some sort of brave free-thinker for using the mouse! There are tons of reasons for preferring the keyboard, one of which is to alleviate the hand and shoulder pains resulting from pointing and clicking with a mouse for 35 years ... Go into any work place where people work with mouse-heavy applications all day, and count the number of employees who have had to resort to special solutions, like trackballs, trackpoints or roller-bars. I'm not saying you can't get pains from a keyboard---not least from Emacs unless you switch capslock and ctrl. But the intro to this article is kinda silly I think. It's not a statement to use the keyboard, and you certainly aren't a rebel if you don't.
I've been using Linux, traditional Unix editors like vim and emacs, and other keyboard-driven tools for the past decade with very little mouse use, and I'm starting to get RSI as a result. Singling out mouse-use for this is a wild claim, especially because typing on a keyboard involves far more RSI-inducing motions (many tiny repetitive finger-motions) than using a mouse.
Also, the author is specifically speaking about "Unx dogmatists" (not programmers in general), where using the mouse absolutely does* make you a rebel.
> I've been using Linux, traditional Unix editors like vim and emacs, and other keyboard-driven tools for the past decade with very little mouse use, and I'm starting to get RSI as a result.
Eh - it's well known in my company where some jobs are mouse heavy and some are more keyboard heavy. Both camps get ergonomic pains, but it is more common with the mouse heavy folks.
Typing can affect hands, wrists and forearms. Mousing affects neck/shoulder/side more.
People who get it with typing tend to get it after extended use (years). People doing mouse heavy CAD work often get it quickly (1-2 years) unless they're aggressively trying to mitigate it.
Contrary to what I just said, I do think they are equally prone assuming equal usage. The reality is that a lot of programming jobs do not require a lot of continuous keyboard usage - you spend a fair amount of time thinking. It's why I get more ergonomic issues when typing emails or writing documentation than when programming.
Mouse heavy jobs, OTOH, often involve continual mouse use. So they automatically are more at risk.
What part of "I'm not saying you can't get pains from a keyboard" is unclear, would you say?
As you seem to have missed it, the author isn't positioning himself as a dogmatist using the mouse. He is calling Unix users who don't use the mouse dogmatists.
What part of my comment implies that I didn't read "I'm not saying you can't get pains from a keyboard"? Answer: none of it. Perhaps you should read more carefully yourself before accusing others of not doing so.
> the author isn't positioning himself as a dogmatist using the mouse
I never said that he did.
> He is calling Unix users who don't use the mouse dogmatists
He is not. The actual article reads:
"It seems as though an irrational fear of the mouse dominates amongst Un*x dogmatists".
This observation also isn't relevant to my comment, so I'm not sure why you're bringing it up.
My point stands - you absolutely are a rebel among Unix-users to use the mouse.
Your mocking statements like "Hahaha, like you are some sort of brave free-thinker for using the mouse!" don't do anything to improve your arguments that are mostly lacking in support.
> As you seem to have missed it, the author isn't positioning himself as a dogmatist using the mouse. He is calling Unix users who don't use the mouse dogmatists.
Not quite, I want to say is there are Unix dogmatists, that don't use the mouse because of what they think the right way to use a Unix-like system is, not that preferring to use a mouse or not makes you a (Unix) dogmatist.
Oh, come on, did you mean to be polemic or not? :) I think it's a hard sell to claim that the article was actually directed at a small, perhaps barely existent, group of Unix users who seem to be either afraid of the mouse (!) or proud not to use it.
I'll rather accept what you said earlier in this thread (the "I wrote this mess ..." post): that you simply meant to be provocative. That's OK in my book, even when it doesn't turn out all that great. Nothing wrong with the rest of the article, either.
> I think it's a hard sell to claim that the article was actually directed at a small, perhaps barely existent, group of Unix users who seem to be either afraid of the mouse (!) or proud not to use it.
Good thing then they never said the article was directed at that subset of Unixers. It was only that little provocative starting section that was.
Ah, I didn't think about it that way, and I understand what you mean, but yes, my polemics were directed at a very specific, rare kind of user that I used to associate with. The reason I call my article a mess is that I don't proof read anything I write, so I just assume there are mistakes all over the place.
My god, a mouse click which actually does something in a Terminal prompt! What a concept.
/s
But seriously though, if I could just ask for two things in emacs:
1. Enable mouse mode by default (Yes -- I love UNIX too, but this is ridiculous)
2. Give up on "yanking" and "killing" with only the keyboard and allow for text selection with the mouse. OP touches on this a bit, but why anyone should have to write their own functions to accomplish it is a bad sign.
Because I know I will get yelled at for this - especially #2 - is this limitation due to the fact that emacs (and I guess, vi) act like a pager with distinct modes of operation? And, yes I know GUI versions exist, but I shouldn't have to switch to something else just because the canonical implementation is incomplete.
I don't see why you wouldn't consider graphical Emacs to be the canonical implementation. It's part of the primary codebase, several features enabled by default rely on it, and it's what is started when you run emacs with no arguments.
> ...and it's what is started when you run emacs with no arguments.
Well, actually...
Not as of macOS 11 it isn't. Installing the latest version from Homebrew also presents a terminal interface - hence my questions re the available GUIs.
Similar to mpv, they make a distinction between Formulas and Casks.
Mouse selection works fine. At least if you use the gui. And, really, if you're using emacs in the terminal, you should consider switching, since it works much better in the gui.
This is a useful practical introduction to the new context menu functionality. Since power users rarely use the mouse or right click at all, I have found that context menus are a great space for making custom functionality accessible to semi-technical users on a file by file basis. Yes, this breaks all sorts of usability guidelines related to consistency. On the other hand if used judiciously it can save the user an enormous amount of time by giving the a single place to look for functionality that is relevant to them in a given context.
Oh absolutely, even as a 20+ year emacs user, if I don’t use a package on a daily basis I keep forgetting how it works. I’m looking at you clj-refactor.
Context menu is a great place for these things. If it’s not in line with how out emacs overlords thought things should work, they should provide a better solution for it.
The thing I love about emacs is how extensible it is.
The thing I hate about emacs is how extensible it is
Emacs was invented in 1976. You think it would be stable by now?
I filed a bug report for a sub-system I will not name because I think the developers are horrid people and the software fabulous, and I was abused, shouted at and called names for using an emacs distribution three years old (out of date they called it). That is I was using software that was forty four years old.
With the pace of development, any given bug or issue could have been fixed within the past few years- I do see your point about Emacs's stability and dev-additudes, which can stand on it's own, but I usually do try to replicate an issue on a clean install (minimal config needed to reproduce the issue) of the latest (released) version before filing a report. Dev time is as scarce as our own. Additionally, if the amount of configuration needed to reproduce your issue is prohibitive, that sounds like it might actually be an emacs-distribution issue?
I dont want to be too caught up in the cons. criticism- thanks for bringing it to someone's attention in the first place c:
I find it’s age awkward too. The terminology used (kill, buffer, window, etc) don’t fit at all with modern desktop terminology. Keyboard navigation doesn’t fit any modern standard either (cut/paste,etc) aside from linux terminals which have inherited it from eMacs.
I’ve tried to (with some success) standardise keyboard shortcuts across my entire desktop (linux w/windows vms) but im forever in keyboard he’ll.
In addition, I have awkward performance in emacs - character movement triggers a buffer save which occurs in the main thread resulting in a pretty constant lag.
Am I the only one that likes the emacs concept, hates lisp, and hates eMacs to the point where I think it should be rewritten?
> irrational fear of the mouse dominates amongst Un*x dogmatists. Be it because their tools don’t integrate, or because it is a symbol or rebellion, a means to differentiate their prior ignorance from the enlightenment they have attained
Or maybe we've learned something in the decades we've been working, since before you were actually born. Get off my lawn know-it-all college kid!
Having started UNIX on Xenix, followed by DG/UX with twm like window manager, and an heavy XEmacs user during its heyday, I agree with the know-it-all college kid.
What exactly do you agree? That I'm not allowed to like my keyboard focused setup? That I can't avoid the mouse as much as I want? That he should be sarcastic with people who like to work a certain away after working for longer that he has lived?
But that's the thing - the article author is talking about a context menu, which by default means that everything from the context menu can be done by keyboard means.
As for me, I'm another greybeard that doesn't need a mouse, but defaults to using it over a keyboard-only setup. Keyboard shortcuts are great for things that are frequently done, but I'd rather not spend the time to remember rarely-used features.
I'm relatively young, only 30, but I have the "privilege" to work on a variety of 90s-era windows-based systems. Everything is mouse-driven. When you have to use the mouse to navigate between multiple nested GUI pages, and each one has a couple seconds of load time, and the button to get to the next level is in another spot relatively to where the previous button you clicked was, it takes hours of your day just navigating between contexts over the course of an entire work day. People who think my fear/hatred of the mouse is irrational have never had to work on the irrational systems and terrible UX that the widescale prevalence mouse has enabled.
Your youthful innocence presumably shielded you from having had to work with the corresponding keyboard driven text menu systems that preceded these mouse based GUI systems. I assure you that they could be far less pleasant to use.
Granted, for any input modality, there are better and worse designs using it, but when designed properly, having an additional modality available can never be a disadvantage. When a newer modality replaces, rather than supplements, an older one, the benefits are often more debatable.
That's interesting, most of the accounts I've heard were that the text mode stuff was vastly superior, because once you knew the interface you could type ahead regardless of how slowly it actually loaded. Are you referring to the difficulty of picking things up in the first place, or am I unaware of some other difficulty that it had?
* Poor availability of navigation options other than linear order.
* Poor availability of editing / correction / undo (and conversely, there often was an easy to hit (deliberately or accidentally) button that would erase everything on the screen so you could start over. Users sometimes trained themselves to use that for any correction, because it WAS effectively superior to other available correction methods).
As an anecdote, in one job, I encountered a text based application for parts inventory management in a garage. The only way to look up parts was to type their full, exact name (And in our country, mechanics were not necessarily solid speakers of the local language).
The programmer didn't see a problem with this, arguing that his design promoted enhanced literacy among his users…
This is a false dichotomy. A GUI app can still provide full keyboard navigation - indeed, all the UX guidelines I can think of require it, and did so back in 90s. And when they do, you can also just type ahead, generally speaking.
In early 00s, I did a GUI (Windows Forms) line-of-business app for a shop that was using an old TUI app written in FoxPro for their other stuff. The people who were doing data entry on that were all using the keyboard pretty much all the time. When they started using the GUI app, they kept using the keyboard - and I didn't even have to do anything special to enable it, just make sure that tab-index is correct and that all widgets have hotkeys.
I'm sure GUIs can provide keyboard navigation and such, but it's not clear to me that this was common. Unfortunately, I'm working from anecdotes, so I can't tell, certainly not this far in the future, what the relative average quality was.
This was very common. For starters, pretty much every UI toolkit provided keyboard navigation between widgets with no need to do anything special. The common QoI problem there was that developers often didn't set tab-index correctly, so if you tabbed through the widgets, the order would be wrong (i.e. not following the screen layout). Visual designers often provided linters for that.
Then there were the shortcuts to immediately activate the specific label, button etc. On Windows, these showed up as underlined letters up until XP (in XP and later, you have to press Alt to see them). Again, as a QoI matter, devs could forget to put them in - but it was really easy to do, and if you didn't, the lack of underlining was actually kinda noticeable. Most apps had them.
Maybe it's because rat wrestling isn't nearly as efficient as it's made out to be, and not as efficient as a good keyboard command set anyway. Mouse-driven UIs are great for beginners who are afraid of computers to find commands. They're terrible for efficient workflows in the hands of seasoned workers because they insert a multi-step process of "acquire mouse with hand, acquire pointer on-screen, move pointer to target, click, optionally drag pointer to alternate target, etc." between you and whatever you want to do.
Mice (or pointers in general) are absolutely essential in some applications: drawing and painting, CAD, 3D modelling, etc. There also hasn't been a better flow for web browsing than simply clicking on links. But making the mouse supreme has added friction to workflows in fields from programming to simple data entry.
It's why I never could really get behind the Acme text editor, as cool as it is on principle.
You might try SmartGit. I use it on Linux and Windows and love it.
I especially appreciate the way it makes it easy and obvious how to do things that would be complicated on the Git command line. Some examples:
Committed to the wrong branch? Drag the branch markers where you want them.
Want to see a diff between the files in two commits, possibly on unrelated branches? Click one commit, Ctrl+click the other, and the file diffs are right there.
Lost a commit and now you have to trawl through the reflog? Turn on the "Recyclable commits" checkbox and all those reflog commits show up as normal commits, complete with diffing as noted above.
vim isn't even the same class of tool; vim is a text editor, emacs is a lisp environment that implemented text editing (in between an email client, web browser, git frontend, task tracker, ...). And I say that as a vim user.
In a lot of ways, GNU Emacs is the last life raft from the MIT AI Lab and its Lisp Machines.
I'd still love to see a Linux/SBCL Lisp Machine. I wonder to what extent such a thing is possible.
On another tangent, I'd love to see an Elisp compatibility package for Common Lisp, which would essentially be GNU Emacs with the C bits replaced with Common Lisp.
Isn't the whole point of a Lisp Machine that it's architecturally optimized for Lisp (rather than C, which is what underpins all of the modern Unix/Linux infrastructure)?
That’s my understanding too, which is why I wondered to what extent it’s possible. SBCL produces performant code so I am hopeful an efficient Lisp Machine could be built on x64 hardware.
The main intention is to demonstrate how context-menu-mode works, how to extend it yourself and call for people to test it before Emacs 28 is released. Having written a few forgettable articles, I ended up forgetting that intentional provocation attracts unintentional attention.