To prevent parts of it (typically the minibuffer) from hanging out of the screen...
This should be done by Emacs, of course (with support from the WM), at least by request, if not by default.

https://www.reddit.com/r/emacs/comments/ntt0v4/copy_from_emacs_in_wsl_to_windows_applicaitons/
-> https://github.com/spudlyo/clipetty/

Works with the Windows Terminal, too.

But I'm having a weird bug in the init code, so it's not available from conemacs for some reason. :-/

Cannot open load file: no such file or directory, clipetty

WTF?! :-o Works with emacs -nw

To make the cfg. more composable, it seems to be better to package everything around features, rather than system layers or procedural phases etc.

This way a streamlined base config that only uses built-in defaults could be shared ubiquitously across installations (and be the config of my ed or conemacs variants).

-> #11

-> #5

It did, earlier, though, AFAICR.

Well, well... As I noted in the emax startup scripts, the HOME hack really is shaky...

When tried to just open my old ~/.emacs.d/init.el on dev, with the newly built custom emacs in /opt/emacs, plus this config repo cloned there & activated, my "redirecting" quick-edit emacs script (conemax) indeed made emacs open /opt/home/.emacs.d/init.el, rather than /home/<me>/.emacs.d/init.el!!! :-o

(/home/szabi/.emacs.d/init.el worked OK, of course.)

-> https://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-custom-user-emacs-directory
-> https://emacs.stackexchange.com/a/4258/41263 -- this also for completing my own fake init with:

(setq user-init-file (or load-file-name (buffer-file-name)))
(setq user-emacs-directory (file-name-directory user-init-file))

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.

OMG, this will never end... :-/

• Couldn't remap Esc to quit, as that's apparently the same as Alt in console mode (only; fine in GUI mode), and now every Alt + ... combo will just quit... :-/ -> #7

https://www.gnu.org/software/emacs/manual/html_node/emacs/Saving-Emacs-Sessions.html

• set desktop mode on by default initially, just to learn its details faster, annd also to conserve (+ surprise me with) forgotten remote sessions
• --no-desktop for the $EDIT wrapper, if desktop saving is on by def.
• does it save search, recent files & other history lists, too?
• actually almost EVERYTHING that's not global cfg should be saved as session data! Chk what other people have done for this "chrooting", apart from switching entire home dirs (similarly to VSCode profile switching)

Just to have a feel of the cost, general robustness of the build setup etc.

Building from source

Source = the .zip from the GH mirror, which apparently means the relevant guide is INSTALL.REPO, not INSTALL!

Vanilla build at first, no options (like --with-modules etc., only the prefix to install in /opt/emacs), just to have a feel.
UPDATE: It's massive, as expected... Took ~half an hour on my old Toshiba laptop, and 10-15 min on my dev server.

Linux (WSL Debian 12)

1. For configure to succeed, I ran (partly as per the messy build page of the Emacs Wiki, partly as per the errors make configure and then configure gave):

   sudo apt install libc6-dev libjpeg62-turbo libncurses5-dev libpng-dev libwebp-dev libtiff5-dev libgif-dev xaw3dg-dev zlib1g-dev libx11-dev texinfo libcairo-dev gnutls-bin gnutls-dev

   Note: no makeinfo, no gnutls pkg, and libcairo defaults to cairo2. Also, since this is a dev. host, a bunch of X-related and other libs have already been installed!

   Also had to add libxpm-dev libgif-dev libtiff-dev on my dev server! And --with-gnutls=ifavailable, because couldn't install that one for some reason...

2.1. To go ahead and build (with configure options, as needed, e.g. --with-tree-sitter --with-small-ja-dic):

make configure="--prefix=/opt/emacs CFLAGS='-O2 -g'"

Note: --with-native-compilation requires libgccjit-dev, but I couldn't even find the package name for my Deb11 server...)

2.2. Or... For more control, like building in a separate dir outside the repo:

./autogen.sh # to generate `configure`
cd ..
mkdir build.tmp && cd build.tmp

3. ../emacs-master/configure --prefix=/opt/emacs, or more, e.g. this on my Deb11 dev server:

   ./configure --prefix=/opt/emacs --with-gnutls=ifavailable --with-tree-sitter --with-native-compilation --with-small-ja-dic

4. make install -> ~150 MB to /opt/emacs, most of which is share... All is well, apparently.

   (The emacs exe is 26 MB though -- 8 after strip; I wonder how much of it is actually statically linked... Well, not much! ldd lists 65 shared libs! :-o )

Windows 10

-> #4

• There must be a general buffer predicate (hopefully built-in!) to tell the difference
• The "by-request" option is, well, optional... Need to find a good key binding for toggling it -- which requires #20...

See also: #14

Ctrl+Insert in Windows Terminal, Deb12, conemax.

Is is not shown only in the "visual" (or whatever) style I'm using? Or is it broken in general.

Without that it gives the strong impression that there isn't actually a line there, even though the cursor is moved down there.
(The general arcane clunkiness of Emacs allowed me to suspect that, assuming first that it's not a line number display problem; I even looked for ways to tell Emacs to stop it... -- before I realized that Emacs is doing the right thing here.)

Not so sure any more... It's a dilemma of how to define a line:

a) one that has a line terminator, or the chars between the last one and EOF
b) one, where you can go to (vertically), regardless of being empty

I prefer (b), but both have merit. Practically though, there's a big benefit to the default behavior, which uses (a):
You can immediately tell the difference between an empty last line and one that only has some (invisible) whitespace!

Well, it's mostly an inherently impossible task, but... everyone must have some "optimal" (i.e. good enough) solution.

• super ergonomic (without hardcore mods like Dvorak or CTRL -> CAPS LOCK etc.; but compatible with touch typing and the typical "coder typing" mode, where the right hand mostly rests over the navig. block, not the letters!)
• logical (learnable; -> "extensible")
• intuitive (guessable)
• (somewhat) compatible -- to survive on default emacs instances!
• extensible (-> "logical")
• (somewhat) portable -- to other environments (editors / IDEs)
• creative, inventive (Ctrl is not as bad if you use instead of your pinky)

There's e.g. gnu-elpa-keyring-update-2022.12 installed (as recommended by a respectable SO user), but that didn't help on Windows, for the missing gpg toolset, AFAICR.

init-addons.el:

(setq package-check-signature nil) ;; Can't install from Windows without it yet...
  ;; https://emacs.stackexchange.com/questions/233/how-to-proceed-on-package-el-signature-check-failure

(Follow-up of #3)

This is just as the configurable default. Various modes would have different params. E.g. my MD-like mode would probably have 2 as indent-size. (Shouldn't be called tab-size!)

• Aligned indent should just copy whatever whitespace the ref. line has!
• That "or else" means: if already aligned, or no ref. line "near enough" (cfg!), then proceed deeper.
• Reverse logic should be straightforward (but not sure).

All I checked depended on e.g. emacsen-common, and typically there are various others, too!
I guess the (m)elpa package manager does what it needs to to resolve dependencies, but when I'm just copying over some of those from a pre-created config, that seems shaky...

Wait, I'm actually doing that from Windows to Linux! :) Sooo...

• What exactly emacsen-common does then?
• And is apt on Debian just trying to be nice, with all those other dependencies?!

...while C-h k says that C-x C-c x is undefined! :-o

• Why the hell is C-x C-c x the same as Alt+X
  -> Only in console mode -- not in the normal config!
  • Because a) Esc is remapped in conemacs to C-x C-c and b) Alt = Esc to the idiotic terminal stuff... :-/
• Why does it quit? Is it related to redefining ESC?
  ->It's the proper exit command, with confirmations etc., so probably! But doesn't happen in GUI mode!
  • Same thing: Alt = Esc in the terminal :-/
• Why is it "undefined" (then)???
  • Because it is..., now that "Alt" (i.e. "Esc"!) has been redefined to C-x C-c...

Yet another sad case of terminal key translation fukup! :-/ -> #8
(Confirmed by e.g. the default Alt+Q also quitting.)

It just closes the currently open (sub)menu pane, and does nothing else.
E.g. open the Buffers (sub)menu, and click to Files from there...

Try repeated up/down cmds while moving around with no selection...

In "normal interactive user mode" it makes no sense to wait indefinitely for an input event to complete. It would be much better to auto-cancel it, sparing the slightly inconvenient & arcane C-g, or a frustrating "dunno how many exactly in this particular counter-intuitive context, but certainly more than one ESCs" punchfest.

But over a network connection, when it's a macro of some sort that hangs, it could be disastrous to cancel the flow, garbling the subsequent input sequence entirely (in case it resumes)!

But as a "minor mode", turned on explicitly by an interactive command, it should be fine.

• Ctrl + Del/Backsp -> sz/delete-to-next-word-boundary, sz/backspace-to-prev-word-boundary

• Proper file (buffer) switching (FWIF: M1/M3 on buffer name is prev/next)

• Divide the init/cfg into a "free" sanitization baseline layer, plus extras. -> #11!
  Kinda done, but not double-checked how free the baseline is.

• conemacs: load much less crap on startup, but still keep the sane defaults! (Requires the one above.)

• Custom custom.el: is it actually used?!
  Yes, but not sure if I still need to load it manually...
  -> Some package manipulations updated it, but also OVERWROTE EVERYTHINT ELSE THERE! :-o

• CompAny: also allow dismissing offered completions by delete, not just backspace

• Proper scrolling to botton on Ctrl-End

• Speedbar etc.: no line numbers there...

• Speedbar: why does it only show certain files (like not this TODO or the README,
  not even when loaded)?!

• Speedbar: don't open randomly in other windows (panes) after closing it sidebar!

• Migrate away from the libs/packs installed via Debian into /usr/share/* and
  /etc and who knows where, and put everything into a unified .emacs.d tree,
  installed via emacs itself.

  One motivation was that the Debian install tree is full of symlinks,
  which don't work on Windows (NTFS + WSL + W10 interop issue), so that
  tree can't be shared: everything would need to be installed on Windows
  via Emacs anyay -- so, if that local tree is cross-platform, it should
  be used on Linux, too!

  • Understand what can and cannot be installed in this uniform way both on
    Linux and Windows
  • with the occasional checks/switches/branches across the two
    • E.g. just copying package-installed stuff from one to the other seems fine!

• See how others group their configs: do they go thematically, e.g. putting
  the key bindings along with all the other cfg aspects of a given package
  or feature, or do they tend to keep the keys separate?