Hacker News Reader

Comment by chrisfinazzo | Hacker News Reader

Is mouse-mouse enabled by default?

Can the insertion point be moved by clicking in a particular location?

As of recent versions of macOS, emacs isn't included by default. Last I tried, in terminal-mode emacs, the answer to the above questions seems to be no - with no reasonable explanation why this is the case.

I'm more than willing to do everything else from the keyboard, but these are basic oversights that have yet to be corrected.

EDIT: Is mouse-tracking actually the feature that enables this behavior?

View on HN

On Debian with the distro package, I never even thought about mouse integration. (On the Xorg interface. So much basic stuff - not emacs stuff, but really basic stuff - has been moving into DEs that I don't think the bare console is usable anymore.)

The insertion point is moved by clicking and by using the scroll wheel (now that I've thought about it, maybe I should change that second one), clicking and dragging and double click change the selection.

I normally don't use the mouse, but for moving text between windows it's nice.

M-x xterm-mouse-mode gives an experience in the console that's pretty darn faithful to the full GUI when it comes to mouse interaction. Clicking, selection, and scroll wheel all work pretty much as expected. Even menus and pop-menus work; the new TTY menu in 28.1 is pretty slick!

Confession: I'm a BBEdit user most of the time, so take my questions here with a grain of salt. Although I don't need it often, I still felt the impulse to take a side w.r.t emacs and vi.

I'll see if I can dig out my old init.el from backups and try to get it up and running with 28.1. I actually hadn't heard about the scroll wheel stuff before, so that might be one way to solve this for me.

Is there a setting in Customize to control whether to use init.el or .emacs for configuration? Trying to set symlinks from $HOME to another directory and it's fighting me...

I believe the code that controls that is all in startup.el (or startup.el.gz) in the Emacs distribution. You can find the documentation here:

https://www.gnu.org/software/emacs/manual/html_node/emacs/Fi...

I do know that ~/.emacs takes precedence over ~/.emacs.d/init.el. I've taken advantage of that in the past to keep all the public configuration that I share between machines in ~/.emacs.d/init.el, and then on my work machine I had a ~/.emacs that wraps a (load "~/.emacs.d/init") with some company-specific configuration.

The stink of it is, I had this working: mouse-mode, correct symlinks, all of it...for like 10 mins. before I realized, 'oh crud, I forgot to disable something' and in my haste of mucking w/ settings, tossed the good init I had trying to ID what was missing.

Self: You're dumb

I think I can recreate it, but I've got other stuff to do too, so this may get paused for a while - Monterey beckons as I have yet to take that plunge, although I really should soon.

emacs "gui" perfectly supports the mouse out of the box.

For use in a terminal (after using both for some time, I find the gui version better tbh), see https://www.gnu.org/software/emacs/manual/html_node/emacs/Te...

I personally think GUI mode is simply better. There is no real advantage to running emacs in a terminal imo.

Hard disagree. Sometimes the terminal is the most efficient way to run Emacs on a machine in a remote data center that has a mountain of CPUs, GPUs, memory, and disk. TRAMP can be slow and inefficient. A LSP server process on a huge monorepo can chew up a large amount of memory and CPU on startup. Running all of this stuff locally on the actual hardware your code needs to run on is great.

TRAMP is great, but to me it never feels the same as running locally. OTOH ssh -X (i.e. X forwarding) works for me for exactly this specific case (large and powerful remote dev box).

Incidentally my current setup is that I'm WFH and RDP'ing into my windows desktop, where I run VNC to our xvnc server where I ssh -X to the dev box where I run GUI emacs. It is surprisingly usable (I can also skip the RDP and run VNC directly if needed).

> to run Emacs on a machine in a remote data center that has a mountain of CPUs, GPUs, memory, and disk

But then why not run the daemon on that server and the GUI locally?

Have you actually tried that? I know the server _can_ expose a TCP socket but it's not clear to me if it's intended to work across machines.

Reply on news.ycombinator.com