I think this is a fallacy. If you approach the question of how these people achieve the things they do with a bias towards tooling then you'll come to the conclusion that it plays a big role in their success.

In reality, many of these folks start with a very strong drive to achieve something and then the rest sort of follows. If you want to be a world class musician, start practicing an instrument. Ideally fall in love with music. The rigorous and meticulous practice routine comes later.

In other words: you can have the world's best tooling that gets out of the way, but you're still as unmotivated to do anything as before.

I think it's a cool idea and it sounds like a fun and creative endeavor. I don't want to talk it down. But I also wouldn't want folks to get the, in my opinion, misguided impression that "tooling -> success" is the correct order.

Anyway, I began learning Emacs commands in the Emacs tutorial on that Braille Plus, , and they made sense to me. Unfortunately, Emacspeak only really works well on Linux and Mac, not Windows where all the blind people are. Speechd-el only works on Linux, since it uses Speech-dispatcher. I got Speechd-el talking on Termux for Android last night though, although it was rather laggy between key press and speech. Emacspeak development has paused, though, and Speechd-el seemingly hasn't been updated in half a year. Emacs itself has a lot going on for a normal screen reader to interpret which is why Emacs-specific speech interfaces are so useful.

A few examples:

* On Windows, with Windows Terminal and NVDA screen reader, arrow keys read where the cursor is, but C-n and C-p, C-f and C-b, all that, NVDA doesn't say anything. This is with the -nw command line option because the GUI is inaccessible. * Now, if I do M-x, it does say "minibuf help, M-x, Windows Powershell Terminal". From there, I can do list-package and RET and use arrow keys to go through packages, but N and P don't speak even though I know they move between packages. So it seems like the echo area works. * Programs like the calendar, though, really doesn't speak well with a screen reader. It just read the line, not the focused date. Using left and right jst say "1 2 3 4 5" etc. So custom interfaces don't work well. I shudder to think how it'd read Helm.

Lol maybe I can get AI to make a good speech server for Emacspeak for Windows.

As the years go by one realizes that even these “features” like Org, Dired, etc are just illusions in some sense. They’re just Elisp code someone else wrote and put a name on. You can take or leave them or write your own code that changes/advises/customizes them.

It’s all up to you. You don’t need a blessed “plugin” architecture, some PM at IntelliJ’s permission etc

At some point one realizes the “visual shell” nature of Emacs. Every single piece of text on screen can be programmed to “mean something” (see also: “recognizers” from human interface research) and have actions taken on it either by the editor itself, or external processes / scripts you call with a command. If it’s common enough, make a key binding. It’s your house, do what you want

Depending on how you set up your environment, you may never have to look at text again that you do not have this level of power over. You are no longer at the mercy of “application developers”

I’ve been using it since 2005. Guess how many of 2005’s popular editors even still exist

My recommendation to anyone trying to actually learn is start with the full vanilla config, weird default keybindings, etc, go through the built in tutorials, and only add things to your config that you write and understand yourself. Understand it in its own terms. The plethora of packages, etc have “cool features” but impede learning by adding mountains of complex dependencies that are opaque to the beginner and cause confusion IMO

Basically the notes have the same format that org-mode uses to save notes placed in the logbook. But you can also make them as individual TODO headings or whatever. It's all plain text anyway.

I try to empty the inbox.org every morning, I typically have 20-30 entries to go through. Some things matter and are revised and refiled appropriately. The rest gets dumped into a chronological log file for just in case.

edit: btw, it would be cool if I also made a version that would append the content of the phone's clipboard to the transcription, so that I can also catch links and/or bits of text. Or maybe even multimedia, thought I am not sure how I would accomplish that.

What's your take on opinionated distros like Doom Emacs or Spacemacs?

I've been doing my daily journaling and task management on Emacs for while now, using Doom Emacs. Rationale was that it'd be mostly pre-configured to a sane standard and that, for actual text editing, I'm a long time vim enjoyer, so evil mode is great there.

However I always feel that when I go beyond the safe borders of the preconfigured, leader-key-accessible realm, I'm quite lost. I don't have good intuitions on how to interact with more raw parts of the system.

And I do want to venture further, so I'm feeling I need to get re-started with one of the recommended tutorials/books.

Should I start fresh Emacs install instead?

PS: I've coded in a bunch of lisps in the past and I have already done a bit of customization on top of Doom, so I sort of know my way around, but I'm just not comfortable I guess.

> Emacs is single threaded, therefore if anything in the system hangs, the whole system hangs

For development work I haven't found this to be an issue. Generally when coding I use very few X apps - pretty much just a web browser and maybe occasionally a PDF preview or docs browser. I don't think I've ever had a problem with the single-threaded behaviour blocking window management there. (And as an aside, while proper threading would be nice for things that actually should be concurrent - such as EXWM's duties as a window manager - I massively prefer emacs' synchronous processing of input over the JetBrains horror of pressing a key combination and then having to wait for some asynchronous UI behaviour to occur, with different outcomes depending on whether the next keypress occurs before or after the UI behaviour the first one triggered.)

For other, more GUI-focused activities I just run a separate (wayland) session.

> It is the ultimate sharpening of the axe before chopping the tree[1]

But if part of our axe sharpening is listening to music, reading email, catching up with your feeds and so on then perhaps we need to take a step back and ask if we're just invading our working thought-space with boondoggles.

[1] "Give me six hours to chop down a tree and I will spend the first four sharpening the axe.” - apparently Abraham Lincoln.

As much as I love the idea of declarative builds, I’m struggling to justify the investment of learning and maintaining Nix for an individual setup. I’ve dabbled with it and mostly encountered footguns.

Whatever makes a nice, clean slab is what I’m after.

imho exwm is imho fundamentally flawed, especially when running emacs or doing emacs stuff inside it. You end up in a battle over keybindings, etc.

I think a better model would be a window manager in a separate process that your emacs elisp processes can communicate with over IPC.

Now, this is not a "we need to favour vim over emacs". I think this is a stupid war, the vim versus emacs war.

What I mean is ... basically most editors do almost the same exact thing. They look at some buffer for a file and help the user modify this. There is a finite number of operations possible. Why do people keep on re-implementing basic things here? Why can it not be solved once and for all and then everyone uses that implementation?

We really should have that; and then people can decide ON THEIR OWN what kind of editor they want to use. Many years ago I started with crimson editor as my main editor on windows. I have since then hopped to many other editors. My favourite one was oldschool bluefish in gtk2. I am not saying it was perfect, but I found it much easier to go on my poor brain than e. g. remembering all vim shortcuts. But, it would need xorg + gtk2, so if that is not available, then I can not edit things - that's bad. That was (and still is) also one reason why I use e. g. nano. But this in turn requires ncurses and I hate ncurses with a passion (nano is great though, I can recommend it for quick ad-hoc editing; for larger things it is not quite as good, but if you have to just change some value in a config file, nano is really great).

Even then I used only like 20% of what bluefish offered (the newer bluefish releases are also nowhere near as good as the old releases, also because GTK really sucks nowadays). I'd like to cherry-pick on my editor and declare what I want it to be, without needing to implement everything on my own. Why can't we transition into this? Why do we need to reimplement everything almost from scratch? That just makes no sense to me.

We live in the age where AI autogenerates code (which they heavily drew from stealing people's code). Why can't AI autogenerate the best, most perfect editor/IDE?