pkalI feel the word "bloated" has lost some of its meaning, especially when I hear it being used in the context of Emacs. For me, "bloat" signifies that software has unnecessary functionality that unconditionally wastes system resources, including but not limited to CPU time, memory, disk space, etc., to a degree that it brings with it noticeably degrades to user experience.
In the case of Emacs, while it comes with a lot of scripts that most people don't have to use all the time, they aren't loaded by default and only "waste" disk space. But the file sizes for most scripts is in the kB space, occasionally perhaps peaking over a few MB.
My impression is, that most people don't realise that while Calc, Org, Gnus, ... are all part of the core, their presence is at first virtual, as Emacs uses an "auto-loading" system: We mark certain entry-points of a script as auto-loaded, which means that these commands/user-options do have definitions, even if the actual script was not loaded, but their definition are just little stubs, that would load the real files and then defer the call to the actual definition. Actually quite easy to implement on your own, which I have been considering demonstrating in an article, as I feel that auto-loading is more confusing when just explained in regular language. The point is, that the functionality gets loaded on demand, which by definition wouldn't make it bloat.
Of course, an Emacs script itself can be bloated, especially if it aggressively (and/or unconditionally) attaches itself into frequently used hooks like post-self-insert-hook, which can slow down Emacs, or by not writing code with GC in mind. But I'd argue that these are mostly design mistakes due to the script authors, which can be improved upon.
meso
on-lain ✔ᵛᵉʳᶦᶠᶦᵉᵈ
All GNU social JP content and data are available under the