←back to thread

301 points nogajun | 5 comments | | HN request time: 0s | source
Show context
self_awareness ◴[] No.45943838[source]
For me, VSCode implements everything that I've always expected from Emacs/Vim.

I've spent years to configure emacs/vim to be a good programming editor. Years, multiple configurations, vanilla configs, space/doom emacs configs, multiple predefined configs for vim/neovim. Something always was broken, something was missing, something was non-optimal just below the tolerance line. Missing features, discontinued packages, initialization errors, bad versions, "known issues", LSPs not starting, packages replaced by some newer shinier package with different usage, cryptic setups that are wrapped in "convenience layers" that obscure details, making it completely incomprehensible.

Then VSCode came and it had everything. Remote development is trivial through ssh. Completion simply works without any setups. Massive number of languages supported. It's a mess inside, but the UX is more stable and more consistent than anything I've ever seen in emacs/vim. Sometimes something breaks, but I can restart the window backend without closing the app easily.

This is really telling. Despite dedicating years to configure an "infinitely configurable" system, I wasn't able to achieve anything stable. I've given up and i just use VSCode daily. This way, I have more than I ever had with emacs/vim.

The only thing I have from vim that's left is the keyboard layout. For this, I'm thankful to Vim, but the editor itself for me is just for editing config files. I don't even have Emacs installed anymore.

replies(2): >>45943930 #>>45948876 #
roman_soldier ◴[] No.45943930[source]
This, most people that try and use these legacy editors spend most of their time configuring it get it to be as good as vs code and usually fail. A lot of wasted time and frustration when one click gives you a perfectly modern fast editor with a smorgasbord of great extensions that just work. I do use vim for quick editing of files in the terminal but never for serious work.
replies(2): >>45944066 #>>45949132 #
omnicognate ◴[] No.45944066[source]
Not sure where you get "most" from. Personally I've found the exact opposite: Despite having been forced by work constraints to use most major IDE platforms at one point or another, sometimes for years at a time, I always come back to emacs with great relief and find it better in pretty much every way. I know better than to assume my experience is that of "most" people, though.
replies(2): >>45944955 #>>45952325 #
1. self_awareness ◴[] No.45952325[source]
I've installed emacs now on ArchLinux Wayland system and its window refuses to resize (on purely default settings), and freezes the contents until I move it. Very refreshing indeed.

I bet this is some kind of a known issue, but that just reinforces my original point above.

edit: yeah, here it is: https://bugs.kde.org/show_bug.cgi?id=509871

I mean, how it's not an Emacs issue if it only happens with emacs?

replies(1): >>45954582 #
2. iLemming ◴[] No.45954582[source]
> I've installed emacs now on

I never had what you describe. The variability there could be almost random - which version of Emacs you're installing? How are you installing it? Are you trying to build it from source? What renderer are you using - there are several: Lucid, Motif, GTK, NS, W32, Haiku, Android, Cairo, Pgtk. Perhaps it's installing different renderer instead of using pgtk. Maybe it's not a bug with Emacs but with the package that bundles it for your distro?

> how it's not an Emacs issue if it only happens with emacs?

It does seem to be an Emacs issue. But it is a specific issue that happens on the combination of your hardware and your OS configuration.

replies(2): >>45954729 #>>45955084 #
3. ◴[] No.45954729[source]
4. self_awareness ◴[] No.45955084[source]
Yes, I'm always having "special" problems. It's probably due to the fact that I jump around platforms a lot between Linux, macOS and Windows, mixed GUI and ssh.

For example, macOS emacs always starting at the bottom of the window stack instead of the top. macOS emacs having different font notation than Linux emacs, so maintaining common config is hard. Terminal emacs -nw having its own set of rules, and M-x needs to be addressed with ESC x. Etc, etc.

replies(1): >>45956268 #
5. iLemming ◴[] No.45956268{3}[source]
Yeah, I admit, fair complaints. Emacs can be tricky to render things exactly how you like - I use it on Mac, Linux, GUI and terminal and do have different semantics for each.

The tradeoff is that Emacs does let you handle it all - you're not forced to accept platform defaults like in some editors. Most editors have their UI/behavior largely baked in by the platform. You can customize colors and keybindings, but the fundamentals - window management, font rendering, how system keys work, terminal integration - are mostly dictated by whether you're on Mac, Windows, or Linux.

So when you have mac Emacs behaving differently than Linux Emacs, it's not because the software forced you into that corner - it's because the underlying systems are different and Emacs exposes that difference rather than hiding it behind a unified abstraction layer.

Emacs gives you the rope to make things consistent across platforms, but also the rope to hang yourself. Other editors pre-tie the knot for you.