Comment by dang | Hacker News Reader

Comment by dang | Hacker News Reader

Just for fun, here are some of the larger past threads. Others?

After over a decade of Vim, I’m hooked on Emacs - https://news.ycombinator.com/item?id=16551796 - March 2018 (161 comments)

A pragmatic decision on GNU Emacs versus Vim for programming - https://news.ycombinator.com/item?id=13590944 - Feb 2017 (59 comments)

Why I switched from Vim to Emacs - https://news.ycombinator.com/item?id=13130775 - Dec 2016 (101 comments)

From Vim to Emacs - https://news.ycombinator.com/item?id=8367384 - Sept 2014 (116 comments)

Emacs and Vim - https://news.ycombinator.com/item?id=8084359 - July 2014 (275 comments)

Vi and Vim vs. Emacs Shootout and Deal - https://news.ycombinator.com/item?id=3205828 - Nov 2011 (52 comments)

Some thoughts on Emacs and Vim - https://news.ycombinator.com/item?id=2229040 - Feb 2011 (40 comments)

How a Vim user converts to Emacs - https://news.ycombinator.com/item?id=2036586 - Dec 2010 (66 comments)

On vim vs emacs - https://news.ycombinator.com/item?id=1374916 - May 2010 (28 comments)

Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)

Emacs vs Vim is like comfort food for software-related online discussions.

And it's even more useless fluff than it was back in the day because people used Vim and Emacs in large numbers back then. These days the vast bulk of professional developers use Visual Studio Code. Compared to VSCode vs. IntelliJ, Vim vs. Emacs is a sideshow at best.

> Vim vs. Emacs is a sideshow at best.

Until you need to ssh into a server and edit something.

VS Code supports editing files over ssh. https://code.visualstudio.com/docs/remote/remote-overview

Yeah but you have to install 100+mb into a .vsserver folder to get it to work

sshfs?

Unfortunately, sshfs doesn't work on modern macOS.

I just tested and it works for me, I'm fully up to date too.

That is great! I thought Big Sur had deprecated kernel extensions which would prevent osxfuse and sshfs from working.

It's funny you mention that.

https://www.murilopereira.com/how-to-open-a-file-in-emacs/

The summary is that the author tried to open a remote file and Emacs froze for several seconds. He dived deep into finding out why that was and how to fix it, pointing out how great Emacs's introspection is that one can find solutions to problems like these.

And then two thirds of the way into his essay, he has this:

> More recently, I’ve been very put off by the performance and stability (or lack thereof) of building large scale software via Tramp. This has been sufficient to have me looking out again. On a whim, I installed VSCode for the first time and tried its “remote development” capabilities and holy smokes are they good. Getting up and running was trivial and the performance was great. Saving files was snappy and LSP worked out of the box. What a different experience from my carefully-put-together, half-working, slow Emacs setup.

And then later:

> Improve Tramp performance to match the experience of using terminal Emacs via SSH, or VSCode’s Remote Development.

Well for what it's worth, here is something about VS Code LSP and embrace-extend-extinguish.

https://news.ycombinator.com/item?id=25719338

This isn't about LSP but specifically pylance. Let's not confuse the issue.

(Incidentally, I don't even use lsp on Emacs, although I may give it a try).

I think the thing is that pylance is a python LSP. And it's proprietary. So they embraced python LSP, extends it so that the additions are proprietary. And pylance might become the defacto python LSP. Typical EEE. Python is hugely popular, it's everywhere - so even if one hates it, might end up having to use it.

Also the remote extensions are proprietary [1]. This has been discussed on HN before.

[1] https://github.com/VSCodium/vscodium/issues/240

> So they embraced python LSP

They did not embrace LSP. They invented it. LSP came from MS.

> And pylance might become the defacto python LSP.

Nothing is preventing someone from creating another python LSP that will work with the LSP tools. MS is not unique in this. Jetbrains makes proprietary products that are well embraced by the Python community.

> LSP came from MS.

Thanks, today I learned.

Yeah anyone is free to create, same as anyone is free to create remote extensions for VSCodium. So far nobody seems to have done it. Even if somebody does it, it might not match the quality and features of MS extensions.

MS has a history of EEE. Jetbrains doesn't, and as far as I know they are no bullshit no dark patterns high quality.

I get where you're coming from. It's just amusing that many people talk about how great it is to use LSP with Emacs, but are simultaneously recommending not to use MS tools :-)

If one is concerned enough not to use VSCode because it is MS, then one should also not use LSP.

LSP is great. The thing about VSCode is dark patterns. VSCode is great, one sees that it's MIT licensed, downloads it uses it and is like wow nice. After a while realises that the official build is not FOSS licensed and contains telemetry code. So one finds 'VSCodium' which is a community port without telemetry. You carry on working but now remote things are not working. One looks why - the only reason is MS made it proprietary. Remote is essential for lots of developers. One feels f*cked by MS. Few years ago, Github's 'Atom' editor was getting popular. Then MS bought GH now Atom reduced to atoms - can't see it anywhere - though getting updated.

> They did not embrace LSP. They invented it. LSP came from MS.

I don't think this changes the issue: EEE became CEE (Create, Extend, Extinguish).

This always comes up. How can we still not edit a remote file via ssh using whatever you want!?!

I need to make a conscious effort to stay the hell away whenever this comes up here on hn. It's not the only topic that does this, but it's by far the least productive one, lang wars can at least be educational.

I guess, given how evil-mode just gets better and better every day I'm not really seeing many people moving in the other direction, at least based on the blog posts.

No shade on Vim, people like it and are productive in it. I see it like using Sublime Text, lots of people can get away with it, but I need more doodads in my editor.

And hey, nobody is like "Notepad++ vs. Visual Studio", which I think kinda matches the mismatch (or maybe "Notepad++ vs Atom" or something)

Here's the thing, though. I don't use Vim as an IDE. I use it on live servers to change configs / scripts / app code (don't tell anyone) quickly and efficiently. I don't think "extra doodads" would help with that, and I'm not sure I'd want to manage those dependencies on my platform anyway.

If I'm actually developing something that's part of a greater whole, then I'm using a fully fledged IDE like PyCharm (but with the VIM emulator plugged in for when I need it, of course ;-D).

Likewise, no shade at Emacs, though. Several of my favorite colleagues use it!

Changes to PRODUCTION app code on server?! I’ve seen this happen once or twice at my current company. Not the best of times...

Everyone has a test environment. Some are lucky enough to have a separate production environment.

Contrary to what many might expect, Emacs tools are quite good for performing sysadmin tasks:

* TRAMP for remote editing. It's more powerful than Vim's netrw remote editing capabilites and can handle root-owned files on remote servers. It's so extensible there's even a package that allows you to edit files inside Docker containers running on remote servers.

* Dired. It's the best text-based file manager out there IMHO, and it integrates very nicely with TRAMP.

* Org mode. It can be used like Jupyter notebook, but is far more powerful. You can write each code block in any language you choose, pass data between them, and make each of them run on different servers. This is very useful for sysadmin tasks especially in professional environments because it allows you to document each step in a reproducible manner as you're executing it. You can then just share the org document for your cowokers to review.

I personally use Vim for coding and Emacs for non-trivial sysadmin tasks.

One of our oldest and proudest flame-wars.

In 2001, Slashdot held a poll for Best Flame War. [0] The winner, by quite a margin, was Operating System, but the text editor wars (presently being fought at [1]) weren't listed as an option. Personally I'm also rather fond of the tabs-vs-spaces debate.

[0] https://slashdot.org/poll/699/best-flame-war

[1] https://news.ycombinator.com/item?id=26431864

From

>> Debian's Vim maintainer switches to Emacs - https://news.ycombinator.com/item?id=341492 - Oct 2008 (32 comments)

He warned me I should switch from vi to emacs because prolonged vi usage causes hair loss. :)

Maybe, but prolonged emacs use causes carpal tunnel syndrome!

Only if you don't use a keyboard the way it was intended. For example, Ctrl-c should involve both hands. If you press Ctrl-c with only your left hand (there's a reason your keyboard has a right Ctrl), you will gradually hurt your wrists. Emacs can accelerate this, since a lot of things begin with Ctrl-x, assuming that you never use the right side Ctrl.

I have never had carpal tunnel-like symptoms yet, though I just realised I've only used left ctrl for the past 10 years. I'll definitely be more mindful of that. Do you have any more resources on avoiding common typing pitfalls, or specific wrist movements one should avoid while typing? Should capitalising your sentences be a two-hand action as well, considering I normally only use left shift?

Macs don't have a right Ctrl, unfortunately.

Reply on news.ycombinator.com