The more I learn about emacs the more I feel we took the wrong fork on road in terms of the desktop metaphor decades ago.
For someone not good with the keyboard, it's probably a nightmare. I suppose it's good for power users and terrible for casual users, and I don't know if there's any way to really build one user interface that works equally well for both, it's usually a compromise.
The next best thing I love about Emacs is that I can do anything conceivable with code. This one is an even larger gap between power users and casual users.
I think tools like that are just fated to only attract a select few.
(xterm-mouse-mode 1)
(global-set-key (kbd "<mouse-5>") 'scroll-up-command)
(global-set-key (kbd "<mouse-4>") 'scroll-down-command)
(global-set-key (kbd "<wheel-up>") 'scroll-up-command)
(global-set-key (kbd "<wheel-down>") 'scroll-down-command)I tried it for a while, after seeing my Eve Online friend skipping through tasks at a rate of knots without any mouse movement. My god the amount of tab pressing I had to do to get anything done was crippling. I might have to jump through 15 times to get to something that would take me less than a second to click.
Fundamentally the mouse is just a form of modal editing. Emacs supports this in spades of course, and god-mode is my modal input minor mode of choice, but clicking to jump to a position on screen can often be a lot faster than I search or avy-jump commands, say nothing about how much gentler on the wrist it is. Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
Then you have the biggest benefit of using the mouse: scrolling around reading code or text while having a drink or snack in the other hand. These days I use a trackball in my left hand. Regardless, the keyboard vs mouse thing always struck me as one of the many dumb flamewars that tech people engage in.
Certainly. I wouldn't argue that text editing speed is a relevant bottleneck in software development, actually. To me it's enjoyable and that's a big factor in my productivity, but that's just me.
My point was mainly that the keyboard (efficient use is difficult to learn) vs mouse (arguably easier to learn) is just one example of why the current desktop metaphor won over something I'd say is designed for heavy keyboard use (even if usable without it). The "code the entire environment" thing you mention is another example. Not sure I expressed that point all that well, rereading my comment it almost looks as if I'm trying to start a flame war :D
This comparison of the mouse and keyboard seems to have programmer tunnel vision. Anything involving layout, graphs, media editing (audio, video, image), 3D modeling, and drawing I think we can all agree are better served by the mouse (in tandem with the keyboard). It's really the mouse and keyboard together that's made the computer such a successful creative medium. Programming seems to me like a bit of anomaly in that it's one of the few creative tasks that doesn't benefit greatly from a mouse.
People with RSI from constantly reaching for a mouse.
I love emacs because I can do everything with the keyboard. It is faster and a lot easier on your body long term. My advice, start young. Keep your keyboard directly on your lap and use a ortholinear plank keyboard so your fingers don't have as far to travel. I was skeptical at first, but I will never go back.
I literally went to an orthopedic specialist recently for overuse of the left alt key causing me pretty notable pain in my thumb.
My primary mouse is a trackball one, because I have pain in my arm (elbow and shoulder) when I use a regular one on a desk.
I will maybe get a split keyboard in the future. But I did get a mechanical one because of key travel. And I touch type, so I spend less time on the keyboard itself.
I had RSI issues early in my career and this advice alone really helped. Never got the Emacs pinky/thumb. I recently switched to a MacOS and that is giving me thumb issues with the overuse of the Meta button. I now consciously have to force myself to use a different finger when pressing Meta.
Always remember: You have five fingers - no need to keep using the same one/two fingers to press Ctrl or Alt. It will take time getting your brain used to using other fingers for this purpose.
Oh, and yes: Definitely got lots of ergonomic pains due to mouse use. In fact, I changed my career from "regular" engineering to SW engineering partially to avoid having to use a mouse (e.g. CAD SW). And every ergonomist you'll meet will tell you "Memorize keyboard shortcuts and avoid the mouse as much as possible."
And because emacs is under socialized and under adopted the emacs user will still have to use notion or outlook or whatever corporate security requires.
There's no reason a program like Emacs couldn't exist which had something like capabilities baked in, but as it is, every package has access to anything it wants.
My few cents:
Pretty much every ergonomist will tell you that mouse use causes more ergonomic pains than keyboard use. They literally tell you to memorize as many keyboard shortcuts as possible.
> but clicking to jump to a position on screen can often be a lot faster than I search
It can be, but is it the norm? I have a distinct memory - over 15 years ago - of reading a blog post that recommended isearch to move the cursor and realizing how right it was. I suppose not everyone agrees.
> say nothing about how much gentler on the wrist it is
A bad mouse is as bad as bad posture on the keyboard. You only realize this once you're in pain. Not everyone reaches the point of pain.
> say nothing about how much gentler on the wrist it is
You should not be moving your wrist! Move your whole arm. Once again, one realizes this only when you're in pain. Not everyone reaches the point of pain.
> Then you can customize the menus and toolbar icons so you can be 1-2 clicks away from something that would otherwise require a chorded keypress or worse, an M-x command.
The same argument works for keyboard. If you're going the route of customizing the menu for particular commands, you can also customize the keyboard to minimize the keystrokes for those commands (e.g. via hydra).
Right but that's because their advice is tailored around the "average" computer usage, which is lots of mousing to click around in buried menus and hunting and pecking on the keyboard. RSI is just what it says: Repetitive Stress Injury. The best palliative for RSI is to stop repetitively stressing the same tendons and ligaments. So that means breaking up your keyboarding with some mousing. Alternating which finger and which hand you use. Getting up and stretching and taking breaks. Maybe using some dictation in lieu of using an input device.
If you're writing text, your mousing is mostly going to be scrolling, unlike doing something like CAD or design or illustration. In that context, the context of using emacs, mousing is fine.
And realistically, for my own RSI, exercise was the real solution. Rock climbing increased the blood flow to my wrists significantly. That's probably the only real solution to RSI.
https://sites.google.com/site/steveyegge2/effective-emacs
Get in the habit of using Ctrl-r (isearch-backward) and Ctrl-s (isearch-forward) for moving around in the document. Whenever you need to jump the cursor backward or forward more than about 5 lines, and you can see the target location, you should be using i-search.
To do it effectively, you don't necessarily need to search for the exact word where you want to put the cursor. Let your eye defocus slightly and take in the whole paragraph or region around the target point, and choose a word that looks reasonably unique or easy to type. Then i-search for it to navigate to it. You may need to hit Ctrl-r or Ctrl-s repeatedly if your anchor word turns out not to be unique. But Emacs will highlight all the matches, so if there are more than a couple of them, Ctrl-g out of the search and choose another anchor word.
It's difficult to overemphasize how powerful this technique is, once you've mastered it. Mastering it simply requires that you do it repeatedly until your fingers do it "automatically". Emacs eventually becomes like an extension of your body, and you'll be performing hundreds of different keystrokes and mini-techniques like this one without thinking about them. It's comparable to the hundreds of subtle techniques you acquire for driving a car well.
But generally, please if you believe this provide some kind of source.
you already could though, no? emacs didnt allow you to execute lisp for the first time
Is a bit like having a problem with "ls" and wondering if you could fix it by scanning the source real quick. In emacs, that is often just a keystroke away. In most systems, good luck.
A lot of people hate that, they want a tool that has all relevant to their tasks front and center, all irrelevant invisible or nonexistent, and zero options to tinker with. It should just work, and preferably never change.
A middle ground are the browsers that just work out of the box, but can be heavily customized by extensions. MS Office is another example.
It seems a curious attitude for a developer, though. My curiosity about how things work and the joy I get when I make a computer do the specific thing I want it to do for me are the reasons I program for a living.
But that's just culture, and quite easily moldable. Lots of people would also rather gamble watch smut all day, but we decided that it's not the best way to go about life... so we set up a system (school) to manage their learning process, and shepherds them for well over a decade, and then involves them in the economy and in society. Likewise we have cultural mechanisms which try to ensure that people learn essential skills related to nutrition, mobility, relationships, etc.
A lot of this has been eroding in recent years under the banner of convenience, and will likely have pernicious consequences in the coming decades. I posit that letting the insidious patterns broadly drive our approach to computing is similarly dangerous.
A lot of people don't even know how to use their tools properly. I remember when I was teaching a number of Perl courses to programmers, they where joking about me using emacs while they where using vi or vim.
But while I watched them while they did their exercises, I constantly heard the "bing" sound when the cursor hit the end of the line. Why? Because they pressed the cursor key and waited for the cursor to travel to the end of the line, then chynged to insert mode to append stuff.
Even I, a humble emacs user, knew that there was a vi command to jump to the end of the line and append.
Somehow in the same vein, some people prefer to write in C and tell the machine what exactly it must do, on a very low level, instead of picking an abstraction-rich language like Typescript or C++ or, well, a Lisp, where you typically operate in abstractions which you need to tweak to express your solution elegantly and correctly, but not very directly.
It gave me orange. I wanted lemon-lime. Another one swallowed my coins.
But to be pragmatic, many tasks need more than one thing to be done (I think most of us compose our e-mail in a program which sends said e-mail out as well, for example), so the inflexible tools can be insufficiently convenient at times.
Also, consider the humble scissors. They do one thing and do it well unless they're the wrong handedness. Try using a right-handed pair with your left hand, it's terribly unwieldy.
That is Emacs. You just have to drag the relevant up first and push down the irrelevant.
The thing is in Emacs, most utilities don’t want to presume how you would want some feature. Even if they do have defaults, they are suggestions at most. Instead of getting a tools that you have to learn and conform too, you get the template/idea/inital_version of a tool, and you make it your own
And there’s the whole idea of integrating stuff instead of isolated utilities.
I have a hope for the Common Lisp based Lem. All we need is to coordinate enough signal for potential users to feel it's the right time for their actions. Go star Lem https://github.com/lem-project/lem
I feel the same way about org mode. Nice. Can I use it on a team? Get real. I'd like more embedded data functionality in markdown. It's not XML, and that's good. Org is just weird. AFAIK it's still trying to figure out inline data embedding, so the embedding isn't even that strong. Doing something like exporting with a CSS class around a specific word probably uses some awkward literal syntax instead.
There are consequences to the monastic culture around Emacs. It's really good at holding itself in place. If you don't buy that tradeoff, you need to keep shopping.
I still can't believe we have IRC for grandma (slack) but not emacs for grandma.
People get tied up in the program-ability of it but it's UI and the concept of jettising both the desktop and tty paradigms.
Don't waste my time with 70s "ergonomics" (if it can even be called that)
The comparisons with art seem almost to the point of offense to me. You're not building art, you're just building another yet plugin for emacs to do what other people do in maybe 5% less efficient ways but won't spend 2 days automating it
The thing is that, there’s enough packages built-in and by third-party, you never really write your own. My whole config is pretty much setting options and linking packages together.
Emacs changes big O. It is not about changing constant factor. If you need N commands with M features then you can implement and combine them in emacs in O(N+M), to get O(N*M) custom commands.
For example, if you need “Search” feature then you can use it everywhere. It can help find you a file in Dired buffer. It can help you find a git chunk in magit. It can help you find todo item in Org mode, etc. It like having a separate `uniq` command instead of implementing it for each shell command (`sort -u` vs. `sort | uniq`). Another example, having `repeat <N> <cmd>` to repeat `<cmd>` command `<N>` times in zsh vs. implementing `<cmd> —repeat <N>` for each command.
The difference is linear vs. quadratic. If you need to do 1000 actions that can be decomposed into 100 commands with 10 features each then in emacs then you need to know and understand ~100 things vs. 1000 in less customizable environments.