3 ms·
What should I imagine under term "extending"? Is that adding new extensions (like in vscode)? I never felt that this is something I often enough to need quickes
by aacid 3y ago
What should I imagine under term "extending"? Is that adding new extensions (like in vscode)? I never felt that this is something I often enough to need quickest possible way to do it.
Or do you mean more like changing how editor looks, how many windows/panes/tabs are displayed and where are they displayed?
- yaantc 3y agoLiterally changing the editor code, to do whatever you want. Emacs is a lisp (elisp) environment mostly with a small C based core for performance sensitive primitives. But the user code is at the same "level" as the Emacs core code. This is very different from most extensible editors, where extensions are sandboxed and have a limited, controlled API to the core editor, which is kept separate. This makes Emacs very "malleable", and it's likely easier than with most other tool to change it in custom, specific ways. It may seem dangerous, but it comes from a culture where this extensibility is very front and center, with documented design pattern to support it (hooks, customization settings...).
- kazinator 3y ago> small C based core Count before you post; Emacs now boasts over 300,000 lines of C. "Encompassing Massive Amount of C Source"
- chungy 3y agoRelative to the Lisp source, it might qualify, but wow. :) Emacs 29.1, excluding the test directory; top ten languages: all SLOC=2618374 (100.00%) LLOC=182918 in 2584 files elisp SLOC=1188181 (45.38%) LLOC=0 in 1566 files man SLOC=501820 (19.17%) LLOC=0 in 48 files C SLOC=387169 (14.79%) LLOC=159681 in 317 files Texinfo SLOC=288384 (11.01%) LLOC=0 in 182 files Lisp SLOC=175786 (6.71%) LLOC=0 in 1 files Objective-C SLOC=18289 (0.70%) LLOC=8480 in 8 files Tex SLOC=16031 (0.61%) LLOC=0 in 23 files m4 SLOC=10436 (0.40%) LLOC=0 in 133 files shell SLOC=6819 (0.26%) LLOC=0 in 28 files C++ SLOC=6240 (0.24%) LLOC=2924 in 5 files
- yaantc 3y agoOk, I should have said relatively, or even better "subjectively", small C source base. The C base supports many platforms and variants, so only a part of it is used in a running Emacs instance. And to the 1+M lines of elisp one typically had many more extension packages. That's the the "relative". In practice, when I want to change things I don't hit the C layer. Anytime I had to introspect Emacs to change something I was firmly in the lisp world. I don't remember having been limited by something being at the C level, which are things that cannot be changed dynamically. This is really what I meant: in practice to change Emacs the C level (although big in the absolute, and definitely complex) doesn't show up much and hasn't been a limitation at least to me.
- globular-toast 3y agoSo your editor works exactly the way you want it to? Just yesterday I made a tiny tweak to a package that I use (doom-modeline). I haven't thought about it enough to make a pull request, so that tweak now lives on my fork on GitHub. It took me all of five minutes to find out where to make the change, have the code open, and the change made, loaded into my running Emacs session and uploaded to GitHub. And bear in mind I'd never looked at the code for doom-modeline before. Good tools change the way you work because they make certain workflows possible. If it was that easy for you to tweak your editor, you would too.