Google deprecated external access to its IMAP due to “security reasons”

Karpathy posted a classy coding video lecture in which programming has been done entirely from the default Mac OS browser (doing everything in a web-interface to a Jupiter notebook).

Corporations want us to stay in their (and only their) browsers all the time (in many different tabs) and never leave, so they can collect all the data they want.

This may be “the future” of computing, but not for me.

The biggest complain about the most advanced open-source solutions based on GNU Emacs and Neoivim is that they require too much time to set up and configure – “we have some work to do” – they said.

Yes, everything is pre-defined and pre-configured in the so-called webapps.Services like Github and YouTube even have their own browser extensions, with nice keyboard shortcuts and what not. Updates and bugfixes of corporate web services are being rolled without you even noticing..

Yes, compulsory tweaking of one’s complex configuration is, perhaps, the most common way of tricking oneself into procrastination – doing unnecessary but dopamine-rewarding simple tasks instead of hard/boring required ones – being busy with nothing,

This, however, is superficial. The main point of never leaving Emacs is not in being a clever member of an “elite”, but in minimizing unnecessary context switches, and thus in reducing the cognitive load and the number of inevitable distractions and restarts. In short – to stay in the same familiar uniform working environment, just as Symbolics envisioned it back then.

The greatest enemy of open-source solutions is over-configuring. and not enough delegating.

Technically, the problem is in breaking the abstraction barriers, literally (using improper leaky abstractions which expose implementation details) instead of just using declarative embedded DSLs. To understand and realize this fact requires some level of sophistication.

Ideally, we have to just use declarative DSLs of, lets say, Doom Emacs, and it will never break with the next update (at least in a theory). The only configuration is by enabling the modules (of corresponding components) we wish to use.

:lang
emacs-lisp
data
agda
coq
common-lisp
(clojure +lsp)
(json +lsp)
(yaml +lsp)
(sh +lsp)
(lua +lsp)
(python +lsp +pyright)
(julia +lsp)
(sml)
(erlang +lsp)
(ocaml +lsp)
(haskell +lsp)
(fsharp +lsp)
(scala +lsp +metals)
(rust +lsp)
(markdown +grip)
(latex +cdlatex +latexmk +lsp)
(org  +gnuplot  +hugo +pandoc +pretty +roam2)
:email
(mu4e +org +gmail)

…aaand wallah, just like that…. In reality, however, things are a bit more complicated. Every update will potentially break your configuration by changing arbitrary things – no one promised any stability of interfaces within Doom-Emacs or even Emacs itself (at the ELisp level) – it has to be “dynamic” after all.

But I think you can see the potential – literally everything within the same, familiar, uniform text-based extensible environment.

Latex and Org-mode are the obvious choices – the way of processing (working with) a symbolic information and producing documents.

The key part is that email (mu4e), a knowledge-base (org-roam2), the converter (pandoc) and web publisher (hugo) are all in one place.

There are also readers (including for .pdf) and even a rudimentary web-browser, good-enough to read HTML documentation (as in Rust).

Add to this spell-checking, formatting, completions, snippets and nothing could match this power. Again, it is just like a Symbolics Lisp-machine.

What is crucial for reducing cognitive overload and unnecessary context switches is the uniformity – the same keyboard shortcuts across all buffers (navigation, marking, copying and yanking completions, snippet expansion, etc).

The same appearance of the same or similar (related) things across all kinds of buffers is another major factor. This is what is behind the overall “magic”.

The take-home principle is sound and even universal – do not break abstraction barriers (or use improper ADTs). Use the use-package DSL at least.

Your configuration should be actually small and mostly declarative - you don’t have to redefine every single variable (the defaults are almost always OK) and reconfigure all the packages (the authors of the Doom Emacs has been done a lot of work).

Doing everything in Emacs is still a dream, but it will be actually an improvement when you simplify and actually understand whys and hows behind your workflow and how your time being wasted on context-switches and restarts.

Last but not least, a versioned (ability to examine all the changes as diffs) semantic knowledge base (as a Wiki or a org-roam2 base) along with the source code (obviously versioned) is what one actually needs.

Having a structured text (mostly paragraphs and plain lists ) in org-mode (with embedded LaTeX, math and code block) as the source for storing in files and for conversion into other formats is the main objective.

This will “pay back” eventually (once your workflow stabilizes) and you will never look back to any web tools or IDEs.