From: Po Lu <Luangruo@yahoo.com>
To: emacs-devel@gnu.org, John Yates <john@yates-sheets.org>,
Eli Zaretskii <eliz@gnu.org>
Cc: arne_bab@web.de, comms@dabrev.com, allred.sean@gmail.com
Subject: Re: Consideration for Rust contributions in Emacs
Date: Tue, 24 Jan 2023 07:52:42 +0800 [thread overview]
Message-ID: <2C8C5514-92D6-4E82-8F6C-2551E65F91B8@yahoo.com> (raw)
In-Reply-To: <CAJnXXoiP0GNz8k-n06ZjshHJ3r620ZM65SG-o6U4r6aB7GEyHg@mail.gmail.com>
I find Emacs Lisp to be a limiting language compared to C. This is just my opinion, and this is why I greatly prefer writing C over Lisp.
However, writing everything in C precludes customizing Emacs, so I tried to find a balance there. A good example would be the drag and drop code.
On January 24, 2023 2:22:44 AM GMT+08:00, John Yates <john@yates-sheets.org> wrote:
>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
>
>
>
next prev parent reply other threads:[~2023-01-23 23:52 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
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 [this message]
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=2C8C5514-92D6-4E82-8F6C-2551E65F91B8@yahoo.com \
--to=luangruo@yahoo.com \
--cc=allred.sean@gmail.com \
--cc=arne_bab@web.de \
--cc=comms@dabrev.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=john@yates-sheets.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).