Pondering about forking

[xparq]

Vision, priorities...

Before even starting to review existing forks, the basic goals, priorities must be set straight, to have a sharp vision for a direction/strategy I consider "winning". (I might be wrong, of course, but I still have to have something (the best intuitive assessment I could have) to start out with, as a baseline to check against, to recognize if/when I'm wrong.)

A clear decision: not just an Emacs "flavor" (of "emacsen"), but an Emacs successor!

A different species. With interbreeding may or may not being possible...
Heck, even a completely new editor, with no ancestry, like VS Code, could become immensely successful, in just a few years!
Compatibility would of course be nice, and will be a priority, but if one only wants to run 100% emacs packages -- a perfectly compatible solution already exists for that...

(BTW, any fork that has daring claims of reform, tags like "new generation" etc., yet claim to be faithful to "true Emacs heritage" is a direct oxymoron, and hints a lacking/unstable vision, or not really being an Emacs successor. I wonder where emacs-ng belongs. The fact that I've only seen it mentioned in a reddit post (from 4 years ago) suggests that it may be either too weak an effort, having the wrong goals, or just an emacsen. My hunch is that there's still a strong vacuum, so a good project candidate could gain support just by communicating its goals well + some consistent management. -- UPDATE: Hehh, OK, I was spot-on: it's not a replacement... It wants to make existing Emacs "more approachable", by not actually changing it very much! :) )

The vacuum:

The "Notepad++ phenomenon", the "Vim ecosystem", and VSCode, of course... And then all the IDEs. But also the million small contenders, like mcedit, or even FAR's internal editor... And any of the Notepad replacements, or even the "code editors" on Android. And the haunting legacy of the forgotten Multi-Edit, the "Emacs of DOS"... (if it had UTF-8, it could be a very viable thing even today, at least on Windows)

While VSCode is a huge winner right now, it has left behind a huge part of the user base, mostly old-school frugalists, like me, who have no choice but to resort to Emacs, still, even today.

The sheer fact that Emacs just doesn't want to die, is proof that VSCode can't fill all the niches alone. And neither can Emacs.

I feel there's a huge patch -- can't really call it a "niche", for it's actually a gigantic continent of mainstream needs... -- that a combination of most of the existing tools could cover more optimally than the existing ones.

Things to keep

• The perverse level of portability of the tool (cross-platform, and obviously cross-seat). Emacs can work everywhere, even more so then VSCode.
• The perverse level of portability _of the user experience, too including configurations etc._! My config can just be copied over across Windows/Linux, and will keep working!
• Technical frugality: it may not even have that many 3rd-party library deps (last time I checked, an old Reddit comment from skeeto, and his related page suggested so)
• Unparalleled extensibility (well, ME came close in the 90s, with its CMAC language + bytecode, having most of the editor implemented in that)
• Inherent versatility: all the extensions can only work because (on top of) of this
• Tight, comprehensive integration with the host OS (well, if it's a POSIX...), external tools, processes
• Introspection, discoverability
• "Secretly" being a general-purpose computing env., i.e. a glorified REPL
• Organic growth of personal configurations
• Transparent remote editing (over SSH; even VSCode lags here)
• Docs quality!... The existing docs are fantastically comprehensive, but very outdated, tedious and obviously only speak Emacs
• Mature, decent package repos

Things to change

• Steep learning-curve (e.g. no amount of ultimate Emacs-level explorability and self-documenting can replace and intuitive, self-describing UI (see below), or no amount of docs. can make elisp (see below) more approachable than sg. like Python or C; etc. etc.)
• Arcane, outdated, unergonomic UI in today's mainstream environments (GUIs & modern text terminals)
• Not having maximum ergonomics enabled by the default config (distributions like Doom already do this)
  (Obviously, "maximum" is an artificial qualifier here, but I think everyone but religious zealots can intuitively understand what I mean, without defining it.)
• Not integrating very useful (often basic) functionality ubiquitously provided by widely used add-ons packages to the core, again, for "maximum ergonomics" out of the box (and again: distributions do this well already)
• elisp being the default language; as a minimum -- and in addition to dynamic modules -- another extension language is needed. JS & Python are almost a must, but some embedded + extended + bytecoded C would also be (or even something like Vala, for OOP), to attract old-schoolers too, who are not that old-school to actually prefer elisp... (Note that Stallman and others do believe that elisp is a critical factor for the success of Emacs. And I understand why, so I'm not meaning to remove it, but to make it optional!)
• Crippling key translations in console mode: modern terminals have no problem with basic stuff like differentiating various inputs Emacs thinks are the same.
• Better concurrency (as in multiprocessing support, not flat-out multi-threading initially, that would probably require rewriting everything, perhaps in a different language then); see e.g. this nice Reddit discussion
• That "organic growth of bespoke, personal configurations" is rather unguided; it's a recipe for growing a hopeless mess (especially with package upgrades etc.); some sort of configuration control/management would help a lot (possibly integrating some core git functionality)
• Easy "context switching" (chrooting, essentially) for configs & sessions (running a shared config with different users is problematic with the current Emacs)
• Symbolic/virtual keys, to avoid all the trillion packages each individually mapping basic navigation keys to their own haphazard preferences... (This may very well be there already! But then it's incomprehensible, why it's not in widespread use.)
• Arcane, confusing terminology: visit, minor mode (for every single "option", even unsuccessfully reflected in the "mode line"), umm... mode line, point, mark, kill ring, yank, window, advice, truncate line (I've seen even "Emacs influencers" confusing it either with word wrap or scrolling...), diminish, ...

Things why VSCode is not the final answer

(It's risky to start listing points here without a safeguard against self-delusion -- but at least I'm very aware of this...)

• Too high level of (restricted) extensibiliy: you can only work on its plugin API, not much of its internals (like Sublime, Notepad++ etc. -- how much is that true? I couldn't figure out how to "fix" PgUp/PgDn, or just have Ctrl-Up/Dn locked scroll, or tame the over-eager, distracting auto bracket matching (to do it on request only, or at least not be outline rects.; etc.), but these smell like my own lack of knowledge, and may well be possible, albeit apparently far from straightforward)
• Electron...
• Its shiny-object culture of UX. It's insufferable. Even identical C++ symbols have different colors, when in different contexts...
• Yet, you can't do a simple save-session no-save-session switch at will, just by e.g. a simple command-line switch (Sublime couldn't do it either, and neither could SCite -- fascinating!...)
• the MS stronghold: addons must comply, and the repo is only available to VSCode -- vscodium had to abandon and rebuild the entire package ecosystem
• See this video of Stallman himself talking about this very topic...

---

A nice starting point for looking around (+ old forking history) is a Reddit page about forks like emacs-ng, qemacs, remacs etc. (and non-forks like doom), with a great comment (with links) from /u/massive-dose about Stallman & the FSF.

[xparq]

See #3 for my first attempt to build it. It's massive, but perfectly doable, and it works just fine. NOT tried on Windows yet! (-> #4 )