Nice, but this doesn't go far enough imo. I love emacs but keep using Sublime on a daily basis because it has real, native[0] mouse handling and UI. My dream editor would be a Sublime UI on top of embedded emacs. That means:
- Native mouse selection of text, proper copy/paste, ideally with a "narrow caret" instead of block cursor everywhere
- Native graphical file tree with drag and drop
- Native tabs with pretty drag and drop
- Pixel-fine resizing of panes
- Pixel-fine scrolling!!
[0]: Everywhere I say "native" above, I don't really care if it's GTK or electron (provided it's snappy) or whatever. I mean the nebulous feeling of having text areas work like every other text area on my desktop.
VimR (https://github.com/qvacua/vimr) on mac was the closest to this I ever got, and I love that editor, but I'm not on macOS anymore.
edit: Oh g-----, I'm literally describing aquamacs. I wonder if anyone has tried to run it on linux with GNUstep or something ;__;
I don't see why software not having this is apparently acceptable. It's just disorienting to have line jumps. That's not how the real world works.
Modern Linux software is pretty good at it (GTK, Qt) as is much Windows software. However the only git GUI I otherwise enjoy using that has it is Sublime Merge.
I'm not sure this is true. Emacs is fundamentally command driven - everything is a command, and can be invoked, edited or replaced the same way. What triggers those is obviously key bindings for a lot of people but it's not really what makes Emacs powerful or extensible. People have diverse needs when it comes to wanting to interact with a computer, and it's great that Emacs's flexibility allows them to.
I agree. Vim is inherently keyboard-focused. That Emacs is not, and instead focuses on the command as the fundamental unit driving everything, is its primary strength.
This is what makes Emacs more flexible than Vim to the point where there's a very faithful reimplementation of Vim for Emacs. Couldn't do the opposite, even if you wanted to.
It is true that commands are at the heart of Emacs but as soon as you move beyond very basic use, invoking commands in ways other than through the keyboard becomes impractical. I'm not only talking about keyboard shortcuts but also about the fact that a lot of these commands actually take parameters that would be difficult to provide by mouse.
Emacs out of the box comes with a menu system. This is very good and useful for newcomers because it not only gives a familiar feel, it also helps discovering functionality. However, it is no coincidence that a lot of power-users turn off menu and toolbar, as evidenced e.g. by Steve Yegge's "effective emacs" tips (https://sites.google.com/site/steveyegge2/effective-emacs#it...). Now, not every user is a power-user, there is of course a spectrum, but to me it is fairly clear that the way Emacs is designed, mouse-based usage would be a limiting factor.
I too turn off the menu and toolbar in Emacs, and I'm not saying the setup in the article sounds good to me for that or any editor. But to give you an example of why I think it's an important point, I would absolutely love to be able to issue commands by speech, for example, for things I don't use very often, or just never remember what I've bound them to (or even for stuff I don't remember the name for). Some people _have_ this setup, I've just never invested the time. But it's possible because fundamentally Emacs is a platform first and an editor second. I doubt it would be a very popular platform without the ability to make keybindings, but you nevertheless you could still build useful apps on top of it, and I find that quite interesting.
There's still a difference though between a setup that uses keyboard + speech vs. one that mixes keyboard and mouse. For instance, you don't have to take your hands off the keyboard to issue a speech command. Also, there's a fundamental usability difference between voice input and mouse input in that the strength of menus+mouse lies in the fact that a user does not have to remember the exact command, it can be looked up / navigated to. For speech, you have to remember the command just as you do when using M-x <command> in Emacs right now -- unless you're thinking of a fully fledged spoken dialog system type of interface that would allow interactive descriptions.
I rarely remember commands when I’m typing, I use completion and apropos to remind me, feels like something similar must be possible. Either way, obviously I spend most of my life with hands on the keyboard and I’m not going to make out Emacs isn’t optimised in many ways for that. I just think it’s sad if someone thinks the big ideas in Emacs are just how it handles keybindings, that’s all really.
Yeah, that would be sad. Luckily, I'm not one of these people but at the same time, there's no denying that keyboard is the main modality most Emacs interactions are optimized for.
Your example of auto-completion is actually a good argument in favor of keyboard use since I cannot think of any other modality where a similar functionality could easily be implemented.
That said, I'm not arguing that keyboard-based interaction is per se superior to any other form of input. But to me, it's undeniable that Emacs is de facto a keyboard-centric editor. And let's not forget the history of the software: it was originally developed when terminal-based interaction was the norm, (wide-spread) use of mice came much later.
> a lot of these commands actually take parameters that would be difficult to provide by mouse.
Those that take interactive strings, maybe - but for those that take buffer positions or regions, which seems to me like a plurality if not majority, I would love to be able to invoke a command and then click+drag somewhere I want to apply, rather than having to set the point there and pop it back when done.
Or the other way around, select a region, right-click to get a choice of commands that work on regions - this could even be auto-generated by looking at the keymap stack for commands that work on regions.
> This is what makes Emacs more flexible than Vim to the point where there's a very faithful reimplementation of Vim for Emacs. Couldn't do the opposite, even if you wanted to.
This claim seems at least suspect to me. Vim scripting isn't fun, and vim certainly isn't centred around it like emacs is, but it's possible. Usually making this claim would challenge people to solve it themselves, but I suspect that vim users care significantly less about welcoming emacs users into their environment than vice versa.
(Also, the various vim implementations in emacs are almost-but-not-quite there, to the point that I believe really experienced vim users fall into an uncanny valley.)
Why not? Some things make a lot of sense, like the context menu. The current right-click behavior just sets the text selection mark. This doesn't make much sense anymore: every other editor uses click and drag to select text using the mouse. This frees the right mouse button, and a context menu makes lots of sense. Emacs is a highly complex software, which is then customized with lots of modes. Making functions accessible via a context menu would be awesome for both usability and productivity. The menus could be easily customized to further improve user workflows.
As for the rest: maybe some of the features are nice to have. I don't really care for tabs, and standard shortcuts are usually a non-issue, since everyone ends up using whatever they prefer ("standard", Emacs, or Vim). In any case, most advanced functions are usually accessed by name, whatever the editor.
The important takeaway is that every Emacs user should acknowledge the fact that the mouse is underutilized. We may not need it, but it's a huge barrier to overcome for new users.
Emacs of course has long supported menus but I think every serious user would agree that it's not necessarily a love child. I agree with you that it is the strength of menus in general that they allow for easy discoverability of functionality. However, at the same time, Emacs provides other ways to the same end.
Simple interfaces are especially useful for newcomers, I agree to that point as well. At the same time, most power-users of Emacs do not use the mouse at all. While not everyone aspires (or even should aspire) to become an Emacs power user, the question might be asked at what point it would be wise to switch from mouse-based use to keyboard-based use as you progress? Does it even make sense to first learn an interface you're better off ditching at some point as your expertise raises?
It makes complete sense to start using the mouse, and to keep improving our own workflows over time. Take the Mac interface: it's built in a way that allows users to just use the mouse, but everything is accessible via keyboard shortcuts. One of the key features of the Mac is the constant feedback the user gets, and the fact that this feedback is always the same, whether the user uses the keyboard or the mouse. Animations, selections, menu highlight when invoking actions... It's a very well-thought experience that makes things better for all kinds of users.
I use Emacs as my primary... everything. But I totally see the point and need for mouse-driven functionality. Emacs only works if you have two functioning arms with hands on them. Put a coffee, a sandwich, a cat, a kid, a beer... in one of your hands, and Emacs is unusable. If my cat wants some attention, I can't keep typin' stuff.
Though, not sure why the mouse-driven features are also wrapped up making shortcuts match VS-Code etc. That makes it a lot less useful.
If you can't type, I'm not sure the mouse is going to get you much ahead either ;-)
But it's true that there might be a certain class of users with impediments for which a different input modality setup could be very beneficial. However, note that standard Emacs already provides menus and mouse support, it's just not what is commonly the focus of the editor.
I was looking at a recent HN post about chording, and it struck me I'd have a hard time using a chording keyboard with Emacs. This might address that problem for me.
Emacs has thousands of shortcuts for every conceivable piece of functionality. Personally, I will remember shortcuts for commonly used things - and all the other functionality may as well not exist if it is not easily discoverable.
A gui is a nice way to make a lot of functionality discoverable.
> may as well not exist if it is not easily discoverable.
But it is easily discoverable ?
I literally just do M-x and can I get a buffer open with _all_ emacs commands and their explanation, and can do a fuzzy search on that, e.g., so if I type "M-x align re" I get only one command highlighted that can just execute "align-regexp".
That's the main thing I like about emacs. I don't have to remember a million shortcuts, just what things are possible, and then I just type a description of what I want to do and hit enter and that's it.
A GUI / having to use the mouse would push me completely out of "the zone".
That's cool if you can remember roughly what the command is called. For example, I wanted to format some XMl in a buffer. In a GUI, I'm fairly sure I could find this easily, in emacs it is "go to google" and find out that you want sgml-petty-print or whatever. So a bunch of M-x searching for "format" is hopeless.
Emacs tends to have its own names for many concepts, making things even more obtuse.
In about 70-80% of the cases, using ido or helm, with some guesses on what the command name may contain, is enough to find me what I need.
But yes, to be frank, my productivity in Emacs really took off once I started memorizing things with flashcards. I currently have 603 cards for Emacs (including elisp).
(And telling a newbie that would cause a lot of despair!)[2]
The other thing that really helped is I started using/making hydras.[1] So now when I encounter a new, interesting mode, instead of memorizing lots of command names or keybindings, I just build my own custom menus.
[2] But it really shouldn't. Emacs, with all its packages, and modes, is like a language with all its libraries, and not just the standard ones. Remembering all the commands/keybindings is akin to expecting someone to know all the APIs in all the libraries. It's OK if you don't. Most people don't.
> That's cool if you can remember roughly what the command is called.
>
> [ ... ]
>
> In a GUI, I'm fairly sure I could find this easily, in emacs it is "go to google" and find out that you want sgml-petty-print or whatever.
I just yank into a new buffer, set it to xml mode, "M-x indent" reveals the command to format xml (indent-region or indent-buffer or something like that), enter, yank it back. Done.
In an editor with a gui, I would just go to "Help -> Search" and do pretty much the same, which would reveal the menu item to click to achieve something. I find emacs ido/helm workflow for this much better. Never need to memorize anything.
Microsoft's office products are mostly GUI centered. But I rarely can easily find ways to accomplish things there and instead get lost in their GUI, which sometimes looks like a twisty maze of little passages all different. So "GUI" isn't a panacea for ease of use IMO.
In emacs I can use "apropos" (i.e. "c-h a") or "c-h v" for example to search for ways to accomplish what I'd like to do.
If you hit `C-h b` you get a list of all the current keybindings. `C-h m` lists the keybindings focused on the active modes. You can search either for the functionality or binding you're looking for. Also, `C-h k` followed by any keybinding will describe the keybinding. If you get the documentation of a function or command with `C-h f`, it'll also mention the keybindings it's bound to, if any. All these `C-h` help keybindings are described if you hit `C-h C-h`, and they're also mentioned in the tutorial that's linked to when you start up emacs for the first time on default configuration.
These helps are also available in the GUI menu bar, for example Help > Describe > List Key Bindings, which also mentions the keybinding `C-h b` to the right of that.
Discovery of functionality is lacking, not the keybindings. Most of the time I want an answer to "how do I do...?" not "what happens if I press this key?", and even isearching the help buffer I have to guess did they suffix `at-point` or not? did they call it `swap` or `transpose`? `forward` or `next`? did they make a `sexp` do something useful in this mode, or will it just pick something between parens, or some awful mix of the two?
Emacs suffers somewhat here for its ancient-ish heritage, because it was conceived and developed in the depths of university computer lab precursors, when people had different names for everything.
Try explaining "yank-pop" to somebody who's only ever used sublime/vscode.
Yes, a GUI allows you to give richer contextual feedback without introducing modality to the core functionality. For example, if I can click and drag, I do not need `transient-mark-mode`, a tricky modality in our "non-modal" editor. If I can summon a menu of relevant commands for a region, I do not need a menu of all commands filling up multiple pages of a separate window.
A GUI also introduces other problems, but the ability to just point at what you want to know more about or do something with has been a cornerstone of discoverability since the introduction of the mouse.
> For example, if I can click and drag, I do not need `transient-mark-mode`, a tricky modality in our "non-modal" editor
transient-mark-mode just allows you to see what you're selecting. If you don't have it you don't see what's being selected until you release the mouse. You need that more with a mouse than a keyboard.
> transient-mark-mode just allows you to see what you're selecting.
Yeah, no. It's a modal state, and since Emacs doesn't support modal interfaces directly, it touches tons of separate commands (anything using `region-active-p`) and means it's tremendously difficult to find out all it does!
Many commands change their behavior when Transient Mark mode is
in effect and the mark is active, by acting on the region instead
of their usual default part of the buffer’s text. Examples of
such commands include M-;, M-x flush-lines, M-x keep-lines,
M-%, M-%, M-x ispell, and C-x u.
To see the documentation of commands which are sensitive to the
Transient Mark mode, invoke C-h d and type "transient"
or "mark.*active" at the prompt.
The reason selection with a mouse also triggers it is because all these commands would not DTRT unless it did, given Emacs's approach of forcing mice to fit into the system designed for keyboards.
Hmm, thanks for pointing this out. But I'm slightly baffled, for the commands you gave (flush-lines, M-%, M-S-%) that's fine - transient mode with keyboard (between point and mark) and with a mouse, they are the same thing. Transmode is just highlighting AFAICS (between point and mark) and that mode quits the moment you release the mouse (leaving mark where you started the drag, point where you ended it). The convention of "operate only on stuff between point and mark" is necessary, mouse or no, and has been there since forever.
I would push back against this. There is definitely a pretty steep learning curve, but once you are over it you really start to reap the benefits of being able to rapidly add niche functionality that exactly fits your workflows.
The file browser on the left and the general design of it makes me lean towards the author intending this to replace VS Code and other modeless, less keyboard focused editors, not regular Emacs, which I can see the value in because Emacs being written in C and Lisp is probably a lot more performant and lean, plus a lot of people are opposed to Electron apps in general.
I have Emacs pinkies - I see the value in similar efforts. I will try this out for some time to see if it actually helps. But muscle memory is a thing for me, it is hard to undo 20 years of Emacs habits.
A weirder one for me that I like now: my RIGHT pinky has been hurting recently. Not sure if it's emacs fault, but I've been using "Enter/return key as CTRL when held"... When you hit return it's normal return key, but if you just hold down return it acts like control! It was weird at first, but now it's awesome - especially useful on a Mac lappy that has no right ctrl key.
Mac has "Aquamcs" which is mac native emacs with a wierd blending of MacOS key commands and emacs commands.
It works better than expected. Its not perfect but maintains the recording/playback of macros I use all the time. The fact that mac shortcuts use "Command" which emacs doesn't use natively helps.
The official Emacs.app also supports using the Command shortcuts while keeping all the normal emacs commands the same. In general I find that the app plays nicely with MacOS and I prefer it over aquamacs since emacs.app is newer (right now version 27 vs 25.) And I think looks nicer once I've removed the menu bars.
I was about to say the same thing! I suggest the author of this digs into acme (easy to run plan9 on a rpi!) and borrows some of the chording, because I'm not crazy about the menu driven mouse commands shown in the repo examples.
An "acmemacs" would be amazing - might be the only thing that could tear me from emacs at this point.
> 3) As someone who's used emacs for a long time, I would hate to have my emacs shortcuts replaced by standard ones. I don't want to remap my brain.
As someone who's used Mac for a long time (and now Linux desktop, with similar shortcuts, plus spending most of my time in a browser like Chromium or Firefox), I chose other editors like Sublime and now VS Code partly because they use shortcuts that feel normal on those platforms so I didn't have to remap my brain. (More like my thumbs I think.) So to me the shortcuts changes in this project may be the most interesting part!
I'm not sure anyone is actually fighting. We both like what we're used to, and neither of us is claiming it's better. We're both just agreeing we don't want to change.
People are allowed to like different things (except vi, obviously -- I hope we can all agree to that).
As a footnote: I'm comfortable with mainstream keyboard shortcuts too, but not in emacs. Those things do specific things in emacs, and would be a mess. If you remap ctrl-k, I won't have a way to cut a line anymore! I need that.
I recommend using the desktop feature also mentioned there.
Now, if I can only get emacs daemon mode to maintain state so if I abruptly disconnect and reconnect with emacsclient over X11 I get the state restored exactly where I left off, so that even the screen is painted exactly where I left off, down to the cursor position. Running something like VNC is a non-starter on my locked-down WinPC, unfortunately.
This is the first step only. I remember in 1995 Stallman wanted Emacs to be "like Microsoft Word" with varying fonts and other formatting shit with hidden Tex-coding. Do it.
I do not understand the want to stick with fixed-width fonts in this day and age. We do not use the editor to punch cards anymore, nor do we type text on a character-cell terminal or a typewriter. With the high-resolution displays, code we write should look more like one that is found in some nice programming books - complete with bold-faced reserved words, italicized comments, and even some mathematical typesetting. This could even (re)open the path to the Holy Grail of literate programming!
You can do that with many Emacs themes, but have you tried to read those things for a longer time? I like uniform text with minimal highlighting and I know many developers prefer the same - it is much easier for eyes. Some prefer to have a circus of fonts, colors and sizes. YMMV.
> I do not understand the want to stick with fixed-width fonts in this day and age.
Usually it involves alignment issues. Some people neatly align array entries, etc, and variable width fonts makes this look ugly. Also, people often put ASCII diagrams, etc in the comments, which are screwed up by non-monospace fonts.
> This could even (re)open the path to the Holy Grail of literate programming!
The Leo Editor[1] is your friend. It's the only such editor that seems to do it well. And by well, I mean "poor experience, but better than all the others."
It would seem that being able to simply insert an image (or some kind of a link to one - similar to what you can do in HTML) would serve the purpose much better).
It definitely does, and I can do this in Emacs with Org Mode. However, I cannot convince the world to use Emacs and Org Mode. I appreciate Noah's frustration.
In future PyLyx-mode the code is monospace, but comments are assumed to be Tex-formatted. Imagine implementation of some mathematical formula. You can have the description with proper notation. It will be so beautiful that it brings tears to my eyes already.
Well, then, the question is, why on Earth we are still emulating ancient character-cell terminals? What purpose does this serve? (I think I just might know the answer: so we could run fixed-width font based text editors in them!)
This seems like a nice extension to Emacs for folks that want to use it but are stymied by the steep learning curve.
Personally I think the learning curve is worth it... especially with an aid like Spacemacs. It gives you the context and quick access without requiring a mouse and thus results in faster and more efficient interaction in the long run.
I believe that all available evidence suggests that keyboard-only editing is not actually faster or more efficient (I say this as a keyboard-only Emacs user).
For me it seems like (haven't measured) being only on the keyboard or only on the mouse is faster than trying to switch between the two, if only because I avoid the mental context switching.
I see a potential future use case for this when human-computer interaction will be done through brain interface. Will prolly be easier to integrate with nervous signals from brain to one hand (mouse interaction) compared to two hands (keyboard interaction).
One of the things that drew me to emacs initially was that I could customise it to reduce or, in most cases, eliminate mouse usage. Toolbars, scroll bars etc. were the first things to go. Just taking those away makes emacs must more attractive for me.
- Native mouse selection of text, proper copy/paste, ideally with a "narrow caret" instead of block cursor everywhere
- Native graphical file tree with drag and drop
- Native tabs with pretty drag and drop
- Pixel-fine resizing of panes
- Pixel-fine scrolling!!
[0]: Everywhere I say "native" above, I don't really care if it's GTK or electron (provided it's snappy) or whatever. I mean the nebulous feeling of having text areas work like every other text area on my desktop.
VimR (https://github.com/qvacua/vimr) on mac was the closest to this I ever got, and I love that editor, but I'm not on macOS anymore.
edit: Oh g-----, I'm literally describing aquamacs. I wonder if anyone has tried to run it on linux with GNUstep or something ;__;