> Emacs is not just a code editor. It will change the way you approach programming.

This is the most pretentious nonsense I've ever read. Writing code is writing code. God could create for you the most perfect IDE to ever exist, with every feature you know you want, and every feature that you don't yet know you want. Tailored exactly to your needs. But at the end of the day, you're just going to sit down and write code in it.

All I see when I look at people who endlessly tinker with their setup, are people who are spending time things that aren't providing aren't providing value to their customers. I've worked with quite a few emacs wizards. Do they write better code than me? Some do, some don't. It doesn't seem to related to their use of emacs though. Are they more efficient than me? Some are, some aren't. Did they all spend a lot more time than I did to learn how to use their text editor? Yes. Did they all have to tinker with their text editor a lot more than I did to get it working the way they want it? Yes. Have I ever had a problem that I wouldn't have had if I'd invested all the time required to master emacs? No.

In Emacs, every key is evaluating some Lisp expression. You are interactively using Emacs Lisp in a funny sort of REPL. Most of the time you just use predefined commands and they do what you want, but if you know there's a whole programming language there, then you'll see opportunities to take advantage of that sometimes, just like how sometimes it's nice to be able to write a for loop or a pipeline at a bash prompt.

Once you get used to that model of using a computer, it feels crippling to use applications that you can't easily program in on the fly. It's the difference between having a full programming language and a bunch of buttons you can press, and it's for something you're going to be doing a lot for a long time.

I don’t doubt that a skilled Emacs user would be more efficient at editing text than I am. But I don’t have any problems with my ability to efficiently edit text. The problems that I get paid to solve are ‘how do I effectively deliver value to my customers’ and ‘how can I design solutions and systems that meet the business’ needs’. The kind of challenges that I have to overcome to meet these goals do not include ‘I’m not efficient enough at editing text’. If I were to reach a perfect 100% efficiency in text editing, I doubt it would have much impact on my productivity, and I know that I would have no impact at all on the quality of my work. My IDE already has a lot of productivity tools, perhaps I could improve that by learning Emacs, but I’ve never seen the RoI in devoting time to that, over devoting time to learning any number of other things that would actually make me better at my job.

> Once you get used to that model of using a computer, it feels crippling to use applications that you can't easily program in on the fly.

Funnily enough, that's how I feel about Lisp itself: I love having a language I can program at runtime, at compile-time, at read-time (and, in a decent editor, at edit-time).

It really makes me wish that there were a decent modern Lisp OS. It'd need some solution to run Firefox and emulate emacs. Maybe when I retire I'll devote my remaining years to that.

I feel obligated to point out that people have run emacs as pid 1 on Linux. That's... some level of lisp OS, surely.

I don't believe they have, in any real capacity. Can emacs reap processes? Is there an elisp binding for every kernel syscall?

I'd be interested to see the results of a survey of how many Emacs users use Emacs Lisp in any capacity beyond cut-and-pasting examples found online into their .emacs or .emacs.d/ configs.

>I've worked with quite a few emacs wizards. Do they write better code than me? Some do, some don't. It doesn't seem to related to their use of emacs though. Are they more efficient than me? Some are, some aren't.

Are they really wizards then? :^)

You know, I am personally much more comfortable with using emacs as an extremely configurable text editor. As time passes, I want less and less to create ad-hock lisp scripts and to debug my editing commands.

That Blub paradox was insightful. However, you do realize that people using Emacs might be Blub programmers as well!

I think you got a point that some emacs users might severly underestimate the power of limited choices and pre-configured workflows. However, as in understood Blub, this is strictly about power of expression. I think emacs is at the top of the foodchain here, at least I don't know a text editor that would be extensible with such easy as emacs.

Same with the LISPs (which Blub is about btw) - Some LISP programs become unmantainable for people that did not write it, but without a doubt, LISP is one of, if not the most expressive language there is.

Funny enough, as I was reading this I was thinking the users and non-users of Blub were switched.

The argument is symmetrical.