Hacker News Reader

Comment by aacid | Hacker News Reader

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?

View on HN

So 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.

Literally 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...).

> small C based core

Count before you post; Emacs now boasts over 300,000 lines of C.

"Encompassing Massive Amount of C Source"

Relative 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

Ok, 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.

Reply on news.ycombinator.com