Consideration for Rust contributions in Emacs

Consideration for Rust contributions in Emacs

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 1628 bytes --]

I've had a discussion with several people recently about future possibilities of Rust in GNU Emacs core. I could not find an answer to this on the archives, so if it has been resolved previously please point me to that thread.

Let assume for the sake of this discussion that there was a some Rust code that someone wanted to contribute and the maintainers wanted the functionality it provided. What would be the consideration/objections? Here are few that we came up with:

1. The Rust tool-chain is Apache licensed and so is LLVM. There is work on a GCC backend, but it is not production ready yet. Would Emacs allow the current Rust tool-chain?
2. LLVM (and hence Rust) support fewer targets than GCC. Are there certain target that LLVM doesn’t support that are important to Emacs?
3. Many Rust libraries (crates) are MIT and/or Apache licensed. Do all Libraries used by GNU Emacs need to be GPL or is it sufficient to have a GPL compatible license?
4. How sizable of a contribution would be needed for the maintainers to accept Rust in Emacs core? Would auxiliary functionality be considered (such as Rust in the Linux Kernel) or would it need to have major impact.
5. Concerns over having more than one core language in GNU Emacs.
6. Concerns over using such a new language. Rust still changes at a fast pace relative to C and it’s future is less certain then a more established language.
7. Concerns over support for Rust being a distraction from other development work.
8. I assume that FSF copyright would still be a requirement. I just bring it up so no one else has to.


Sincerely,
Troy Hinckley

[-- Attachment #2: Type: text/html, Size: 2020 bytes --]

Re: Consideration for Rust contributions in Emacs

[Po Lu via Emacs development discussions.]

Troy Hinckley <comms@dabrev.com> writes:

> Let assume for the sake of this discussion that there was a some Rust
> code that someone wanted to contribute and the maintainers wanted the
> functionality it provided. What would be the consideration/objections?

It is hard to say for certain, because you have not said what code you
have in mind.

> 1 The Rust tool-chain is Apache licensed and so is LLVM. There is work
> on a GCC backend, but it is not production ready yet. Would Emacs
> allow the current Rust tool-chain?

No.  Emacs code for a platform where GCC is available must be written so
that it can be compiled with GCC.  We already have this policy in place,
and it prevents us from using Objective-C features that are only
supported by Clang in the Nextstep.

> 2 LLVM (and hence Rust) support fewer targets than GCC. Are there
> certain target that LLVM doesn’t support that are important to Emacs?

For example: MS-DOS, via DJGPP.

Or, Windows 9X.  I use Emacs to code-convert files on a Windows 98
machine used to run government software.

And also the various Unix systems that currently do not support LLVM:
HP/UX, and AIX.

> 3 Many Rust libraries (crates) are MIT and/or Apache licensed. Do all
> Libraries used by GNU Emacs need to be GPL or is it sufficient to have
> a GPL compatible license?

I would be more concerned about how Rust libraries are distributed.
Isn't the Rust package manager one of those which download libraries
directly from a source code repository?

> 4 How sizable of a contribution would be needed for the maintainers to
> accept Rust in Emacs core? Would auxiliary functionality be considered
> (such as Rust in the Linux Kernel) or would it need to have major
> impact.

It will probably not be accepted.

> 5 Concerns over having more than one core language in GNU Emacs.

Yes.

> 6 Concerns over using such a new language. Rust still changes at a
> fast pace relative to C and it’s future is less certain then a more
> established language.

Yes.  Rust is not widely available at all, while C is available for
every platform, from 8 bit microcontrollers, to 16 and 24-bit digital
signal processors, and 32-bit and 64-bit consumer computers, and will
remain that way for the foreseeable future.

Emacs is a portable program written in C.  Thus, any code that is not
strictly a port to some other platform should also be written in
standard C99.

In the past, people wanted to rewrite Emacs in Scheme.  Then, it was
C++.  Then, it was Java.  Now, it is Rust.

Part of the reason Emacs has existed for so long is that it has not
given in to those demands, and remains a highly portable program,
written in a standardized language, that has remained more or less
constant since it Emacs was written.  Rust, on the other hand,
frequently releases breaking changes with new versions of the
programming language, and is not standardized in any way.  This shows in
that even an operating system supposedly written in Rust provides a C
toolchain and C runtime library.

\f

Now, judging by recent internet chatter, you probably think Rust will
magically allow Emacs Lisp to run on different threads.

Some people seem to have this idea that because the Rust compiler will
try to prevent two threads from having access to a variable at the same
time, writing Emacs in Rust will, as if by magic, allow multiple Lisp
threads to run at once.

That is not true.  The Rust compiler does not try to avoid concurrency
pitfalls aside from the simple data race: for example, locking a
non-recursive mutex twice is not only a programming error, it is
undefined behavior!

In addition, locking (and not locking) needs to be carefully thought
out, or it will slow down single threaded execution.  For example, a
common pattern found inside Emacs code is:

  for (; CONSP (tem); tem = XCDR (tem))
    /* Do something with XCAR (tem) */;

XCAR and XCDR work fine unchanged on most machines without needing any
kind of locking, as Lisp_Cons is always aligned to Lisp_Object.

However, it does not work on two machines, which either need explicit
memory barrier instructions (or in the case of vectors, mutexes):

On the (64-bit) Alpha, memory ordering across CPUs is extremely lax, and
without the appropriate barrier instructions, even aligned reads and
writes of 64 bit words are not atomic.

On x86 (and possibly other platforms) with --with-wide-int, reads and
writes of Lisp_Object require separate moves and stores to and from two
32 bit registers, which is obviously not atomic.

Then, if XCDR (tem) reads from a cons whose cdr cell is in the process
of being written to, then it may dereference a nonsense pointer.

And contrasting that, this code is perfectly safe in C, on x86.  The
assert will never trigger:

static unsigned int foo;

thread_1 ()
{
  foo++;
}

thread_2 ()
{
  assert (foo <= 1);
}

main ()
{
  /* start thread_1 and thread_2 at the same time.  */
}

I believe the Rust compiler will force you to add some code in that
case.  Imagine how much overhead it would add if Emacs had to lock a
Lisp_Cons before reading or writing to it.

But the Lisp interpreter is the easy part, especially since we already
have much of the necessary interpreter state moved off into struct
thread_state.  A lot of other code which is algorithmically non
reentrant will have to be made reentrant, and papering mutexes and
atomics over them to satisfy compile-time checks will not do that.  For
example, how do you propose to rewrite process.c to allow two threads to
enter wait_reading_process_output at the same time?

Who gets SIGCHLD? Who gets to read process output? In which thread do
process filters run?

In the end, you will have to do the same work you would need to in C,
with the added trouble of adding code in a new language, making everyone
else learn the new language, while throwing portability down the drain.
That doesn't sound like a good tradeoff to me.

Re: Consideration for Rust contributions in Emacs

[Daniel Martín]

Troy Hinckley <comms@dabrev.com> writes:

> I've had a discussion with several people recently about future
> possibilities of Rust in GNU Emacs core. I could not find an answer to
> this on the archives, so if it has been resolved previously please
> point me to that thread.
>
> Let assume for the sake of this discussion that there was a some Rust
> code that someone wanted to contribute and the maintainers wanted the
> functionality it provided. What would be the consideration/objections?
> Here are few that we came up with:
>
> 1. The Rust tool-chain is Apache licensed and so is LLVM. There is work on a GCC backend, but it is not production ready yet. Would Emacs allow the current Rust tool-chain?
> 2. LLVM (and hence Rust) support fewer targets than GCC. Are there certain target that LLVM doesn’t support that are important to Emacs?
> 3. Many Rust libraries (crates) are MIT and/or Apache licensed. Do all Libraries used by GNU Emacs need to be GPL or is it sufficient to have a GPL compatible license?
> 4. How sizable of a contribution would be needed for the maintainers
> to accept Rust in Emacs core? Would auxiliary functionality be
> considered (such as Rust in the Linux Kernel) or would it need to have
> major impact.
> 5. Concerns over having more than one core language in GNU Emacs.
> 6. Concerns over using such a new language. Rust still changes at a fast pace relative to C and it’s future is less certain then a more established language.
> 7. Concerns over support for Rust being a distraction from other development work.
> 8. I assume that FSF copyright would still be a requirement. I just bring it up so no one else has to.
>

The first question to ask is if and how Rust would make the Emacs
codebase better.  Do you have any concrete examples of that?  I don't
think that the alleged benefits of Rust, even when used in small parts
of new functionality, would outweigh the costs of concerns 5, 6, and 7,
at least.

This answer is not exclusive to Rust.  I don't see any clear net benefit
from using another language along with C (even C++) in Emacs core.

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Daniel Martín <mardani29@yahoo.es> writes:

> This answer is not exclusive to Rust.  I don't see any clear net benefit
> from using another language along with C (even C++) in Emacs core.

Exactly.

Now, if someone wants to contribute a port to Redox OS, and the port
code uses Rust, that would be something else.

For example, the NS port uses Objective-C, the Haiku port uses C++, and
the Android port uses Java.

However, Redox has a C runtime, so I doubt that will be necessary.

Re: Consideration for Rust contributions in Emacs

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 855 bytes --]

Thank you for your replies. This matches my expectations, but I wanted to confirm.

One thing I still have an open question on is using non-GPL but GPL-compatible libraries. Ignoring Rust, would that be accepted in C? Or do all libraries need to be GPL as well?
On Jan 22, 2023 at 7:04 AM -0700, Po Lu <luangruo@yahoo.com>, wrote:
> Daniel Martín <mardani29@yahoo.es> writes:
>
> > This answer is not exclusive to Rust. I don't see any clear net benefit
> > from using another language along with C (even C++) in Emacs core.
>
> Exactly.
>
> Now, if someone wants to contribute a port to Redox OS, and the port
> code uses Rust, that would be something else.
>
> For example, the NS port uses Objective-C, the Haiku port uses C++, and
> the Android port uses Java.
>
> However, Redox has a C runtime, so I doubt that will be necessary.

[-- Attachment #2: Type: text/html, Size: 1350 bytes --]

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Troy Hinckley <comms@dabrev.com> writes:

> One thing I still have an open question on is using non-GPL but GPL-compatible libraries. Ignoring Rust, would that be accepted in C? Or do all
> libraries need to be GPL as well?

All libraries are ok as long as they are GPL compatible.  It would also
be morally ok as long as the libraries are free software.

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > One thing I still have an open question on is using non-GPL but
  > GPL-compatible libraries. Ignoring Rust, would that be accepted in
  > C? Or do all libraries need to be GPL as well?

It is fine for Emacs to link in a general-purpose library which is
releasde under a GPL-compatible free license, as long as that library
is developed, released and built separately from Emacs, and comes with
clear instructions about how to call it properly.

We can be flexible about this because we don't have to maintain that
library.  We only have to use it.

Emacs links in many such libraries already.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Having parts of Emacs written in some other language would require
future Emacs maintainers to know one more language.  No matter what
that language that might be, its use in Emacs would be a big added
burden.  This reason is very important, and is by itself enough resaon
to say no to whatever other language might be suggested.

There are specific reasons not to use Rust in particular.  Rust
changes too fast; using it in a very large program for which we try to
keep old versions maintainable would be unwise.  Cargo uses a library
archive which includes nonfree libraries, so we should not publicly
refer to its existence.  GCC is a GNU package and we do not want to
replace a GNU package with anything else.  LLVM is not copylefted;
using a noncopylefted package in place of a copylefted package would
be a setback for our cause.  Any of these reasons is sufficient not to
incorporate Rust code.

Rust has a legal problem as well: the trademark licenses of Rust is
unclear, and I can't determine whether Rust is free software.  It is
potentially harmful for anyone to use Rust at all as long as that
remains the case.

The Rust developers could cure that one problem by explaining
concretely what that license requires, specifically for how to
remove the Rust and Cargo trademarks from the compiler.
I asked them over a year ago, but they never responded.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 894 bytes --]


Richard Stallman <rms@gnu.org> writes:

> GCC is a GNU package and we do not want to
> replace a GNU package with anything else.  LLVM is not copylefted;
> using a noncopylefted package in place of a copylefted package would
> be a setback for our cause.

GCCrs¹ is a GCC frontend written for Rust, currently expected to be
included in GCC 13.

But even when using that to compile, people developing Rust software
would still be dependent on LLVM for now², because GCCrs currently only
compiles but does no actual borrow-checking.

¹: https://rust-gcc.github.io/
   This is via Github, but it does not require unfree Javascript to
   access. It works even in M-x eww.

²: Implementing the borrow checker is planned, but it’s not included in
   the initial release.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Consideration for Rust contributions in Emacs

[Sean Allred]

Hi Troy!

Thanks for raising the topic. I think this is my first time posting on
the list, but this is a topic that means quite a bit to me (and is
something I've had some experience with in other projects).

Using Rust in Emacs is an exciting prospect that draws on the general
buzz that Rust has been generating. I personally enjoy using Rust for
personal and professional projects alike. As you've noticed, though, its
use in Emacs is not without its concerns.

Troy Hinckley <comms@dabrev.com> writes:
> I've had a discussion with several people recently about future
> possibilities of Rust in GNU Emacs core. I could not find an answer to
> this on the archives, so if it has been resolved previously please
> point me to that thread.
>
> Let assume for the sake of this discussion that there was a some Rust
> code that someone wanted to contribute and the maintainers wanted the
> functionality it provided. What would be the consideration/objections?

I would add to your list of considerations that Rust is designed for an
almost singular purpose that it performs very well: memory-safety. I
don't pay *that* much attention to this list, but I also haven't seen
many bug reports concerning memory mismanagement -- and I certainly
haven't experienced any such bugs myself. I suspect this is due to the
relatively small C core that provides a memory-safe runtime for the
elisp that comprises the rest of emacs. Assuming memory-safety isn't a
demonstrated problem that emacs development struggles with,
incorporating Rust into its dev pipeline is going to be a very hard
sell:

    Does Rust actually solve a problem emacs has?

I don't know that the answer is 'no'. Frankly, I don't think I'm
qualified to offer an opinion here. More importantly to your goals, I
don't see where you've shown why you believe the answer is 'yes'.

In general (and this certainly doesn't apply to just emacs), to
introduce a new technology into a stable system, you'll need to be able
to demonstrate concrete gains that *measurably* outweigh the costs.
Introducing a new technology will inherently destablize any affected
components of the system -- this is very difficult to justify in any
large project. Feel-good syntax isn't usually a compelling reason --
especially in a project that's developed a lisp runtime where syntax is
already cheap to develop.

The last significant endeavor in this direction that I'm aware of was
Remacs -- but it appears development has petered out for one reason or
another. I don't think it's a lost cause in the grand scheme of things,
but this clearly is not a ship that can/would/should change course very
easily.

--

If it is something you are comfortable using and they meet your goals,
I'd like to point out the recent support for dynamic modules. Rust has
pretty solid FFI support in my experience. If needed, you may(?) have
better luck submitting patches to hook into / advise core functions in
lisp -- and then using those hooks in a dynamic module implemented in
the language of your choice.

-Sean

--
Sean Allred

Re: Consideration for Rust contributions in Emacs

[Troy Hinckley]

[-- Attachment #1: Type: text/plain, Size: 4060 bytes --]

Thanks Sean!

I should have been clearer in my question that I don’t have any Rust code that I want to contribute to GNU Emacs, and I don’t know anyone who does. This is a hypothetical.

I don’t think Rust should be added to the Emacs core. The core is well tested and battle hardened C and Rust would not add much value.

I guess a clearer question would be: are there any fundamental/ideological reasons Rust could not be part of GNU Emacs? Ignoring technical trade offs and complexity etc.

Po Lu already provided one; Emacs needs to support old platforms like MS-DOS. So that rules out LLVM.

Are there others? I am particularly interested in issues surrounding licensing, such as the question I posed above about libraries.

On Jan 22, 2023 at 7:30 PM -0700, Sean Allred <allred.sean@gmail.com>, wrote:
> Hi Troy!
>
> Thanks for raising the topic. I think this is my first time posting on
> the list, but this is a topic that means quite a bit to me (and is
> something I've had some experience with in other projects).
>
> Using Rust in Emacs is an exciting prospect that draws on the general
> buzz that Rust has been generating. I personally enjoy using Rust for
> personal and professional projects alike. As you've noticed, though, its
> use in Emacs is not without its concerns.
>
> Troy Hinckley <comms@dabrev.com> writes:
> > I've had a discussion with several people recently about future
> > possibilities of Rust in GNU Emacs core. I could not find an answer to
> > this on the archives, so if it has been resolved previously please
> > point me to that thread.
> >
> > Let assume for the sake of this discussion that there was a some Rust
> > code that someone wanted to contribute and the maintainers wanted the
> > functionality it provided. What would be the consideration/objections?
>
> I would add to your list of considerations that Rust is designed for an
> almost singular purpose that it performs very well: memory-safety. I
> don't pay *that* much attention to this list, but I also haven't seen
> many bug reports concerning memory mismanagement -- and I certainly
> haven't experienced any such bugs myself. I suspect this is due to the
> relatively small C core that provides a memory-safe runtime for the
> elisp that comprises the rest of emacs. Assuming memory-safety isn't a
> demonstrated problem that emacs development struggles with,
> incorporating Rust into its dev pipeline is going to be a very hard
> sell:
>
> Does Rust actually solve a problem emacs has?
>
> I don't know that the answer is 'no'. Frankly, I don't think I'm
> qualified to offer an opinion here. More importantly to your goals, I
> don't see where you've shown why you believe the answer is 'yes'.
>
> In general (and this certainly doesn't apply to just emacs), to
> introduce a new technology into a stable system, you'll need to be able
> to demonstrate concrete gains that *measurably* outweigh the costs.
> Introducing a new technology will inherently destablize any affected
> components of the system -- this is very difficult to justify in any
> large project. Feel-good syntax isn't usually a compelling reason --
> especially in a project that's developed a lisp runtime where syntax is
> already cheap to develop.
>
> The last significant endeavor in this direction that I'm aware of was
> Remacs -- but it appears development has petered out for one reason or
> another. I don't think it's a lost cause in the grand scheme of things,
> but this clearly is not a ship that can/would/should change course very
> easily.
>
> --
>
> If it is something you are comfortable using and they meet your goals,
> I'd like to point out the recent support for dynamic modules. Rust has
> pretty solid FFI support in my experience. If needed, you may(?) have
> better luck submitting patches to hook into / advise core functions in
> lisp -- and then using those hooks in a dynamic module implemented in
> the language of your choice.
>
> -Sean
>
> --
> Sean Allred

[-- Attachment #2: Type: text/html, Size: 4849 bytes --]

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Troy Hinckley <comms@dabrev.com> writes:

> Thanks Sean! 
>
> I should have been clearer in my question that I don’t have any Rust code that I want to contribute to GNU Emacs, and I don’t know anyone who
> does. This is a hypothetical. 
>
> I don’t think Rust should be added to the Emacs core. The core is well tested and battle hardened C and Rust would not add much value. 
>
> I guess a clearer question would be: are there any fundamental/ideological reasons Rust could not be part of GNU Emacs? Ignoring technical
> trade offs and complexity etc.

There are no real ideological reasons.

The fundamental reason, however, is that Rust is an unstable language,
it is difficult to learn, and it is not portable.  And Emacs has a long
history of being asked, by others, to rewrite itself in a such languages
for benefits that never materialize.

> Are there others? I am particularly interested in issues surrounding
> licensing, such as the question I posed above about libraries.

As I explained earlier, it is probably morally fine if the library is
free software, as long as it does not promote SaaSS, load proprietary
software itself (think web browsers), et cetera.

For it to be legal, the library must be GPL compatible, or a system
library, but nothing says it has to be under the GPL itself.

Re: Consideration for Rust contributions in Emacs

[Lynn Winebarger]

[-- Attachment #1: Type: text/plain, Size: 483 bytes --]

On Mon, Jan 23, 2023, 7:26 AM Po Lu <luangruo@yahoo.com> wrote:

>
> As I explained earlier, it is probably morally fine if the library is
> free software, as long as it does not promote SaaSS, load proprietary
> software itself (think web browsers), et cetera.
>

I'm not familiar with the SaaSS acronym.  I assume it's a modification of
"Software as a Service", but Google is not showing me anything with the
additional "S".  Could you elaborate or point to a definition?

Lynn

>

[-- Attachment #2: Type: text/html, Size: 1050 bytes --]

Re: Consideration for Rust contributions in Emacs

[Etienne Prud'homme]

> I'm not familiar with the SaaSS acronym.  I assume it's a modification of "Software as a Service", but Google is not showing me anything with the additional "S".  Could you elaborate or point to a definition?

Service as a Software Substitute[1].  It's a (rightly) pejorative term.
I think the term was coined by Richard Stallman.

[1] https://www.gnu.org/philosophy/who-does-that-server-really-serve.en.html

On Mon, Jan 23, 2023 at 9:25 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Mon, Jan 23, 2023, 7:26 AM Po Lu <luangruo@yahoo.com> wrote:
>>
>>
>> As I explained earlier, it is probably morally fine if the library is
>> free software, as long as it does not promote SaaSS, load proprietary
>> software itself (think web browsers), et cetera.
>
>
> I'm not familiar with the SaaSS acronym.  I assume it's a modification of "Software as a Service", but Google is not showing me anything with the additional "S".  Could you elaborate or point to a definition?
>
> Lynn

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Lynn Winebarger <owinebar@gmail.com> writes:

> I'm not familiar with the SaaSS acronym.  I assume it's a modification of "Software as a Service", but Google is not showing me anything with
> the additional "S".  Could you elaborate or point to a definition?

See https://www.gnu.org/philosophy/words-to-avoid.html#SaaS.

Re: Consideration for Rust contributions in Emacs

[Po Lu via Emacs development discussions.]

Po Lu <luangruo@yahoo.com> writes:

> There are no real ideological reasons.

This has changed.  From my POV, Rust is now completely unsuitable for
writing code for Emacs.

The Rust Foundation has published a draft trademark policy.  They will
apply this policy to all use of the Rust trademark, including towards
documentation surrounding other implementations of the Rust language.

The primary problem with this proposed policy is its attitude towards
use of their trademarks in copies of software, especially modified
versions of the Rust compiler.

From their policy:

  4.1.1 Distribution of unmodified source code or unmodified executable
  code we have compiled

  When you redistribute an unmodified copy of the Rust software, you are
  not changing the quality or nature of it.  Therefore, you may retain
  the Word Marks and the Logos we have placed on the software to
  identify your redistribution -- whether that redistribution is made
  via physical products, physical media, or download, and whether that
  redistribution consists of unmodified source code or executables.  If
  you autogenerate unmodified documentation created by the Project using
  rustdoc, you do not have to remove any Word Marks or Logos.  This only
  applies if you are redistributing an official distribution from the
  Rust Project that has not been changed in any way.

  4.1.2 Distribution of executable code that you have compiled, or
  modified code

  See [cross-reference to ## Uses for which we are granting a license;
  ### Distribution of modified software] for cases where you may modify
  the software and use the Marks and Logos for it.

  You may also use the Word Marks, but not the Logos, to truthfully
  describe the origin of the software that you are providing, that is,
  that the code you are distributing is a modification of our
  software.  You may say, for example, ``compiled from the Rust source at
  GitHub'' or that "we have included tools taken from the Rust project in
  our toolchain.'' You must also remove our Logos.

  If you are creating documentation and have modified it, you do not
  have to remove any Word Marks or Logos that appear in screenshots or
  in the text for illustrative or explanatory purposes.  However, you
  must remove them where the use suggest that the Rust Foundation has
  published or endorsed your version of the documentation, such as on
  the cover.

  Of course, you can place your own trademarks or logos on versions of
  the software to which you have made modifications, because by
  modifying the software you have become the origin of that exact
  version.

  4.1.3 Statements about compatibility, interoperability or derivation

  You may use the Word Marks, but not the Logos, to truthfully describe
  the relationship between your software and ours.  Our Marks should be
  used after a verb or preposition that describes the relationship
  between your software and ours.  So you may say, for example, "the
  Dungeness tool for the Rust compiler" but may not say "the Dungeness
  Rust compiler," which suggests that Dungeness is the source of the
  Rust compiler.  Some other examples that may work for you are:

    [Your software] is written in the Rust language
    [Your software] can compile software written in Rust 
    [Your software] can be used in the Rust compiler toolchain
    [Your software] is based on the official Rust compiler

  4.1.4 Rust the language versus Rust products and Project

  Rust is the name of a language, the name for software, the name of the
  project, and the name of the community.  It must always be clear which
  one you are referring to when you use ``Rust.'' If there is a
  possibility of misinterpretation, you should amend your wording so
  that there can be no misunderstanding.  For example, the term ``Rust
  compiler'' can be interpreted as both the compiler distributed by the
  Project and any compiler that can compile the Rust language.  If you
  are not referring to the compiler distributed by the Project, you must
  change the wording to make it clear that this is not the compiler
  distributed by the Project, such as ``ABC compiler for Rust.''

Here, several problems are apparent.  First of all, there is an emphasis
on the redistribution of source or binary code unmodified by anyone but
the Rust developers: that in itself is not a problem, but it is
concerning.

4.1.2, 4.1.3, 4.1.4, however, imply that it is forbidden to use the word
``Rust'' to directly describe modified executable code.  For example, if
you modify the Rust compiler in an unapproved manner, it can no longer
call itself the ``Rust compiler''.  Unfortunately, rewording each
reference in the Rust compiler is not feasible, making the compiler
effectively proprietary, as one cannot freely convey modified versions
of the compiler.

4.2.1, 4.3.1 further expand on this:

  4.2.1 Distribution of modified software

  You may use the Word Marks and the Logos for the distribution of a
  modified version of the Rust programming language, compiler, or the
  Cargo package manager, provided that the modifications are limited to:

    - code adjustments for the purpose of porting to a different
      platform, architecture, or system, or integrating the software
      with the packaging system of that platform; or
    - fixing local paths; or
    - adding patches that have been made available upstream and
      accepted, or submitted upstream and not yet rejected (but you must
      remove either the patch or the trademark once the patch has been
      rejected)

  4.3.1 Use of the marks in toolchains or other software for use with
  Rust

  Using the Marks in the name of a tool for use in the Rust toolchain, a
  software program written in the Rust language, or a software program
  compatible with Rust software, will most likely require a license.
  The ``RS'' abbreviation can be used instead.

Restricting redistribution of modified versions of the Rust compiler to
simple ports, and making difficult the development of other Rust
compilers.  If you are writing Rust code for Emacs, please stop.  As
things are, that code is not going to be useful.

\f

The policy is also politically discriminatory: the policy's FAQ section
contains

  Can I use a modified version of the logo on social media?

  In general, we prohibit the modification of the Rust logo for any
  purpose, except to scale it.  This includes distortion, transparency,
  color-changes affiliated with for-profit brands or political
  ideologies.

  On the other hand, if you would like to change the colors of the Rust
  logo to communicate allegiance with a community movement, we simply
  ask that you run the proposed logo change by us by emailing the file
  to contact@rustfoundation.org with a description of the changes you’re
  proposing.  In the future, we intend to publish new versions of the
  Rust logo to accord with community movements (ex: LGBTQIA+ Pride
  Month, Black Lives Matter, etc.)

and 5.3.1 contains:

5.3.1 Events & Conferences

  Events and conferences are a valuable opportunity to grow your network
  and learning.  Please contact us at `Where to go for further
  information' below if you would like to hold an event using the Marks
  in the event name.  We will consider requests to use the Marks on a
  case by case basis, but at a minimum, would expect events and
  conferences using the Marks to be non-profit-making, focused on
  discussion of, and education on, Rust software, prohibit the carrying
  of firearms, comply with local health regulations, and have a robust
  Code of Conduct.

While not directly related to using Rust to write software, it sure
makes me uncomfortable to think about producing long-lasting free
software with a compiler under the firm grasp of developers who seem to
care more about firearms restrictions and issues better left for
soc.motss...

Re: Consideration for Rust contributions in Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]


Po Lu via "Emacs development discussions." <emacs-devel@gnu.org> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> There are no real ideological reasons.
>
> This has changed.  From my POV, Rust is now completely unsuitable for
> writing code for Emacs.
>
> The Rust Foundation has published a draft trademark policy.  They will
> apply this policy to all use of the Rust trademark, including towards
> documentation surrounding other implementations of the Rust language.

…

> 5.3.1 Events & Conferences
>
>   Events and conferences are a valuable opportunity to grow your network
>   and learning.  Please contact us at `Where to go for further
>   information' below if you would like to hold an event using the Marks
>   in the event name.

Most of the other parts sound like “Firefox if Javascript were named
Firefox Script”, which is mainly annoying, but this one is awful.

Imagine being an organizer of an existing long-standing Rust event that
helped to get Rust where it is today and now being expected to crawl to
them asking for permission to keep the name of the event.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Imagine being an organizer of an existing long-standing Rust event that
  > helped to get Rust where it is today and now being expected to crawl to
  > them asking for permission to keep the name of the event.

One could imagine renaming the event to Bust, Dust, Gust, Lust or
maybe Distrust.

But we need to keep focus on the aspects of this policy which are
worse than merely irritating.  The adoption of this policy would make
the unmodified Rust compiler source code nonfree unless we devise a
way to remove all uses of the trademark, as trademark law understands
the concept.

How MUCH alterattion that would require, and how much work that would
be, I am not sure.  Would a global replace of `rust' with `lust' in
the source files of the Rust compiler suffice?  It would include a
similar renaming of source file names.  It would not be the minimal
possible change as measured by diff, but it might be the change that
is the least work.

One would have the installation script create a symlink or alias from
/usr/bin/rust to /usr/bin/lust.  Trademark law, from what lawyers have
told me, covers communications to human beings, not commands for
programs.

Pu Lu, can you find places where discussion of this is happening, and
tell us?

Would someone with a fast build machine like to volunteer to play with
such renamings?

I hope they will change the policy before adopting it for real.
It would be better if the unmodified files were free software
and we could distribute them unmodified.  We have no reason to make any change
in Rust sources except to excape gratuitous trademark problems.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Richard Stallman <rms@gnu.org> writes:

> But we need to keep focus on the aspects of this policy which are
> worse than merely irritating.  The adoption of this policy would make
> the unmodified Rust compiler source code nonfree unless we devise a
> way to remove all uses of the trademark, as trademark law understands
> the concept.
>
> How MUCH alterattion that would require, and how much work that would
> be, I am not sure.  Would a global replace of `rust' with `lust' in
> the source files of the Rust compiler suffice?  It would include a
> similar renaming of source file names.  It would not be the minimal
> possible change as measured by diff, but it might be the change that
> is the least work.

I don't know.

> One would have the installation script create a symlink or alias from
> /usr/bin/rust to /usr/bin/lust.  Trademark law, from what lawyers have
> told me, covers communications to human beings, not commands for
> programs.
>
> Pu Lu, can you find places where discussion of this is happening, and
> tell us?

`Po Lu' please, thanks.

Unfortunately, I can't really follow these issues.  I have no idea where
this discussion is happening.

I wonder how GCC will deal with these issues, seeing as a Rust compiler
is already part of GCC.

Re: Consideration for Rust contributions in Emacs

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: "Dr. Arne Babenhauserheide" <arne_bab@web.de>,  emacs-devel@gnu.org
> Date: Sat, 15 Apr 2023 11:40:40 +0800
> 
> Unfortunately, I can't really follow these issues.  I have no idea where
> this discussion is happening.
> 
> I wonder how GCC will deal with these issues, seeing as a Rust compiler
> is already part of GCC.

Not just GCC, GDB as well; see gdb/rust-*.[ch] files in the GDB source
tree.

Richard, I indeed think this is something GCC and GDB folks need to
look into, not us here.  It affects them much more than it affects
Emacs.

Re: Consideration for Rust contributions in Emacs

[Dmitry Gutov]

On 11/04/2023 15:39, Po Lu via Emacs development discussions. wrote:
> The Rust Foundation has published a draft trademark policy.  They will
> apply this policy to all use of the Rust trademark, including towards
> documentation surrounding other implementations of the Rust language.

Thankfully it's a "draft". There is currently a minor storm on Twitter 
regarding this proposed policy, so we can help for some positive changes.

https://twitter.com/steveklabnik/status/1645544552206327811, etc.

Re: Consideration for Rust contributions in Emacs

[tomas]

[-- Attachment #1: Type: text/plain, Size: 904 bytes --]

On Wed, Apr 12, 2023 at 03:36:29AM +0300, Dmitry Gutov wrote:
> On 11/04/2023 15:39, Po Lu via Emacs development discussions. wrote:
> > The Rust Foundation has published a draft trademark policy.  They will
> > apply this policy to all use of the Rust trademark, including towards
> > documentation surrounding other implementations of the Rust language.
> 
> Thankfully it's a "draft". There is currently a minor storm on Twitter
> regarding this proposed policy, so we can help for some positive changes.
> 
> https://twitter.com/steveklabnik/status/1645544552206327811, etc.

Hopefully. I don't twitter, but thanks for the heads-up.

Still somewhat concerning that those things happen at all:
one gets the impression that people are throwing things at
walls and seeing what sticks.

There are several reasons for me to stay away from Rust.
This is just one more.

Cheers
-- 
t

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What you've sent is very alarming.  I need to study the whole thing.
Pu Lu, would you please send me the URL of the document you are looking at?
Also, what is its title, and whose statement is it?

Also, if you can tell, when was it published?

Others: I asked Po Lu to send that to me
so that you won't all send me many identical copies.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What you've sent is very alarming.  I need to study the whole thin.
Pu Lu, would you please send me the URL of the document you are looking at?
Also, what is its title, and whose statement is it?

Also, if you can tell, when was it published?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: comms@dabrev.com, allred.sean@gmail.com, emacs-devel@gnu.org
> Date: Wed, 12 Apr 2023 21:02:18 -0400
> 
> What you've sent is very alarming.  I need to study the whole thin.
> Pu Lu, would you please send me the URL of the document you are looking at?
> Also, what is its title, and whose statement is it?

Since Po Lu didn't respond, I assume he has email delivery problems
again, and will respond in his stead.

The URL where you can find this document is:

  https://docs.google.com/document/d/1ErZlwz9bbSI43dNo-rgQdkovm2h5ycuW220mWSOAuok/edit
  https://docs.google.com/document/d/1ErZlwz9bbSI43dNo-rgQdkovm2h5ycuW220mWSOAuok/edit#heading=h.3znysh7

The title is "Rust Trademark Policy".  Don't know a formal answer to
the "whose statement is it" part, but the announcement requests that
feedback and questions be sent to trademark@rustfoundation.org.

> Also, if you can tell, when was it published?

Two days ago.

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Since Po Lu didn't respond, I assume he has email delivery problems
> again, and will respond in his stead.

I responded to RMS off-list, since the details are not exactly relevant
to Emacs.

Thanks.

Re: Consideration for Rust contributions in Emacs

[Dmitry Gutov]

On 13/04/2023 04:02, Richard Stallman wrote:
> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
> 
> What you've sent is very alarming.  I need to study the whole thin.
> Pu Lu, would you please send me the URL of the document you are looking at?
> Also, what is its title, and whose statement is it?
> 
> Also, if you can tell, when was it published?

Again: for now this is only a draft.

There is no need to draw long-term conclusions about Rust from it yet, 
and publish those as if the new terms are a concluded matter.

Re: Consideration for Rust contributions in Emacs

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Again: for now this is only a draft.
>
> There is no need to draw long-term conclusions about Rust from it yet,
> and publish those as if the new terms are a concluded matter.

It's just as alarming, because the draft is currently what they intend
to make policy.

Re: Consideration for Rust contributions in Emacs

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > There is no need to draw long-term conclusions about Rust from it yet,
  > > and publish those as if the new terms are a concluded matter.

  > It's just as alarming, because the draft is currently what they intend
  > to make policy.

I agree.  We face the challenge of dissuading them.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: Consideration for Rust contributions in Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 769 bytes --]


Troy Hinckley <comms@dabrev.com> writes:

> Po Lu already provided one; Emacs needs to support old platforms like MS-DOS. So that rules out LLVM. 

GCCrs might help with that: https://rust-gcc.github.io/

Once that’s released and stable in GCC, Rust is finally safe to use for
those who want at least two independent implementations (like me).

> Are there others?

There was a point about complexity: adding another language besides C
and elisp increases complexity for contributors and maintainers a lot.

Also the gains from memory safety are much lower than for much other
software, because in Emacs memory-safety is already provided by elisp.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

Re: Consideration for Rust contributions in Emacs

[John Yates]

On Mon, Jan 23, 2023 at 9:26 AM Dr. Arne Babenhauserheide
<arne_bab@web.de> wrote:
>
> There was a point about complexity: adding another language besides C
> and elisp increases complexity for contributors and maintainers a lot.

Once upon a time, functions deemed performance critical were
implemented within the C core.  Over time that impetus has
diminished greatly.  I have observed large amounts of functionality
migrate from C to lisp.  Native compilation can only have reinforced
that evolution.

The net effect has been to reduce the need for most emacs developers
ever to need to work in any language other than lisp.

/john

Re: Consideration for Rust contributions in Emacs

[Eli Zaretskii]

> From: John Yates <john@yates-sheets.org>
> Date: Mon, 23 Jan 2023 11:51:32 -0500
> Cc: Troy Hinckley <comms@dabrev.com>, Sean Allred <allred.sean@gmail.com>,
>  emacs-devel@gnu.org
> 
> On Mon, Jan 23, 2023 at 9:26 AM Dr. Arne Babenhauserheide
> <arne_bab@web.de> wrote:
> >
> > There was a point about complexity: adding another language besides C
> > and elisp increases complexity for contributors and maintainers a lot.
> 
> Once upon a time, functions deemed performance critical were
> implemented within the C core.  Over time that impetus has
> diminished greatly.  I have observed large amounts of functionality
> migrate from C to lisp.  Native compilation can only have reinforced
> that evolution.
> 
> The net effect has been to reduce the need for most emacs developers
> ever to need to work in any language other than lisp.

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.

Moreover, familiarity with the internals implemented in C is IME quite
necessary even for Emacs developers who almost never touch that layer.

So the above is true only up to a point.

Re: Consideration for Rust contributions in Emacs

[John Yates]

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

Re: Consideration for Rust contributions in Emacs

[Eli Zaretskii]

> 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

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   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
   > . . .
   > On Mon, Jan 23, 2023 at 12:06 PM Eli Zaretskii <eliz@gnu.org> wrote:
   > . . .
   > > 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 . . .

I can speak to that.  As someone not competent to hack on emacs at the C
level, I nevertheless find I need to dip into the C code from time to
time in order to understand what the elisp is doing, with increasing
frequency over the last 30-odd years.  I think that shows a net elisp =>
C migration during that time.

   A good example is the machinery that triggers redisplay and how it
   integrates into the Emacs "main loop".

I try really hard to stay out of redisplay.  ;-}

					-- Bob Rogers
					   http://www.rgrjr.com/

Re: Consideration for Rust contributions in Emacs

[Eli Zaretskii]

> Date: Mon, 23 Jan 2023 11:44:20 -0800
> From: Bob Rogers <rogers@rgrjr.com>
> 
>    A good example is the machinery that triggers redisplay and how it
>    integrates into the Emacs "main loop".
> 
> I try really hard to stay out of redisplay.  ;-}

I didn't mean redisplay itself, I meant the way it is triggered in
Emacs.  IME, many people don't understand that, and, for example,
think that scroll commands actually scroll the text in the window.
Which, of course, is not what happens.

Re: Consideration for Rust contributions in Emacs

[Bob Rogers]

   From: Eli Zaretskii <eliz@gnu.org>
   Date: Mon, 23 Jan 2023 21:56:16 +0200

   > Date: Mon, 23 Jan 2023 11:44:20 -0800
   > From: Bob Rogers <rogers@rgrjr.com>
   > 
   >    A good example is the machinery that triggers redisplay and how it
   >    integrates into the Emacs "main loop".
   > 
   > I try really hard to stay out of redisplay.  ;-}

   I didn't mean redisplay itself, I meant the way it is triggered in
   Emacs.

Ah, I guess I never needed to make the distinction.

   IME, many people don't understand that, and, for example, think that
   scroll commands actually scroll the text in the window.  Which, of
   course, is not what happens.

That I've seen, from watching emacs repaint after scrolling over a slow
connection.

					-- Bob

Re: Consideration for Rust contributions in Emacs

[Dr. Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 734 bytes --]


John Yates <john@yates-sheets.org> writes:

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

Incidentally the same happens in Guile: the better the runtime gets, the
more functionality moves from C to Scheme. It seems that when you create
a tool with a Lisp runtime, moving as many things into the runtime as
viable might be a natural tendency.

And just like Emacs, Guile derives serious added value from that,
because the migrated code interacts much better with existing Lisp code.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

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

Re: Consideration for Rust contributions in Emacs

[Po Lu]

"Dr. Arne Babenhauserheide" <arne_bab@web.de> writes:

> GCCrs might help with that: https://rust-gcc.github.io/
>
> Once that’s released and stable in GCC, Rust is finally safe to use for
> those who want at least two independent implementations (like me).

The language standard library must also be ported to both the Unix and
DJGPP platforms.  On MS-DOS, it must also be made unexec ready, because
only the unexec build is supported there.

> Also the gains from memory safety are much lower than for much other
> software, because in Emacs memory-safety is already provided by elisp.

Has anyone even demonstrated that memory safety is a problem for Emacs?
The only program where it matters, that runs on most computers, is a web
browser.  And even there it only papers over the more fundamental
problem, which is that web browsers provide an easy means to run
proprietary JavaScript code without the user even knowing it exists.

Re: Consideration for Rust contributions in Emacs

[Robert Pluim]

>>>>> On Sun, 22 Jan 2023 20:00:49 -0600, Sean Allred <allred.sean@gmail.com> said:

    Sean> The last significant endeavor in this direction that I'm aware of was
    Sean> Remacs -- but it appears development has petered out for one reason or
    Sean> another. I don't think it's a lost cause in the grand scheme of things,
    Sean> but this clearly is not a ship that can/would/should change course very
    Sean> easily.

Remacs was doomed from the start since they deliberately decided not to
ask for copyright assignment, which meant merging it into Emacs would
have been a massive pain, so nobody on the Emacs side of things got
involved.

Robert
--