The reason it bugs me is that popularity drives what will be supported by companies. I used to have plenty of linux and Emacs support from official helpdesk channels. In my last several jobs, not at all. At my current job, even though we rely heavily on linux servers and there’s a strong minority of Emacs users, the company (over 300 engineers) mandated that all support for configuring our in-house build tooling and monorepo tooling will be 100% Sublime on Mac, no support of any kind for Emacs.

In one company, the primary language was Scala, and one of the primary Emacs tools for Scala is Ensime. But the company had its own bizarrely wrapped version of sbt running inside of pants tasks, so without explicit support from IT, it was not possible for a developer to use Emacs+Ensime for that Scala codebase.

I am perfectly happy for people who use these UI-heavy tools productively. But the marketing shtick attempts to raise it in popularity and promote it, like this very paper’s recommendation, seem harmful to me.

Code tooling should be extremely fractured, bespoke and customized, by its very nature, and that should be embraced and supported. Instead it seems like PR battles and a rise of (IMO) ineffective proprietary tooling.