[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Consideration for Rust contributions in Emacs
From: |
Eli Zaretskii |
Subject: |
Re: Consideration for Rust contributions in Emacs |
Date: |
Mon, 23 Jan 2023 21:04:47 +0200 |
> From: John Yates <john@yates-sheets.org>
> Date: Mon, 23 Jan 2023 13:22:44 -0500
> Cc: arne_bab@web.de, comms@dabrev.com, allred.sean@gmail.com,
> emacs-devel@gnu.org
>
> On Mon, Jan 23, 2023 at 12:06 PM Eli Zaretskii <eliz@gnu.org> wrote:
> >
> > Quite a few new features are still being implemented in C. Consider
> > just the recent innovations: native-compilation, tree-sitter, support
> > for XInput2 and touch devices, to name just a few.
>
> Of these four, only tree-sitter seems to be implemented in C solely
> for performance reasons. IIANM, there is nothing fundamental about
> what tree-sitter is doing that *could not* be done in lisp. The
> only issue is performance.
>
> By contrast, the three other features that you list (native-
> compilation, XInput2 and touch screen support) need to interact
> with the host environment. From what I have observed, developers
> typically partition such features into a C component and a lisp
> component. The impetus seems to be to find a natural partition:
> to do in C what must (which may still include some performance
> considerations) and then to expose a nice, clean interface to lisp.
Right. Which is exactly my point: some parts of Emacs are implemented
in C for reasons that have nothing (or almost nothing) to do with
performance. E.g., even in the first example, you cannot access
buffer text directly except on the C level.
> > Moreover, familiarity with the internals implemented in C is IME quite
> > necessary even for Emacs developers who almost never touch that layer.
>
> For some definition of Emacs developer, I do agree.
I think for any serious Emacs developer. Limiting the familiarity to
the Lisp level will leave many important aspects look like black
magic, because what we expose to Lisp is higher-level abstractions
that sometimes create a completely inaccurate mental picture of what
really happens. A good example is the machinery that triggers
redisplay and how it integrates into the Emacs "main loop".
- Re: Consideration for Rust contributions in Emacs, (continued)
Re: Consideration for Rust contributions in Emacs, Sean Allred, 2023/01/22
- Re: Consideration for Rust contributions in Emacs, Robert Pluim, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Troy Hinckley, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Po Lu, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Dr. Arne Babenhauserheide, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, John Yates, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Eli Zaretskii, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, John Yates, 2023/01/23
- Re: Consideration for Rust contributions in Emacs,
Eli Zaretskii <=
- Re: Consideration for Rust contributions in Emacs, Bob Rogers, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Eli Zaretskii, 2023/01/23
- Re: Consideration for Rust contributions in Emacs, Bob Rogers, 2023/01/23
Re: Consideration for Rust contributions in Emacs, Dr. Arne Babenhauserheide, 2023/01/23
Re: Consideration for Rust contributions in Emacs, Po Lu, 2023/01/23
Re: Consideration for Rust contributions in Emacs, Po Lu, 2023/01/23