Hacker News Reader

Comment by jonathanstrange | Hacker News Reader

For me as a daily Emacs user this sounds like another "editor war" rant. I neither find Emacs hard to customize nor do I think it has any substantial limitations other than the ones that are based on my own lack of knowledge. It's always fair to compare it to Vim, but I don't think it makes much sense to compare it in general to VS Code or Atom.

One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform. The same could be said about Vim. In comparison to these two, newer editors sometimes appear too ephemeral and fragile to me. (Then again, I used to use BBedit on the Mac and just found out that it's still around! What a nice surprise!)

View on HN

Same. I used to swear by Intellij but they just kept on changing things, and even breaking things on me the odd time.

This latest emacs upgrade has been seamless and hasn't required any cognitive overhead to transition.

That said, I'll always be back to IntelliJ for heavy edits. There's nothing better for Java.

I find for less structured languages the less-structured approach engendered by emacs is an advantage.

emacs has a couple of packages working to implement the editor side of the language server protocol, so it's probably not long until it's at rough feature parity for structured editing of languages with rich semantics.

Emacs is compared to vim because both can be run in a terminal on a remote machine, not because it’s the JS-editor-of-the-month. There’s a fairly decent chance I’d switch away from vim if I ever had a job where I could edit code locally.

I see this occasionally. Why can't you edit locally?

Sometimes it’s policy (no source code on laptops), but mostly it’s because my line of work uses the verilog language and the tool suites require “very stable” (read: archaic) versions of Linux.

Damn, that's a shame, I hope that the pay is good at least :)

do you know about TRAMP? https://www.emacswiki.org/emacs/TrampMode

Can you use ssh/scp? Emacs is able to use that to edit files remotely. I often use it when I work with small Arm Linux boards.

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

sshfs is a thing. If i had to use remote machines only, i would use tramp; not run an emacs instance on a remote machine. I haven't had good experience running editors inside tmux.

Emacs has TRAMP, which allows transparent access to files on remote systems using a variety of protocols (but mostly ssh/sftp).

...and if you haven't given TRAMP an honest shot, you definitely should. I took the leap not too long ago, and it is absolutely amazing. Whenever I can't access a host using TRAMP (does happen, but very rarely), I put off whatever task I have to do on that host for a very long time.

The fact that TRAMP lets you open files on remote systems in and of itself is fairly mundane. What makes it really cool is that it works seamlessly also with dual-pane dired, and just about anything you do in Emacs. It turns remote filesystems into local ones.

Being able to, in my regular file manager (I like Sunrise Commander), treat any combination of remote and local filesystems as though they were local, is a huge productivity boost.

It's this sort of thing that when I first saw it on Apollo's Aegis and again later on Plan 9 it was so obviously useful I figured it would just be everywhere in no time. At then Sun touted "The Network Is The Computer (TM)" and I was like here it comes! But it hasn't quite panned out that way. Considering the number of viruses and ransomware perhaps that's a good thing but it would be cool as hell if I had shared name spaces with my wife, mother, sister, etc rather than the artificial constraint of mapping into Facebook or Google Photos (for example) to share a photo album.

Not that it's the /correct/ solution, but Keybase does a good job of providing that shared-directory experience, and the free tier is pretty roomy.

Not affiliated, just getting good use out of it.

But the coolest thing by far is that you can now go the reverse direction. If you have a ssh tunnel you can run emacsclient --tramp $file on the remote system and it will pop up on your local Emacs window.

Consider my mind blown! :)

Once I had to work remotely over 2g cell phone. Using remote terminal was too painful due to huge latencies approaching 1s. What worked surprisingly well was to work on a local copy of files in a local editor and then to run command remotely I would prefix them with a script that I aliased like rc. The script rsyncs first the tree to the remote host and then run the command there. These days for much simpler setup I use lsyncd to sync file trees and then the rc command just runs the command over ssh.

For that use case, if you have Emacs locally, you could use TRAMP - which basically works the way your script does. It allows you to transparently access files, directory structures, or even run shells on remote machines. It supports many protocols; the typical way it works, is it starts an ssh connection in the background, and uses the shell to ferry the file you want to edit to your local machine, and then transparently ship it back when you save.

TRAMP does not work like that. First it does not have a whole directory tree, rather it just caches the opened buffers so things like grep etc. must run remotely which sucks on a high latency link or could be much slower if the server is not very powerful VM. Second at least like 5 years ago when the last time I played with TAMP it worked really badly on an unreliable connections or when the laptop switches to different wifi network. If ssh connection hangs, the whole GUI often hangs and sometimes after reconnecting I had to throw away resent edits and reopen the buffer. It could be that nowadays things are better, but for me nothing beats my lsyncd + explicit remote command script. Even file completion works with trivial efforts. As paths in my local tree copy matches the remote paths, completing by files just works, and it is trivial to call completion scripts for remote command from the completion script for rc.

For some perspective:

BBEdit - launched in 1992 (26 years ago), still around.

Notepad++ - launched in 2003 (15 years ago), still around.

Textmate - launched in 2004 (14 years ago), still around.

Sublime - launched in 2008 (10 years ago), still around.

Almost all the mainstream editors since 1995 at least are around. They have been marginalized, but they're generally around. Especially cross platform editors and even more so Open Source ones have great survival characteristics.

That's why both Atom and VS Code seem like solid long term bets.

To see why this isn't necessarily the case, add to your list all the text editors launched between 1992 and 2008 that are no longer around ("being around" defined as being able to install and run on whatever OS you're using on your main computer with no special effort).

Exactly. The post above yours is simply an illustration of survivorship bias.

I'd be interested to hear about former mainstream editors from that time that are gone. Especially cross platform and Open Source ones :)

Brief, Multiedit, Codewright, Semware, Slickedit and Epsilon used to keep the lights on at many programming/tech magazines. You don't hear much about them anymore...

Clark Maurer still updates Slickedit at least annually though.

You made me curious as I'd never heard of any of these editors... (except for Slickedit, I think)

A bit of digging around:

Brief seems completely dead, was killed off by Borland.

Multiedit seems operational: http://multieditsoftware.com/ It doesn't seem to active, but you can still buy the product.

Semware is still technically "alive": http://www.semware.com/ It was last updated in 2005, so there's that :)

Slickedit: is definitely operational: https://www.slickedit.com/ I have no idea why you're counting it as dead?

Epsilon: seems operational http://www.lugaru.com/ They even had a release in 2018.

To also clarify my previous statement, in the history of software, there's pre-mass PC and pre-internet. In my opinion the 2 periods are not comparable. Anything which was launched before 1995-9 or so is way more likely to have died. The mass PC and the internet have offered even commercial products much higher resilience.

Now, if a tool for developers reaches the mainstream, it super likely to stick.

I find very often that arguments by Emacs and Vim users come from a time before 1999 or so, when companies were super volatile. Look at this: https://www.joelonsoftware.com/2003/08/01/rick-chapman-is-in...

The list from Softletter in the spolsky link kind of illustrated my point. Most of the editors I listed were big sellers until 1997 or so. And most of them are effectively dead with the exception of Slickedit. The reason I switched to vim was the lack of a decent text mode editor for Windows in the early 90s. I'd likely still be using Slickedit otherwise.

Also, the cited survivors have certain characteristics, like being small items with no "ecosystem" baggage and few dependencies in general.

It makes sense, I guess. As programmers, we naturally spend a lot of time with our editors of choice, so we become very attached to them, both emotionally and practically - with Emacs, at least, you accumulate your customizations and extensions over time, and you want all the time and effort you put into learning and customizing to pay off. And with any editor, there's the muscle memory - it's like you're offloading certain tasks to a dedicated piece of hardware, thus freeing your mind to focus on the task at hand. It's a kind of "lock-in", if you will, but it's the kind that enhances your productivity.

Original comment:

>One major reason for me to use Emacs and not newer software is that it is not only cross-platform but also gives some confidence that I will be able to use it in twenty years from now on a new platform.

You're ignoring the first half of the sentence:

BBEdit - not on Linux

Notepad++ - not cross platform

Textmate - not cross platform

Sublime - cross platform - but can I see the source? If not, I have little faith it will be around in 20 years.

My (heavily customized) Emacs environment on Windows gives me the same experience as in Linux. No warts at all.

I wasn't ignoring it, if you notice my final argument is for cross platform and FOSS stuff: Atom, Visual Studio Code.

There's even good native editors if you want that, Scite comes to mind.

Anyway, my point was just don't dismiss out of hand, don't belittle other people. Of course, if you're happy with Emacs, continue to be happy.

Oh, and the irony of this is me railing against Emacs/Vim when I'm also a Vim user and have been for at least 10 years. I say also because I've been using VS Code quite a bit lately.

VS Code and Atom are practically guaranteed to run until the end of time at this point. The sole benefit of web apps is that they're more likely to remain functional than native ones.

Both Atom and VSCode are multiplatform and can run on any platform emacs can. Hell there's a version of it that runs in-browser. Both have commercial backing and the platform is built ok Chrome. Hard to imagine a world where any of that adds up to ephemeral.

Any platform? Like the terminal on my server?

No, like your browser since it's a GUI? A terminal isn't a platform.

Not all environments have GUI or need to have it

Never said otherwise. Just assumed my statement would be clear that environments lacking a windowing system wouldn't qualify given GUIs require a windowing system.

I'd love to use Atom on a little QNX system, can you tell me where I can find the Atom distribution? It's possible to build Emacs on it.

That's my bad, I should expect stupid responses when I make a stupid statement. Major platform where, you know, it makes sense to have. You'd "love" to have Atom on your realtime OS? For what, exactly?

I'd bet he'd want to edit text; but I'm no fortune teller.

You'd probably use a text editor in that case. I'd bet most operating systems include one.

I need to work on my disruptive startup's decentralized AI blockchain machine learning product using Vue.js from my car's infotainment system.

Actually though pre-6.6 QNX had a great GUI and is capable of running on desktops and laptops just fine¹. I rather like it.

¹ Hardware support is not great but way better than you might be expecting. Either way, it runs fine in VMWare and VirtualBox. I'm currently trying to acquire some parts to build a PowerPC laptop for QNX.

Reply on news.ycombinator.com