Comment by TeMPOraL | Hacker News Reader

Comment by TeMPOraL | Hacker News Reader

Parent Full thread

I don't have an opinion on the way it does that, but the fact that it does think/work it's a text program is actually a feature, not a bug. Something like 99% of built-in features and 95% of features added by plugins work identically in terminal frames over SSH.

I fear if Emacs was remade with graphics at the forefront and text as a secondary concern, we'd lose a lot of interoperability this "text program" thinking brings to the table. Being able to work with an UI in a way you would with text files - jumping, copy-pasting, editing the UI itself, all with the exact same shortcuts and conveniences you use for programming - is incredibly powerful and something not really replicated elsewhere. I mean, number one complaint against TUIs and GUIs is that the data is locked inside, and you can't easily take it out and send elsewhere. With Emacs UIs, it's not true - if need be, you can select, copy and paste the whole thing, UI included, and it looks good in a text file and can be operated on programmatically.

--

Further improving performance of elisp and enabling true multithreading/async: that would be a huge breath of fresh air in Emacs.

Which part of ”we have to pretend to be a deprecated system that pretends to be an even more deprecated system that pretends to be an obsolete system to prevent Emacs from flickering” is a feature?

That is an implementation detail. The feature is "witness the firepower of this fully armed and operational battle station/editor, of which 99% works and looks the same both in GUI and terminal, at zero extra effort from feature developers". Whether or not the implementation is truly necessary to achieve the feature, that I don't know.

It’s not an implementation detail. It’s decades of technical debt, and it’s very strange to see it defended.

When a simple task of making a program not flicker (a solved, well understood and fairly trivial problem) requires quite a sizable effort, it’s no longer just an “implementation detail”.

LOL at people decrying the bloat and inefficiency of Electron apps and calling this a perfect program with just implementation details:

— start quote —

GNU Emacs is an old-school C program emulating a 1980s Symbolics Lisp Machine emulating an old-fashioned Motif-style Xt toolkit emulating a 1970s text terminal emulating a 1960s teletype. Compiling Emacs is a challenge. Adding modern rendering features to the redisplay engine is a miracle.

— end quote —

Let me rephrase my thoughts. I'm not defending this cruft per se. I'll be glad to see it gone iff it doesn't affect the text-orientedness of Emacs UI, as this specific style of text UI is a feature.

Don't focus in the mechanism. People aren't defending the mechanism. They are defending the benefit, which is currently a side effect of the mechanism: feature invariance with respect to render target, whether GUI or terminal.

My own use is about 50:50 of each. Only a few things don't work the same way in the terminal and that's extremely valuable.

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.

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