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

81–90 of 99 posts

Re: Mousemacs – A mouse-driven Emacs

#81

Post by Koshkin »

BeetleB wrote: post #77
Koshkin wrote: post #30

Earlier quoted context omitted.

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

> I do not understand the want to stick with fixed-width fonts in this day and age. 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 y…

> diagrams

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

Re: Mousemacs – A mouse-driven Emacs

#82

Post by BeetleB »

Koshkin wrote: post #81
BeetleB wrote: post #77

Earlier quoted context omitted.

> I do not understand the want to stick with fixed-width fonts in this day and age. 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 y…

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

It definitely does, and I can do this in Emacs with Org Mode. However, I cannot convince the world to use Emacs and Org Mode. I appreciate Noah's frustration.

Re: Mousemacs – A mouse-driven Emacs

#83

Post by abrowne »

murgindrag wrote: post #73
vaxman wrote: post #57

Earlier quoted context omitted.

Don't talk about politics, religion or text editors at work, son. They used to ban people for starting rWars on USENET (that is, outside of the forums specifically for rWars) back in the day.

I'm not sure anyone is actually fighting. We both like what we're used to, and neither of us is claiming it's better. We're both just agreeing we don't want to change. 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 mes…

Hear, hear. Celebrate diversity!

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 …

Re: Mousemacs – A mouse-driven Emacs

#85

Post by m463 »

sgillen wrote: post #72
acomjean wrote: post #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

The official Emacs.app also supports using the Command shortcuts while keeping all the normal emacs commands the same. In general I find that the app plays nicely with MacOS and I prefer it over aquamacs since emacs.app is newer (right now version 27 vs 25.) And I think looks nicer once I've removed the menu bars.

except for cmd-c (apple copy) and cmd-w (emacs copy)

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

...

Re: Mousemacs – A mouse-driven Emacs

#86

Post by jcynix »

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.

Microsoft's office products are mostly GUI centered. But I rarely can easily find ways to accomplish things there and instead get lost in their GUI, which sometimes looks like a twisty maze of little passages all different. So "GUI" isn't a panacea for ease of use IMO.

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.

Re: Mousemacs – A mouse-driven Emacs

#87

Post by O_H_E »

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…

> Sublime UI on top of embedded emacs.

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.

Re: Mousemacs – A mouse-driven Emacs

#89

Post by s17n »

wtetzner wrote: post #65
s17n wrote: post #61

Earlier quoted context omitted.

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.

I just googled and it looks like my statement is true, with the caveat that "all the available evidence" is pretty much garbage.

I get terrible wrist pain when I even look at a mouse so editing speed is a secondary concern for me.

Re: Mousemacs – A mouse-driven Emacs

#90

Post by kleiba »

thom wrote: post #64
kleiba wrote: post #55

Earlier quoted context omitted.

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.

Yeah, that would be sad. Luckily, I'm not one of these people but at the same time, there's no denying that keyboard is the main modality most Emacs interactions are optimized for.

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.

Post reply on HN