From: John Yates <john@yates-sheets.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: arne_bab@web.de, comms@dabrev.com, allred.sean@gmail.com,
emacs-devel@gnu.org
Subject: Re: Consideration for Rust contributions in Emacs
Date: Mon, 23 Jan 2023 13:22:44 -0500 [thread overview]
Message-ID: <CAJnXXoiP0GNz8k-n06ZjshHJ3r620ZM65SG-o6U4r6aB7GEyHg@mail.gmail.com> (raw)
In-Reply-To: <83cz75i3iu.fsf@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.
Part of what went unsaid in my previous post is that there have been
multiple occasions where code migrated from C to lisp, often to make
it easier to maintain and/or extend. I am sure that there must have
been instances of migration in the other direction, but none come
immediately to mind.
> 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. (Though, as a
C++ developer who, decades ago, left ancient C behind, and having
recently spent time noodling on the periphery of the display engine,
I can tell you that wading into that code is "bracing". :-)
/john
--
John Yates
505 Tremont St, #803
Boston, MA 02116
next prev parent reply other threads:[~2023-01-23 18:22 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <f2ee2f1d-332f-4707-bd9e-23444c34749f@Spark>
2023-01-21 22:48 ` Consideration for Rust contributions in Emacs Troy Hinckley
2023-01-22 7:44 ` Po Lu via Emacs development discussions.
2023-01-22 11:05 ` Daniel Martín
2023-01-22 14:04 ` Po Lu
2023-01-22 23:16 ` Troy Hinckley
2023-01-23 5:55 ` Po Lu
2023-01-24 3:49 ` Richard Stallman
2023-01-24 3:52 ` Richard Stallman
2023-01-24 6:52 ` Dr. Arne Babenhauserheide
2023-01-23 2:00 ` Sean Allred
2023-01-23 3:37 ` Troy Hinckley
2023-01-23 12:25 ` Po Lu
2023-01-24 2:24 ` Lynn Winebarger
2023-01-24 2:47 ` Etienne Prud'homme
2023-01-24 2:49 ` Po Lu
2023-04-11 12:39 ` Po Lu via Emacs development discussions.
2023-04-11 18:23 ` Dr. Arne Babenhauserheide
2023-04-15 3:36 ` Richard Stallman
2023-04-15 3:40 ` Po Lu
2023-04-15 7:03 ` Eli Zaretskii
2023-04-12 0:36 ` Dmitry Gutov
2023-04-12 4:59 ` tomas
2023-04-12 11:26 ` Richard Stallman
2023-04-13 1:02 ` Richard Stallman
2023-04-13 5:09 ` Eli Zaretskii
2023-04-13 8:23 ` Po Lu
2023-04-15 23:27 ` Dmitry Gutov
2023-04-16 0:11 ` Po Lu
2023-04-17 2:55 ` Richard Stallman
2023-01-23 13:21 ` Dr. Arne Babenhauserheide
2023-01-23 16:51 ` John Yates
2023-01-23 17:06 ` Eli Zaretskii
2023-01-23 18:22 ` John Yates [this message]
2023-01-23 19:04 ` Eli Zaretskii
2023-01-23 19:44 ` Bob Rogers
2023-01-23 19:56 ` Eli Zaretskii
2023-01-23 20:08 ` Bob Rogers
2023-01-23 19:22 ` Dr. Arne Babenhauserheide
2023-01-23 23:52 ` Po Lu
2023-01-24 0:45 ` Po Lu
2023-01-23 7:32 ` Robert Pluim
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJnXXoiP0GNz8k-n06ZjshHJ3r620ZM65SG-o6U4r6aB7GEyHg@mail.gmail.com \
--to=john@yates-sheets.org \
--cc=allred.sean@gmail.com \
--cc=arne_bab@web.de \
--cc=comms@dabrev.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).