Yep, I edited and added the commit that first tried adding it. It's been four years at least...so much about me noticing changes in programs I use ;)

Oh....you are right, I had no clue when that was added. Sorry, I really had no clue that kwrite can do that by now...I am sure it couldn't do it in the past (But I doubt I really tired it in the last ten years after seeing that it initially didn''t support it...so it could have been possible for some time already and I wouldn't have noticed)

Edit: Okay I was curious...seems kwrite gained tab support around 2022: https://invent.kde.org/utilities/kate/-/merge_requests/691 and https://kate-editor.org/post/2022/2022-03-31-kate-ate-kwrite/

I wouldn't use "=>"...they serve different purposes. But yes, they are all build with the same editor components (ktexteditor). Kwrite for example has no tab support..making it not really useful for editing more than one file at a time...but is simpler to use so rather useful for quick config file editing.

Kate is a full fledged text editor with plugin and LSP support. So it can serve as editor for programming but also as editor for other tasks that require some organizing and multiple files.

kdevelop is a IDE. It includes a lot more tools that aren't strictly editor related (for example tools for easier looking through git patches before submitting them) but it is pretty much only geared towards programming (and there for specific languages like c, cpp, python or php)

Not mention...but kile is a editor specified on creating latex document which also uses the same editor component.

Missing kernel config is a good guess at this point. If this is your first gentoo install I would recommend using the distribution kernel at first without manual configuration. It makes it easier to setup your system first to a usable state and then later you can still do a manual kernel config but at least have a back-up kernel that works until you get the manual config right.

https://wiki.gentoo.org/wiki/Intel#X_drivers

What do you have in your VIDEO_CARDS variable in your portage settings?

Edit: Also if you configured your own kernel make sure to look at the section above the one i linked if you have everything needed enabled in your kernel config.

Edit2: About the ~amd64 keyword...gentoo packages come in two "branches". The stable and the testing branch. Normally you install a package in the stable version. But if you want you can set the ~amd64 keyword for a package and you get the testing version ( https://wiki.gentoo.org/wiki/ACCEPT_KEYWORDS ). You can mix stable and testing package on your system as you like...but often testing packages will require other testing packages to be installed. For KDE for example plasma 6.8 is currently the testing version and 6.6.6 and 6.7.5 are the stable versions (you can pick which one you want).

I really recommend you read the "Working with gentoo" and "Working with portage" section of the handbook...they explain most of this.

From the mail it doesn't exactly look like "upstream dependencies on systemd" but rather like a lack of features in sysvinit:

The second reason for dropping System V is that packages like GNOME and soon KDE's Plasma are building in requirements that require capabilities in systemd that are not in System V. This could potentially be worked around with another init system like OpenRC, but beyond the transition process it still does not address the ongoing workload problem.

So it seems a bit like sysvinit is simply a dead end and there is definitively not enough manpower for a transition to openrc/elogind/whatever...and it's a good chance to consolidate the exiting workforce on a single version. Sounds all pretty reasonable to me. But it can't really serve as example for systemd being an absolute requirement even for LFS now and them being "forced" to use it.

Gentoo user....but assuming now it's about building on distributions that don't automate it like gentoo.

Disadvantages:

• No easy way to uninstall again. Some build systems generate lists of files that were installed or even some uninstall rules but that requires to either keep the build directory with the source-code around or to make backups of the necessary build files for proper uninstall. And in some build systems there are no helpers for uninstalling at all.
• Similar...updating doesn't guarantee to remove all traces of the previous version. If the new build overwrites every file of the previous version...fine. But if an update version doesn't need files anymore that were installed in previous versions those will usually not get remove from your system and stick around.
• In general lack of automatism for updates
• Compiling takes time
• You are responsible for dealing with ABI breakages in dependencies. In most cases the source-code you compile will depend on other libraries. Either those come from your distro or you also build them from source...but in both cases you are responsible for rebuilding a package if an update to one of the dependencies breaks the ABI.
• You need build-time dependencies and depending on your distro also -devel packages installed. If source-code you install needs an assembler to build you have to install that assembler which wouldn't be necessary if you installed the binary (You can remove those build-dependencies again of course until you need to rebuild). Similar for -devel packages for libraries from your distro....if the source-code depends on a library coming from your distro it also needs the header files, pkgconfig files and other development relevant files of that library installed which many distros split out in own -devel packages and that aren't necessary for binaries.
• You have to deal with compile flags and settings. It's up to you to set the optimization level, architecture and similar for your compiler in environment variables. Not a big deal but still something someone has to look into at the start.
• You have to deal with compile-time options and dependencies. The build-systems might tell you what packages are missing but you have to "translate" their errors into what to install with your package manager and do it yourself. Same for the detection of the build systems...you have to read the logs and possibly reconfigure source-code after installing some dependencies if he build systems turned off features you want because of lacking dependencies.
• Source-code and building need disk space so make sure you have enough free. Similar with RAM...gentoo suggests 2GB of ram for each --job of make/ninja but that's for extreme cases, you usually can get away with less than 2GB per job.

Of course you also gain a lot of advantages...but that wasn't asked ;)

You can "escape" most of the mentioned disadvantages by using a distro like gentoo that automates much of this. It's probably worth a look if you plan on doing this regularly.

edit:typos

You can set most KDE menus to show the "Comment" key of the .desktop files instead of the "Name" key. So "KDE Advanced Text Editor" instead of "Kate".

Packages can come with several "programs" that aren't necessarily named the same as the package. Example: Calibre installs menu items for "Calibre", "EBookViewer" and "EBookEditor" on my distro.

It's not about forgetting...it' about helping to quickly find what you just installed and what is all included.