Live data from Hacker News

Mousemacs – A mouse-driven Emacs

github.com

61–70 of 99 posts

Re: Mousemacs – A mouse-driven Emacs

#61

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. https://github.com/syl20bnr/spacemacs

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

Re: Mousemacs – A mouse-driven Emacs

#62
post #49

Earlier quoted context omitted.

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.

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 ke…

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?

Re: Mousemacs – A mouse-driven Emacs

#63
post #3

Based on the title I hoped this was going to be emacs with acme-style mouse chording. [1]: http://acme.cat-v.org/

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.

Re: Mousemacs – A mouse-driven Emacs

#64
post #55
post #54

Earlier quoted context omitted.

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…

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…

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.

Re: Mousemacs – A mouse-driven Emacs

#65
post #61

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. https://github.com/syl20bnr/spacemacs

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

Any links?

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.

Re: Mousemacs – A mouse-driven Emacs

#66
post #49

Earlier quoted context omitted.

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 ke…

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 awfu…

Does a GUI actually solve any of these problems?

Re: Mousemacs – A mouse-driven Emacs

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

https://aquamacs.org/about.html

Look forward to trying mousemacs out.

-A

Re: Mousemacs – A mouse-driven Emacs

#68

Earlier quoted context omitted.

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 awfu…

Does a GUI actually solve any of these problems?

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.

Re: Mousemacs – A mouse-driven Emacs

#69
post #30
post #2

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

> nor do we type text on a character-cell terminal

Yes we do. Command line interfaces are as popular as ever and all terminal emulators rely on a fixed-width fonts.

Re: Mousemacs – A mouse-driven Emacs

#70

Earlier quoted context omitted.

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,…

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.

Post reply on HN