- 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.
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.
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.
