One's personal transformation, changed perspectives, or new capabilities are real empirical evidence - just not the kind that satisfies scientific methodology's requirements for generalizability.

I never even hinted at attempting to prove it to be universally paradigm-shifting for everybody, but I can certainly vouch for its profound impact on thousands of users based on their direct experience.

It isn't a hobby, because Vim and Emacs allow me to perform in a way that I consider far more enjoyable, productive and satisfactory than I ever had before them. That is of course on a personal empirical basis - I cannot promise them having the same effect on anyone else.

In my opinion, after many years using many different tools, techniques, ideas and methodologies, frameworks, approaches, systems, platforms, workflows, philosophies, paradigms, strategies, practices, concepts, models, theories, and experiments, I personally find these two to be exactly the paradigm shift — in comparison to my prior experience when I didn't have them.

But let me be more specific - the paradigm shift I see is not in Emacs or Neovim as tools themselves. The paradigm shift I sense is in the grand ideas behind these tools - modal navigation and Lisp.

I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time. I wouldn't know - I never practiced mediation for long. And that time required to see the shift can differ for every person - some may grok it quickly, for some, it may take decades without ever even clicking.

Also, you're wrong about "upgrading one's workshop" - it's a misconception that longtime Emacs users constantly have to tweak their configs. My config for example is pretty stable; I often make changes to it not because I have no choice, but because the task at hand calls for it. I write a lot of Lisp because it's an instrument for achieving specific goals and solving specific puzzles - work for which I get paid real amounts of real money. I get paid to use Emacs, not the opposite. So, no: definitely not a hobby.

They would if there was a bit more GUI introduction. Seriously functional menus and visual indication of modes. With hints from graphical to the faster keyboard sequences.

> I honestly don't know why more people don't gravitate towards these ideas. Perhaps, because these ideas are kind of like 'meditation' - people say one can only experience the mind shift after practicing it for some time.

idk this reads a lot like tl;dr: it's a hobby.

What's a "hobby" anyway? As the one you commented on, I have also been programming for a very long time. And why do I continue to do that, instead of changing to some management role? The answer to that is that I enjoy programming. I enjoy making tools to make the tools to create the thing I want to create, and to have enough stuff I want to create, I have a job which provides that in abundance. There are no hard borders between "hobby" and "job". It's a useless distinction in this case.

You know what really makes Emacs different than other editors and IDEs? Consider many ways one can transform selected text in VSCode. Let's say there are maybe 3-4 ways, with some extensions it can get to, I dunno a dozen?

Now consider that Emacs allows you virtually unlimited ways of doing the same thing. Because there are virtually unlimited ways to program that behavior.

In VSCode, you'd be clicking buttons and using shortcuts. Imagine if you had virtually unlimited number of buttons there? For different ways of running a command. That would be insane, right?

Well, here comes the argument if VSCode's (default) way maybe actually better? Some may argue about cognitive overhead - flexibility isn't free after all. Some programmers prefer tools to be tools rather than clay, yeah?

That's totally okay, I'm fine with all that. I'm just seriously baffled as to why Emacs is such an underrated and misunderstood tool. Why don't more programmers even attempt to try it? If you are a programmer, for sure, you should be, at least to a certain degree, curious about the ultimate programmable environment, no?

And don't bring the argument that non-emacs things are also "extendable". In virtually none of them can I open a buffer and add yet another way to transform selected text. Right there, without even saving that code in a file.

For an example of a system that I think is probably just as extensible as emacs, look at TiddlyWiki. If you really want to, you can add in arbitrary JS and even the main tiddler edit form is itself a tiddler that can be customized as much as you want.

Anything that runs on a computer is a program; by definition it is a "programmable" entity. It's only a matter of the degree of intentional programmability - exposed interfaces, APIs, scripting languages, or configuration systems that make modification practical and supported.

From my perspective as an Emacs user, where I can extend virtually any part of my running system by simply evaling some code in a buffer, without having to save, lint, link, compile, publish or restart - an extreme degree of intentional, designed programmability.

From that perspective, VSCode in comparison pales into looking rather constrained and bureaucratic, making it, personally for me, virtually not extendable - I have close to zero incentive to even try. Don't get me wrong, I would use it for certain tasks; it is an excellent tool, but I don't think it ever would become my main instrument - it will just annoy me to death to deal with it on daily basis. Joyride looks promising for making the experience smoother; still, it feels more like a band-aid.

So, yes, once you truly experience the genuine extensibility of the malleable nature of a Lisp-based system, you would completely rethink your entire understanding of programmability of things. I write code, my main instrument must be easily extendable through Turing complete coding mechanisms, not through structured data in json or xml; nor through clicking buttons or dragging boxes around.

First definition says "it's a horse", then there's another:

> Any favorite object, pursuit, or topic; that which a person persistently pursues or dwells upon with zeal or delight, as if riding a horse.

Sure, in that sense it can be characterized as a hobby. What's the opposite of a hobby? Well, it's either "work", "chore" or "obligation"— all three kind of fit for my example. I use Emacs at work, for work, to do stuff I get paid for - check! It sometimes feels like a chore - well, what tool you use everyday doesn't? Sometimes you need to update it, delete stale cache files, reinstall, fix dependencies, etc, so can feel like a chore - check! Whenever I open-source some piece of code that extends Emacs, I have an obligation not to break it, etc. So the third one fits too. So, like I said - not a fucking hobby.

Shall we continue quibbling over words, how what reads to you is not what I meant and maybe even discuss how semantic meaning of words may change due to interlocutors' backgrounds, age, mood or the current lunar phase, or do you have some other kind of nitpicking in mind?

I guess the path to Emacs was more of a possibility/probability earlier in my career and I might find it later but for now I'll alt+tab to the browser and/or open a new tab when I need to look up any etymology and stick to navigating around Visual Studio like a pro while they still pay me to do it.

Like you, though, I work in orgs that are very Windows heavy, so I tend to use it more for my personal stuff rather than in my day job

Well, just like I said - you're not getting it, we're talking past each other. It isn't about a "single interface" - not about cramming everything into one window, it's rather about seamless workflow integration. It's like having a command center that orchestrates your existing tools, rather than replacing them. The power isn't in the interface - it's in the programmable glue between your tools.

You say: "I'd open a new tab if I need etymology..." Sure, on the surface it feels like a fair point. However, when you have the ability to request something from any tool or service "at-point", right in the middle of typing a sentence or solving a specific task - it simplifes so many things, and you tend to use those tools more. It's basic psychological phenomenon called 'convenience effect'.

But that's the only half story of it. Here's the practical example I often use as an evidence. I use Google Translate, alright? On its own there's nothing special about it - other editors and IDEs, also probably have integrations like that if not even nicer with GTranslate or some other translating service, right? Yet check this out. I'm learning Spanish, and when I want to translate something like "Colonel was born in 1968", what would GTranslate do? It would translate the text leaving the numbers intact, and that's totally expected. But guess what? I am trying to gain better familiarity with numbers in Spanish, I really do need to see them in their written form.

How long do you think it took me to solve that little personal discomfort? No longer than fifteen minutes. First, I needed to find out what actually was sending the payload to GTtranslate endpoints. I launched Emacs' built-in profiler and performed a task of translation. I found the function. Then I advised it. Advising is an Emacs Lisp mechanism to prepend, append or override the behavior of any given function - built-in or third-party. So, I figured that if I convert the numbers to text first, then send the payload with that text instead of numbers, it will work exactly as I wanted.

I couldn't even find an implementation of numbers-to-word in Elisp, and I didn't want to spend any time trying to write one. So I delegated the task to an npm package. Now, my advising function adjusts the behavior of 'translate' function (that sends the payload) by detecting the numbers in the text and then runs nodejs, changing the payload, so GTranslate spits out: "Coronel nació en mil novecientos sesenta y ocho"

Did I have to write my own browser extension for that? Nope. Did I have to figure out how GTranslate endpoints work? Nope - I didn't even have to open their documentation page. Did I have to re-implement the entire command that sends the payload? Nope - I just needed to tweak one, specific aspect of it, with extreme granularity - the body of the function is ten lines long. If that's not some blackmagickfuckery, I don't know what that is. Maaaan, I wish someone has showed me some shit like that when I was much younger.

> Perhaps I'm just a little too lazy to learn that stuff

Here's a thing about ideas - and don't consider Emacs as a concrete tool, a mere editor, but think of the fundamental idea behind it. You don't need to "learn" ideas. You just have to cultivate some level of curiosity about them. Sure, you may later have to spend considerable time learning the concrete tools behind those ideas, but absorbing the idea is the first step.

And grokking basic fundamentals about the idea of Lisp is pretty trivial - one just needs to learn mainly two things - structural editing and REPL-driven development. Some may argue that even those are not specifically necessary to begin the journey.

You know how the "do" in Taekwondo, Judo, Aikido, Karate-do stands for "path" or "way"? There's no truly "learning" Aikido, you either practice it or you don't. It's a lifelong practice rather than something you "master" or "complete." The idea of Lisp is similar - it's not really something you "learn" in the traditional sense and then move on from. You practice thinking in Lisp.

The fundamental principles of Lisp - code as data, the power of the REPL, recursive thinking, functional approaches - these aren't just techniques you acquire. They become a way of approaching problems, a mindset you cultivate through practice. The practice never really ends - it just deepens.

I haven't done any martial arts, so I'm just spitting words here, but I bet, if I ask anyone who practiced Aikido for a long time if it makes their lives any better, I bet they'd tell me some koans about zen master pouring tea or some other shit that I'd immediately dismiss as complete bullshit, so I wouldn't blame you if you take my words the same way.

> I guess the path to Emacs was more of a possibility/probability earlier in my career

Just like Aikido welcomes practitioners at any age or stage of life, Lisp is always ready for new practitioners. The fundamental principles align here in more ways than one could imagine - "the journey is the destination", "wisdom over athleticism", etc. Many people discover their deepest appreciation for Lisp (or Aikido) later in life, when they have the patience and perspective to appreciate the subtleties. The best time to start is always now.

FWIW, Org Mode is what a native Emacs user might reach for as alternative to Jupyter notebooks: https://michaelneuper.com/posts/replace-jupyter-notebook-wit... That doesn’t imply that you should both try Emacs and replace Jupyter! Just be aware that if either you are using Jupyter for your own reasons or working with like-minded team there is an alternative which may be preferable for your use-case.

You could probably get it working locally for yourself but in corporate environments it can be annoyingly hard.

org-mode is a better choice, but note that it's not specialised for Python (which is good and bad) so you may need to wire up some stuff (I mostly use R for personal stuff and that works very well).

I haven't used terra.bio, but this works for any text box, so should just work.

Of course, emacs has modes for Jupiter and other notebooks, as well a Org Mode and a way to run code from Org Mode to function similarly to such notebooks, just you can execute code in any language, not just python, and can then immediately use the results in the rest of your file, including tables. You can even reference tables in your code blocks.

https://www.youtube.com/watch?v=ud3Gmxg5UZg - Browsing Reddit and HackerNews In Emacs (7 minutes).

If you don't want to watch it:

https://github.com/thanhvg/emacs-hnreader - for browsing HN.

https://github.com/thanhvg/emacs-reddigg - for browsing Reddit.

https://github.com/agzam/consult-hn - for searching through HN.

https://github.com/agzam/browser-hist.el - for browser history.

It saddens me how people of Emacs often reject vim navigation outright, just as the broader programming community tends to dismiss the fundamental ideas that drive Emacs.

Neither represents a dogmatic religion, nor do they embody fundamental, conflicting truths about computing. No one needs to choose one and commit to it exclusively - they are simply tools, built upon some brilliant foundational concepts. Understanding and utilizing the ideas behind them may literally transform your life in mind-blowingly positive ways. I wish more people contemplated this profound truth, instead of thinking they have to stick with one, particular way of things.

Here's one thing about vim-navigation. Gary Bernhardt (the WAT talk guy) once said: "There's no vim-mode there's only Vim" and he was right - to a certain degree. All the different extensions and attempts to bring vim-navigation to non-vim editors have glaring deficiencies - all of them - VSCode doesn't fully vim, IntelliJ doesn't do it comprehensively, Sublime can't properly vim, etc. With one notable exception. Emacs actually vims better than vim/gvim/neovim. I'm saying this with the full-blown confidence of a die-hard vimmer.

The way Emacs implements Evil-mode and its extensions is the ultimate compliment to its design. If there's a model of a plane that can perform a vertical landing, yet never actually needs to use it, I would still love that model over any other planes, even if the feature is purely accidental. The fact that it can do so alone would be great evidence of amazing engineering. Evil-mode is absolutely one of the most celebrated achievements of Emacs, complementing other remarkable packages like Org, Magit and many others.