Mousemacs – A mouse-driven Emacs(github.com) |
Mousemacs – A mouse-driven Emacs(github.com) |
- 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 an emacs user and love it but lack of fine scrolling is hardly it's worst feature.
I would _really_ pay for that.
If you throw in a simple (even if limited) interface to elisp via something like python/lua, the would be IDE nirvana for me.
Emacs is so inherently keyboard-focused that I fail to see the point of this... nor the need for it?!
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.
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.
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?
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.
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.
A gui is a nice way to make a lot of functionality 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".
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.
How is discoverability of keybindings lacking?
Use your imagination and build a different editor.
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.
https://aquamacs.org/about.html
Look forward to trying mousemacs out.
-A
but mostly macos works well with emacs because... macos uses the basic emacs navigation and editing keys in all its text widgets.
control-a/e beginning/end of line
control-p/n previous/next line
control-k/y kill to end of line, yank
...
An "acmemacs" would be amazing - might be the only thing that could tear me from emacs at this point.
1) I would love to have a better way to manage tabs and multiple files in emacs. This piece seems awesome!
2) Good context menus aren't as important, but a definite win! emacs is useless here. But I'm not sure your context menus are the ones I want.
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.
I wish there were a way to pick-and-choose.
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!
They used to ban people for starting rWars on USENET (that is, outside of the forums specifically for rWars) back in the day.
https://stackoverflow.com/questions/350526/how-do-i-count-th...
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.
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.
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.
Do you think it'll still be able to run org-mode?
EDIT: Org-mode is working for me. I still don't know how to use it, but it's nice to be able to navigate through it via the right-click menus.
There is a way to pick and choose :)
The context menu in Mousemacs is a couple of dozen lines of Elisp and would be simple to rewrite. You can simply create your own context menus.
https://lists.gnu.org/archive/html/emacs-devel/2018-03/msg00...
https://lists.gnu.org/archive/html/emacs-devel/2020-04/msg01...
And not everybody is happy about it. [Careful, flame ahead.]
In my experience, code in non-monospace fonts are hard to read and is hard to navigate because the letters don't line up.
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."
Yes we do. Command line interfaces are as popular as ever and all terminal emulators rely on a fixed-width fonts.
I guess it feels fitting when you use a mouse wheel that has jumps in it anyway, but on a touchpad it feels highly unnatural.
I get terrible wrist pain when I even look at a mouse so editing speed is a secondary concern for me.
Easily configurable under Linux with xcape, and (iirc) karabiner for Mac. For Wayland there is also a tool.
OMG that is beautiful
Emacs tends to have its own names for many concepts, making things even more obtuse.
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.
[1] https://github.com/abo-abo/hydra
[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.
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.
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.
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).
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.
FWIW, VS Code uses Ctrl+Shift+K by default for Delete Line. I'm used to it enough that I sometimes try it in other apps, like Chromium text boxes …
Try explaining "yank-pop" to somebody who's only ever used sublime/vscode.
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.
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.
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 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.)
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.
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.
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.
But I'm no expert!