A mouse-driven Emacs?

I know most people who browse this thread will ask me to just plug the mouse off my computer, and I certainly did that at one point in my life, but using the mouse is really comfortable when you're skimming or if the laptop is too distant to comfortably use the keyboard. The latter happens when I read and have a notebook in front of my laptop. Emacs already comes with a fair share of mouse tricks that probably go unnoticed. This thread is to (a) ask a question, (b) share things that I know, and (c) share things that you know. I've already taken a look at the mouse+.el page on EmacsWiki and I did not find anything of interest. To be clear, I'm not interested in C-M-H-S-mouse-N combinations too much since when I use the mouse, the keyboard is too far away from me to bother. The same goes for editing-centric commands---I would rather use the keyboard. The question: What is the difference between mouse-N and down-mouse-N? I bound mouse-1 and down-mouse-1 to commands that echoed "click" and "hold" respectively. When I held down the mouse button, I expected it to just echo "hold" but that wasn't the case, it also echoed "click". "click" was echoed when I let go off the button. And here are some mousey things that I noticed Emacs does nicely, 1. The mode-line bindings! You can switch buffers with mouse-1 and mouse-3 on the buffer-name. You can access the major-mode and minor-mode menu using mouse-1 on the mode list. If you have two or more windows in a frame, then you can close the window or make it the only window (i.e., C-x 0 and C-x 1) using mouse-3 and mouse-2. Gnus is a pain though since it does not put the keymap property in the buffer-name. The following advice does the job for me. (define-advice gnus-mode-line-buffer-identification (:filter-return (return) vz/propertize-string) "Apply `mode-line-buffer-identification-keymap' to the string." (list (propertized-buffer-identification (format "%s" (car return))))) 2. context-menu-minor-mode. I don't think there is much to say here since it is a new addition and so is probably well known at this point but I will leave a link to an article about it by Philip K. -- http://amodernist.com/texts/emacs-mouse.html. Do you have any custom context-menu commands that help you? Please do share it. 3. The strokes library. I came to know of this from Karthik's article on "More batteries included with emacs" -- https://karthinks.com/software/more-batteries-included-with-emacs/. I do plan on having a go at implementing a TODO item in the file: > Likewise, there may eventually be a `strokes-local-set-stroke` > command, also analogous to `local-set-key`. 4. If you're familiar with acme(1) or Plan 9, you're bound to know about mouse chords (for the uninitiated, see http://acme.cat-v.org/mouse). There's a github repo in the wild that implements mouse chording for Emacs: https://github.com/akrito/acme-mouse but I never tried it so I can't tell how good it is. 5. There's a nifty buffer menu under C-mouse-1, which I have bound to mouse-2 in mode-line-buffer-identification-keymap. 6. Another article by Karthik about having the menubar in the tab bar is also interesting: https://karthinks.com/software/a-tab-bar-menu-in-emacs/. 7. Not Emacs related but I have two window manager tricks up my sleeve to create and resize windows keyboard free (that's a sentence you don't hear often in the Linux world I suppose): (a) Running a command when your mouse rests in a specific region of the screen, named "hot corners." You can see my implementation of it for awesomewm here: http://0x0.st/oanm.txt. (b) A dropdown menu when I right click the root window that brings up buttons to draw an emacsclient frame in (rio style), reshape any window by selecting it first with the mouse. I am not too keen on sharing the details here since they are highly window-manager specific but I use xmenu by z3bra (check z3bra.org). For a similar workflow (again by z3bra), see https://libreddit.spike.codes/r/unixporn/comments/dhs0ha/oc_see_mom_only_one_hand/. I have quite a few patches for xmenu to make it behave nicely with ewmh-compatible window managers and make it look a bit more aesthetically pleasing. If anyone is interested, just ask and I will share them. That's all I have to say for myself. What mouse-tricks do you have up your sleeve? I'm interested to hear them.

> The question: What is the difference between mouse-N and down-mouse-N? [Difference between \[mouse-1\] and \[down-mouse-1\]](https://emacs.stackexchange.com/questions/64964/difference-between-mouse-1-and-down-mouse-1)

> [ The awkward position is because I cannot figure out how to post a code block in the middle of a numbered list. ] 1. one code indented 8 spaces instead of the usual 4 2. two

Ah that sucks. I guess I have to write an idle-timer thingy to get the behaviour I desire. :-/ [Info-page: (info "(elisp) Button-Down Events")]

Now fixed. Thanks!

[removed]

1. Don't succumb to mouse-shaming. ;-) (You haven't; that's good.) 2. As the author of [`mouse+.el`](https://www.emacswiki.org/emacs/MousePlus) I agree that its features are relatively minor. The "**+**" in the name is not to indicate something wonderful. My convention for using "**+**" in library names is that the library is in some way an extension of the standard library of the same name without the "**+**" (library `mouse.el` in this case). In some cases (e.g. [Bookmark+](https://www.emacswiki.org/emacs/BookmarkPlus), [Dired+](https://www.emacswiki.org/emacs/DiredPlus), [Info+](https://www.emacswiki.org/emacs/InfoPlus), [Isearch+](https://www.emacswiki.org/emacs/IsearchPlus)) the extension is major. In other cases (e.g. Mouse+) it's minor. In yet others (e.g. [`find-dired+.el`](https://www.emacswiki.org/emacs/download/find-dired%2b.el)) it's midway. 3. A wholly new mouse feature (set of features really) is provided by library [Mouse3](https://www.emacswiki.org/emacs/Mouse3) ([`mouse3.el`](https://www.emacswiki.org/emacs/download/mouse3.el)). IMHO it's better (e.g. more flexible) than the mouse-3 context menu that was added to Emacs 28. In particular, it can give you (or code/modes) any kind of context menus, and in various ways, without your losing the handy `mouse-3` region-relimiting and region-deletion behavior of traditional vanilla Emacs. IOW, you can choose either/or behaviors (menu, relimiting), or both at the same time.

This has been removed, as it is not very civil; please attack ideas, not people.

1. Although we blocked every hole in our house that a mouse can get in, the one in my desk manages to be just fine! 2,3. I think I confused mouse-3.el and mouse+.el to be the same. I can't tell. I will take a look at mouse-3.el because it sounds like it does what I want, thanks for pointing me to the right package. Also, I was surprised to learn that find-dired+.el didn't have a filter function to unescape the nonsense `find -ls` writes when I checked it months before.

Maybe I'm missing out. pretty much the only thing I do with the mouse in Emacs is resize windows and frames.

Bruh. This seems to go against the ethos of Emacs: to keep your hands on the keyboard 100% of the time. Edit: Actually these are good tips. Much appreciated.

I'm excited to take a look at these packages. As someone who recently delved into the guts of `mouse.el` there were some bits in there that I had a hard time grasping. In particular the function [mouse-on-link-p](https://github.com/emacs-mirror/emacs/blob/9661c82920cf2b75300266bbd9da9e45b9471173/lisp/mouse.el#L1537-L1592).

Definitely saving this post. Lots of useful tips! I, too, think there are times when using the mouse is more efficient, or at least more comfortable than the keyboard. I really appreciate that Emacs includes mouse functionality in addition to excellent default key bindings.

Not really a mouse-trick but just a PSA: A lot of modes put stuff in the tool-bar by default, eg info-mode puts navigation buttons. You can also put stuff in the toolbar with `tool-bar-add-item`, I usually add buttons for stuff I like to toggle frequently with mouse, eg treemacs. The toolbar is kind of underutilized, though I think it's because icons are hard to find and also the toolbar is a bit confusing to configure, for example there isn't a neat command to add separator items in the tool-bar, you have to dig in the manual and learn how menu keymaps work and all the different commands that are used to build them. EDIT: A possibly "better" way to do tool-bars in emacs that might be less confusing is to use the header-line, which is configured the same way as the mode-line: it has the benefit of being per-buffer and can also take full advantage of all mouse buttons and modifier keys, unlike the tool-bar which is only capable of detecting when a tool-bar item is clicked. So a single "button" in the header-line can do different things depending on whether it was clicked with the left mouse button or right mouse button.

I have my mind open for cool mouse-tricks, and my gaming mouse could probably find some use to all them extra-buttons. But thing is when I'm on emacs, I rarely have my hand on my mouse in the first place, so it feels like binding anything to it would be less convenient than just do it on my kb. Even the example you gave: if I'm reading something that won't need input (aka: me typing notes), it will probably feel more comfortable to do it on a tablet. I haven't used emacs browser things, and I don't know how it works, but assuming it is compatible with mouse, maybe that could be a time which I'd prefer having one hand on the mouse and one on the kb often and have a reason to find some tricks.

If you’re interested in a mouse-driven experience, take a pin internet-search gander at Acme or Sam, the editors built as part of the Plan 9 operating system. The ideas are not easily grafted directly into emacs, but they are definitely interesting. From a high level, the idea was to build a ui that assumed color gui displays and three-button mice. These were baseline standard at the time (ok, a mouse with 3 good buttons rather than 2 was sometimes harder to find), but the UIs of that era were basically built around a pure-text interface with added gui “chrome” like scroll bars and menus, or a b&w graphical display with a 1-button mouse (“Hello, Macintosh!”). Acme instead uses mouse chording (for example, press and hold mouse-1, drag out an area, then press mouse-3) to make the mouse very expressive. Within this framework, most things were text (not icons), and the expressive mouse could be used to make the text active — different chords would grab text for manipulation, or run it as a command, or send it to a dispatcher application called the plumber that could be extended as easily as emacs, sort of a system-wide “thing-at-point” concept. It’s still possible to run acme these days via a sort of vm-ish translation layer on a modern OS, if one were really interested. Plan 9 itself suffered from a refusal/failure to adopt the “modern web”, which required a fairly unruly mess of CSS and JavaScript even back then.

This is cool. I work s lot with mouse driven gui applications, and switching between kb and mouse when testing can be annoying. I'll probably end up using some of this. Thanks.

nice username

FWIW, library [Tool Bar+](https://www.emacswiki.org/emacs/ToolBar#ToolBarPlus) ([`tool-bar+.el`](https://www.emacswiki.org/emacs/download/tool-bar%2b.el)) offers these features, to conserve screen real estate: * Adds a minor mode, `tool-bar-here-mode`, which is the same as `tool-bar-mode`, except that it affects only the current frame. This saves real estate on frames other than the ones with the tool-bar. * Adds a “button” named **Buttons** to the far right of the menu-bar whenever the tool-bar is not visible (that is, whenever both `tool-bar-here-mode` and `tool-bar-mode` are turned off). You can click **Buttons** to pop up the tool-bar on the current frame just long enough for one command: after you click a tool-bar button, the tool-bar disappears again. The **Buttons** button is absent whenever the tool-bar is visible, and vice versa.

Could you perhaps elaborate a bit about unescaping `find -ls` nonsense?

> If you’re interested in a mouse-driven experience, take a pin internet-search gander at Acme or Sam, the editors built as part of the Plan 9 operating system. OP mentions Acme and an Emacs library that implements Acme-style mouse chording.

`find -ls` does the most unhelpful thing ever: escaping non-ASCII characters. When I saw this for the first time, I thought I should check out find-dired+ to see if you already had something for this. I was just a bit surprised to see nothing pop up is all. In theory, you can use `find-dired-refine-function` to unescape them. (Also see bug#36085.)

See item no. 4. ;-) I do know of plan9port. I would be using the mouse-chording library I linked in OP if it weren't such a PITA to press the scroll button in my mouse. I do love the concept of plumber though, the closest things that comes in practise is GNU Hyperbole; second closest embark. I say embark comes second closest since it is not dwim enough but it does have the same general principles as the plumber. The thing that made me stick to Emacs in the first place was the realisation that I could make my own makeshift 9term using M-x shell. When I did this, I could ditch the friction between having a terminal window open with my shell and an Emacs frame. Moreover, the shell was more fun to use as well. ;-)

You don't really miss out a lot by not using the mouse. I was more or less using the mouse only to resize windows and reshape Emacs frames by drawing a rectangle. But like I said in the OP, when I'm reading a PDF file or somesuch and taking notes on _paper_, I have a note that is a bit shorter than A-4 size between me and the laptop keyboard. In such cases, it is uncomfortable to bend over the desk and use the keyboard---I end up looking like this octopus!: http://0x0.st/oahT.jpg TL;DR: You don't miss out much but having more options to use the mouse is handy in my case.

Oh yes, I know how useful the tool bar tends to be as well. But the problem I have with the tool bar is that it takes too much screen real estate, and the fact that it uses icons to represent commands not text. AFAICT, there's no way to autohide the tool bar like the Windows taskbar either. I'm also absolutely awful when it comes to understanding icons, they don't make sense to me at all: as an example, it took me literal years to understand the messenger icon used by facebook was a paper airplane! I always thought it was some kind of crooked thing. I would prefer it if the tool bar was more like Acme's tag, in that, I could write whatever sexps I want in a freely editable space and have an easy to eval it whenever. But that is not the case. The toolbar not being rendered per buffer is also kind of a bummer. And like you say, the header-line could be used as a toolbar of sorts and I absolutely do this for pdf-view buffers. ;-) I have clickable buttons in the header-line for annotation functions, goto page and outline. I advice the drag mouse command to make the markup annotation functions behave a bit more like Okular's markup annotations too.

>Even the example you gave: if I'm reading something that won't need >input (aka: me typing notes), it will probably feel more comfortable >to do it on a tablet. I prefer paper. And the notebooks I use are all a bit shorter than an A-4 sized sheet so I end up a bit far away from my keyboard to be able to use it comfortably. >I haven't used emacs browser things, and I don't know how it works, >but assuming it is compatible with mouse, maybe that could be a time >which I'd prefer having one hand on the mouse and one on the kb often >and have a reason to find some tricks. Like u/wysteriary pointed out, the toolbar has useful buttons. But my original intent to use the strokes library was to make gestures for navigation. A swipe towards the right for backward history, a swipe towards the left for forward history, etc.

>Bruh. This seems to go against the ethos of Emacs: to keep your hands >on the keyboard 100% of the time. Considering how thoughtful the Emacs mouse commands are, I would disagree.

As briefly referenced by an earlier poster, the single GNU Hyperbole package in addition to its extensive context-sensitive keyboard-based Emacs augmentation does even more with two thoughtfully designed context-sensitive mouse keys, allowing you to manipulate window and frame layouts, browse documentation, select and drag more types of things than thingatpt.el and other things as documented below: [Hyperbole Smart Mouse Keys](https://www.gnu.org/software/hyperbole/man/hyperbole.html#Smart-Mouse-Keys) Install one pre-configured package with years of design expertise and save your self the time and effort from hunting around for a dozen other point packages to get to a similar level, all of which are likely handy but just solve a small sliver of the rapid information management needs that you likely have. Enjoy.

I know of GNU Hyperbole. It is probably my favourite package despite not having used it much. I'm waiting for it to play nicely with native-compilation (I saw you open a bug report about it on debbugs too). I haven't looked too deeply into the mouse support of GNU Hyperbole though so thanks for linking the relevant info node.

I would kill for *mouse gestures* in Emacs...

You don't have to kill. Try out the strokes library. There's a video demo in the link I mentioned.

It's not often that I save a reddit post. Today is a rare day…so, thank you, OP; there's quite a bit to unpack and explore here!

I see. So this is about a general `find` issue on some platforms. Your best bet is maybe an eventual fix to Emacs bug #36085.

Yea, hopefully a fix goes in. But it does not bother me too much since I did end up writing a filter function (the one in the last mail was posted by me).

Well, obviously my skim was too quick! Apologies for not giving your post a thorough enough read before posting. If you do implement something like 9term or acme using shell or eshell, I for one would love to hear about it. I toyed with something like that a while back, but got sidetracked by several years on a MacBook trackpad, and never picked it up again. I’ve long thought that there was room for a cli/shell interface that separated the input area from the output area, made it very low-friction to snarf text for the input area, and saved all of the output in an infinite scroll of some sort. Back in college, I toyed with something like this using the Andrew Toolkit from CMU, but the overhead of that system was always quite high, and Andrew itself was never very stable. I also toyed a bit with rep the idea in epoch, before lucid/emacs 19 became real. At this point, I think emacs is a good platform for such a tool, but I have less need for hardcore shell usage after I shifted career away from coding. Anyway, if you find/build something along these lines, I’d love to hear about it!

The best thing about 9term for me is the fact that you can easily turn the output of a command into new input. The bulk of the part was already done for me due to the exact design of Emacs itself---buffers. All I did was add some glue code to make RET pass the current region or line to the shell as the command to run. (defun vz/comint-send-input () "Send region if active, current line otherwise." (interactive) (if (use-region-p) (let ((cmd (buffer-substring (region-beginning) (region-end)))) (comint-send-string (get-buffer-process (current-buffer)) (concat cmd "\n")) (comint-add-to-input-history cmd) (deactivate-mark)) (let ((on-prompt (comint-after-pmark-p))) (save-excursion (comint-send-input)) (when on-prompt (comint-next-prompt 1))))) I would recommend binding comint-accumulate to a more convenient key like S-<return>. As for re-pasting the command with the mouse, it is already available OOTB: mouse-2 (Emacs is really thoughtful about the mouse, innit? ;-). I haven't done anything to replicate the plumber since I think GNU Hyperbole does a thorough job. M-RET on the line of interest and it will just work™. In acme's win, you can right click on a filename to open it in acme. I haven't done anything like that since usually C-s <search> C-x C-f M-n RET does the job. Speaking of the plumber again, I think we can leverage the OSC 8 sequences. Comint-mode got support for OSC 7 and 8 sequences in Emacs 28, I already use OSC7 to track current directory and it's been flawless. Anyway, here's the commentary in comint.el ;;; OSC escape sequences (Operating System Commands) ;;============================================================================ ;; Adding `comint-osc-process-output' to ;; `comint-output-filter-functions' enables the interpretation of OSC ;; escape sequences. By default, OSC 7 and 8 (for current directory ;; and hyperlinks respectively) are acted upon. Adding more entries ;; to `comint-osc-handlers' allows a customized treatment of further ;; sequences. Finally, as a slight tangent, the comint-mime package will definitely improve the M-x shell experience: https://github.com/astoff/comint-mime. I obviously don't separate the input and the output area personally since my RET command does a good enough job most of the time. But I think the sheldon package does this https://github.com/Overdr0ne/shelldon. I haven't thought about saving the output to somewhere though. There are commands that lets you write the output of the last command to a file but I never really used them. Having an infinite buffer size limit for the shell instance is good enough for me. If I have ever to save my current shell instance for future ref, I just mark and copy the lines to a file (I did this when I played around patching an executable for NixOS). If you have a simple shell prompt I like do (just % lol), then setting an appropriate outline-regexp is super easy. [ This easy copy-and-paste output paradigm is another attractive factor for me. \`st(1)' has the flag -o which might be of interest. ] I think someone described M-x shell as a two-dimensional interface and thusly more convenient than the traditional shell in a terminal emulator, and I couldn't agree more. Most of the time previous output needs to be turned into the new input and nothing is more frustrating than not being able to trivially edit the output to do the job. The line orientated terminal emulator does not let you do so. Not to mention, multi-line commands suck balls and IMHO people take the wrong approach to solve them by deciding to stick with the stupidly constrained terminal interfaces. Much of my sentiment is also shared by Pierre Neidhardt, you can see his Common Lisp as a shell experiment (?) in his blog: https://web.archive.org/web/20210926052045/https://ambrevar.xyz/lisp-repl-shell/ That's all I have really. This comment kinda turned rambley since I added things in an ad-hoc manner, sorry about that.

We have fixed this in the elpa-dev pre-release. See the Hyperbole manual for how to install from there.