Hacker News Reader

Comment by adastra22 | Hacker News Reader

I use Visual Studio Code now for pretty much this exact reason. The only configuration I need to do is to install the right language server extensions for the code I develop, but even this is mostly handled by the "It looks like you're writing Rust code. Do you want to install the extension to handle this file type?" dialog that pops up on first use. Everything is auto-updated, settings synchronized across devices, and default settings are mostly ideal.

Reaping the benefit of everyone else's hard work at improving vscode is awesome. It just gets better over time without me having to do anything except occasionally read about new features in the release notes. Spending hours twiddling in emacs lisp to get things configured just right is just wasting my limited time.

View on HN

You also get the benefit of everyone else’s hard work with Emacs. One of the differences is that it’s such an established ecosystem, that instead of individual extensions just getting better, with Emacs they’ve yielded shared abstractions that make _new_ extensions trivial and much more consistent than with VSCode (which is nevertheless still an excellent editor these days).

I also don’t understand why people think spending time on the tools they use to do work is wasted. You either believe software creates value or you don’t. If your time is so limited, eliminating toil seems essential.

I think my time is better spent improving my build and deployment environments instead of something like customizing my text editor. More of my work is in tying command line utilities together Maybe I don’t know what hardcore emacs use is like.

Yeah, I suspect the fundamental disconnect is that some people think of the terminal as the dev environment and something else is used purely as a text editor. Emacs edits text, but it’s an environment beyond that (one which happens to also contain a terminal).

I think you're missing the point. With vscode I literally don't have to do anything. It just magically gets better every time I start it up. Most people I know who use vim or emacs don't have it setup to auto-update extensions, and even if they did they wouldn't automatically fetch and configure those new extensions you mention.

What I'm objecting to is the very idea of a highly customizable editor.

VSCode is a highly customisable editor.

> It just magically gets better every time I start it up.

Some of my coworkers violently agree, but at least 20-30% get annoyed when autoupdate removes/ changes some feature (pane splitting recently I think) and they have to adapt their workflow.

> If your time is so limited, eliminating toil seems essential.

The counter point to this is usually:

What exactly is your toil as a professional software developer (or associated profession) that is eliminated with a "better"[1] editor in 2023?

Refactoring is more powerful with an IDE, for mainstream languages. For non-mainstream languages 95% of what Emacs enables can be done using multi-cursors and a macro language built in to the editor, and we're in 2023. Those kinds of editors are a dime a dozen :-)

Editing data dumps or whatever is probably better with an advanced editor (I generally use Vim for that). But it's such a rare occurrence.

Writing code is super easy in an IDE.

Most of my toil is unnecessary meetings, unnecessary reporting, unnecessary social stuff. Emacs can't help with any of that.

* * *

[1] To note, "better" is strictly a claim. I'm quite sure there's no peer reviewed study that can prove conclusively that Emacs/Vim users are more productive than non-Emacs/Vim users, just due to their usage of Emacs/Vim.

    For non-mainstream languages 95% of what Emacs enables can be done using
    multi-cursors and a macro language built in to the editor, and we're in
    2023. Those kinds of editors are a dime a dozen :-)

Are they? Multi-cursors, sure, but what other editors have a macro language that combines the power and accessbility of emacs lisp? The only other one that comes close is vim, and, as many critiques as I have of emacs lisp, I can firmly state: it's a lot nicer to use than vimscript.

But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.

> but what other editors have a macro language that combines the power and accessbility of emacs lisp?

Is it accessible? Why would I want to spend time learning the idiosyncrasies of a 40-year-old editor to write something that I might use once in a blue moon?

I have other, more interesting things in life.

There are many text editors extensible in Lua or in Python. They generally don't allow messing with the innards as much (Firefox proved that's a double edge sword with its extension, it's not an unalloyed good).

https://micro-editor.github.io/index.html

https://lite-xl.com

https://neovim.io

https://code.visualstudio.com

http://www.sublimetext.com

And Emacs Lisp doesn't feel super accessible to most software developers under 40. Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.

> But other than emacs and vim, which other editors allow me to interactively automate portions of my editing workflow? All the other IDEs and editors that you've cited, like IntelliJ or VSCode require you to either find or write a package. That's a much bigger step than just interactively evaluating some lisp to do a one-off thing.

Devs generally write one-off or maybe reusable shell/Python/... scripts for that. But some of the examples I listed allow you to do a lot of that using Lua.

There are a ton of workflows out there, other devs don't just bang 2 rocks together because they can't automate everything <<inside>> the editor itself :-)

Also, xkcd is always very poignant:

https://xkcd.com/1205/

Software devs routinely fall into this trap:

https://xkcd.com/1319/

> And Emacs Lisp doesn't feel super accessible to most software developers under 40.

Or over 40 (I'm 42) :)

> Almost all its conventions come from a small little island, it's like marsupials in Australia, their own little parallel evolution.

This is a great analogy. And people forget that to program any system effeciently you need to know that system. Not necessarily inside-out, but good enough. A brief look at any emacs config will show you just how many weird and inconsistent things you have to contend with: major modes, minor modes, hooks, global variables, global functions, mode-specific global functions, special lists, non-special lists, and a myriad API calls and functions in between.

Wikipedia says that emacs has 10 000 (ten thousand) built-in commands [1] That's probably on par with JVM :)

[1] https://en.wikipedia.org/wiki/Emacs

The worst part for me is that I wanted a few "simple" UI tweaks with Emacs. I really wanted to use it.

But I wanted it to have a native tab bar and I wanted to move the command bar at the top, with dropdowns instead of "expand-ups" (turns out, I read right-to-left, top-down, not right-to-left, bottom-up. You can't have either of those, in the world's most extensible editor :-(

Emacs has had tab-bar-mode since 27.1 and tab-line-mode since 27.2. As for the drop-down minibuffer (I suspect that's what you mean by "command bar"), you can use something like vertico-posframe* and put it at the top like so:

  (setq vertico-posframe-poshandler #'posframe-poshandler-frame-top-center)

* https://github.com/tumashu/vertico-posframe

The "toil" is anything involved in software development that's boring and repetitive. There's a computer right there that's for that stuf. My biggest frustrations come when I'm prevented from bringing the power of that computer to bear on a problem that isn't one of the ones envisioned or prioritised by the makers of my tools, and they didn't think to make it easy for me to extend them myself.

Emacs isn't an editor, it's a (very) rapid development environment for textual UI applications. Text editing is a large class of such applications but there are plenty of others.

Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.

Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.

> Case in point: at work we use a job scheduler with a horrid web UI. I knocked something together in a couple of hours in emacs that eliminated that pain from my life and allowed me to explore our environments much more freely. If more of my colleagues used emacs they could share in the joy. I don't have anywhere near the time I would need to make something they could use without it.

Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing. There are myriad viable ways to automate things.

> Meetings, reporting and "social stuff" isn't much of an issue for me as I've been very clear in every interview I've had that I have no desire to take on managerial responsibilities at any stage of my career.

Meetings, reporting and "social stuff" happen as an individual contributor because you need to sync with customers, peers, bosses, plus customers and bosses also expect you to report your progress. Social stuff isn't going out to lunch or dinner, it' just regular interaction or support.

I'm glad that you get what you want, not everyone does.

I'm just pointing out that there are many ways to happy coding and Emacs is just one of them.

A needlessly crabby response. I don't think anybody claimed emacs was the only way to code happily.

I was just explaining what the "toil" is in my life and how emacs materially alleviates it. The examples you give don't, in my experience, allow a useful interactive UI to be knocked together anywhere near as quickly as it can be done by an experienced user in emacs. YMMV - use whatever tools you like and manage your career how you please.

> Other devs would (and regularly do) just whip up something using shell scripts and command line tools, or write their own CLI/TUI/GUI/web service/app for the exact same thing.

The difference is time of development and flexibility of tge emacs result using the same universal plain text interface you use in emacs every day for me.

True, but you're giving up composability outside of Emacs. Think of CI/CD pipelines, for example.

I mean, you could probably run Emacs as part of your CI/CD pipeline, but it would be a bit... weird?

Yeah, with more experience I have realized that most customization is not better

A certain level yes, but doesn't need to be all, end all

VSCode solves most of my issues.

"oh but in Emacs you can do..." a thing that I either don't need, or I don't care about or I can do using a web service or some other offline program or maybe even a VSCode plugin or a short vim script.

> "oh but in Emacs you can do..." a thing that I either don't need, or I don't care about or

or it's already available in pretty much any IDE out of the box. Most people advocating for emacs or vim usually have no idea what a modern IDE is, and pretend modern IDEs have not surpassed win3.1 notepad in terms of functionality.

Yes, that's a good reminder.

And I agree, a lot of those heavy advocates live in a bubble

Reply on news.ycombinator.com