Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mousemacs – A mouse-driven Emacs

github.com

Post reply on HN
Print view View original

91–99 of 99 posts

Re: Mousemacs – A mouse-driven Emacs

#91

Post by vvillena »

kleiba wrote: post #51
vvillena wrote: post #29

Earlier quoted context omitted.

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

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

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.

Re: Mousemacs – A mouse-driven Emacs

#92

Post by stragies »

cobbzilla wrote: post #45
sn41 wrote: post #18

Earlier quoted context omitted.

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.

I always remap Caps-Lock to be an extra Control key; this has really helped me avoid repetitive stress injuries over the years.

Take it a step further: Remap CapsLock to be 'Escape' when pressed&released, and 'Control' when held.

Easily configurable under Linux with xcape, and (iirc) karabiner for Mac. For Wayland there is also a tool.

Re: Mousemacs – A mouse-driven Emacs

#93

Post by throwaway_pdp09 »

solarkraft wrote: post #74
rjeli wrote: post #71

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

> Pixel-fine scrolling!! 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.

Beyond 'pretty', how does this help the user in any way?

I'm an emacs user and love it but lack of fine scrolling is hardly it's worst feature.

Re: Mousemacs – A mouse-driven Emacs

#94

Post by throwaway_pdp09 »

morelisp wrote: post #68
wtetzner wrote: post #66

Earlier quoted context omitted.

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

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

Re: Mousemacs – A mouse-driven Emacs

#95

Post by solarkraft »

throwaway_pdp09 wrote: post #93
solarkraft wrote: post #74

Earlier quoted context omitted.

> Pixel-fine scrolling!! 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.

Beyond 'pretty', how does this help the user in any way? I'm an emacs user and love it but lack of fine scrolling is hardly it's worst feature.

It's less disorienting. Humans are not built to track things that are at one place at one point in time and instantly another at the next moment.

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.

Re: Mousemacs – A mouse-driven Emacs

#96

Post by morelisp »

throwaway_pdp09 wrote: post #94
morelisp wrote: post #68

Earlier quoted context omitted.

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

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

Re: Mousemacs – A mouse-driven Emacs

#97

Post by throwaway_pdp09 »

morelisp wrote: post #96
throwaway_pdp09 wrote: post #94

Earlier quoted context omitted.

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

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.

But I'm no expert!

Re: Mousemacs – A mouse-driven Emacs

#98

Post by gumby »

BeetleB wrote: post #79
gumby wrote: post #75

Earlier quoted context omitted.

Just do c-x c-b to get the list of buffers and c-x l to count the lines. Like everything in emacs it’s an editable buffer which is quite handy.

Ah, but this will be incorrect if you have multiple buffers pointing to the same file.

When you have hundreds of buffers it doesn’t really matter.

Re: Mousemacs – A mouse-driven Emacs

#99

Post by fluffything »

JetSetWilly wrote: post #70
fluffything wrote: post #19

Earlier quoted context omitted.

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

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

Post reply on HN