Hacker News Reader

Comment by bitwize | Hacker News Reader

No, it's not really. In order to get window toolkit independence, and terminal- or GUI-independence, Emacs pretty much has to pretend to be a deprecated system pretending to be an even more deprecated system pretending to be an obsolete system.

It needs a rewrite with modern tools and frameworks. And it needs to abandon the terminal (the obsolete system) altogether.

View on HN

Up until about a year ago, I used emacs exclusively from a terminal. The only reason I switched was because I usually have a number of tmux sessions open (with multiple “windows” in each one), and I kept losing emacs :). Having it in its own window made it easier to jump back to.

I’ll still often SSH home from a Chromebook and edit remotely. The fact that everything still works exactly the same is awesome. If you want to make an editor that doesn’t support that, you’re welcome to, but it won’t become my editor :)

"Now that I've SSH'ed into this system I sure wish I couldn't use Emacs!"

--Nobody, ever

(My point being that I think abandoning the terminal would be a huge loss to many people and therefore a poor decision)

Why would you SSH into a system and use Emacs there when you can just have Emacs handle SSH for you[1]? What do you gain by running the whole UI over SSH when you can just send the reads and writes instead? Especially since Emacs might not even be installed on the remote machine.

[1] http://www.gnu.org/software/emacs/manual/html_node/emacs/Rem...

Because it's already there?

I routinely SSH to my home desktop, where an instance of Emacs is always running, to work from e.g. a bus, or a queue to the doctors', etc. Since I'm normally working on my desktop, which runs GUI Emacs, when I SSH in I have all my files and processes opened as I left them, and I can pick up working via interface that's 99% indistinguishable, sans the smaller screen size.

Because I can. I've tried TRAMP a few different times in the past and, for whatever reason, I bounced off of it pretty hard every time. They were long enough ago that I can't remember what went wrong, but I have a pretty deep and lingering feeling of frustration whenever I contemplate giving it another go. Compared to the effort needed for me to shell into the remote machine and start Emacs there, I just haven't bothered.

I think it's great that the capability exists and that others find value in it; it's just not for me (or maybe vice versa). One of the great things about Emacs is that it can still work for both sets of people: folks who like TRAMP and folks who like to SSH in and run it locally.

Tried again just now to use Remote File access from my Windows desktop to my Linux (Ubuntu) cloud VM. I'm using Helm, and if I do C-x C-f (helm-find-file) and then type /ssh:me@remote: it opens a new buffer called "C:/ssh:me@remote:".

There was a suggestion on a Reddit thread to use Dired instead: C-x d /ssh:me@remote: which I also tried. This appeared to get further but subsequently failed with the error "ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory".

So I figured I'd try launching Emacs from within a Git Bash prompt to see whether that would provide the extra commands it was looking for, and it failed to locate my dotfiles (must have a different $HOME in that context...). However, when I attempted to open a remote file it did actually prompt me for a password! ...but then the LDAP authentication failed after timing out.

I'm out of gumption for now, but hopefully that helps to illustrate why I still want to be able to SSH into a machine and launch Emacs from the terminal.

Reply on news.ycombinator.com