emacs-devel
[Top][All Lists]
Advanced

[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".



reply via email to

[Prev in Thread] Current Thread [Next in Thread]