Re: Consideration for Rust contributions in Emacs

[Po Lu]

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