Send Emacs-devel mailing list submissions to
emacs-devel@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/emacs-develor, via email, send a message with subject or body 'help' to
emacs-devel-request@gnu.org
You can reach the person managing the list at
emacs-devel-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Emacs-devel digest..."
Today's Topics:
1. Re: emacs-29 faee7e1f1b: ; * lisp/treesit.el
(treesit-font-lock-fontify-region): Minor fix. (Yuan Fu)
2. Consideration for Rust contributions in Emacs (Troy Hinckley)
3. Re: Make all tree-sitter modes optional
(Pedro Andres Aranda Gutierrez)
4. Re: Make all tree-sitter modes optional (Eli Zaretskii)
5. Re: Consideration for Rust contributions in Emacs (Po Lu)
6. Re: Make all tree-sitter modes optional (Eli Zaretskii)
7. Re: Consideration for Rust contributions in Emacs (Daniel Martín)
8. Re: Consideration for Rust contributions in Emacs (Po Lu)
Message: 1
Date: Sat, 21 Jan 2023 14:36:31 -0800
From: Yuan Fu <casouri@gmail.com>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: emacs-29 faee7e1f1b: ; * lisp/treesit.el
(treesit-font-lock-fontify-region): Minor fix.
Message-ID: <
360C06CD-DDA8-4543-A337-B31A108C0419@gmail.com>
Content-Type: text/plain; charset=us-ascii
On Jan 19, 2023, at 10:15 AM, Dmitry Gutov <dgutov@yandex.ru> wrote:
On 18/01/2023 08:52, Yuan Fu wrote:
- (when (and (eq 'undecided treesit--font-lock-fast-mode)
- (> (time-to-seconds
+ (when (and (> (time-to-seconds
(time-subtract end-time start-time))
0.01))
Note that now the 'and' form only has 1 element inside.
Thanks for the catch, I fixed it.
Yuan
Message: 2
Date: Sat, 21 Jan 2023 15:48:28 -0700
From: Troy Hinckley <comms@dabrev.com>
To: emacs-devel@gnu.org
Subject: Consideration for Rust contributions in Emacs
Message-ID: <b972c046-8c29-42eb-92c9-0d5b5fe03551@Spark>
Content-Type: text/plain; charset="utf-8"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <
https://lists.gnu.org/archive/html/emacs-devel/attachments/20230121/65c13475/attachment.htm>
Message: 3
Date: Sun, 22 Jan 2023 07:23:17 +0100
From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Make all tree-sitter modes optional
Message-ID:
<
CAO48Bk8nPyxhqa0qaGaKXPaSk2hOaZ1pNWkTno5QUqLS7otYjQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Eli writes:
What message? I asked to show these messages before, and I didn't see
your answer to that question. We don't intend to have Emacs show any
such messages just because you don't have tree-sitter installed.
Just try M-x c-ts-mode and you'l get this message *four* times (side
question, isn't one enough?)
⛔ Warning (treesit): Cannot activate tree-sitter, because tree-sitter
library is not compiled with Emacs
Another question: If I can't use the command, wouldn't it be better if I
had no access to it?
Best, /PA
PS: BTW, at this point, removing the 'Warning (treesit)' would leave a
coherent message WRT the no entry sign, but that's another thread ;-)
On Sat, 21 Jan 2023 at 12:48, Eli Zaretskii <eliz@gnu.org> wrote:
From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
Date: Sat, 21 Jan 2023 12:30:26 +0100
Cc: emacs-devel@gnu.org
Eli writes:
Why would it confuse? You also have there stuff like w32-win.el.gz,
which is used only on MS-Windows, and other files that are not
necessarily for your configuration. This is not a problem, and
shouldn't be one.
I don't know, maybe for me there is a difference between the OS specific
stuff, tree-sitter and other stuff in
Emacs:
It is nothing new in Emacs: we provide many packages, some of which
are specific to platforms other than yours, some others need optional
libraries that you don't necessarily have, etc.
tree-sitter modes 'compete' with 'regular' modes and if I don't have
tree-sitter activated at compile time, it
can be misleading to see those files there
I disagree it should mislead anyone, and let's leave it at that.
and 'sub-optimal' (to say the least) to get a message that you
can't use them.
What message? I asked to show these messages before, and I didn't see
your answer to that question. We don't intend to have Emacs show any
such messages just because you don't have tree-sitter installed.
OS related stuff is different in the sense that, well, if I'm on a Linux
system and try to use (you say the
OS)-specific features, it is natural that I get a 'wake-up' message
there and stop trying to do things that make
no sense.
Same thing if you use a Lisp package which requires an optional
library you don't have installed or if you use Emacs which wasn't
built with support for that library. Examples: GnuTLS, HarfBuzz,
librsvg, sqlite3, etc.
As for the rest, having dormant features that _work_ (or are WIP with a
level of maturity enough to be in
master) and only wait for me to test them and activate them if they help
me in my day-to-day interactions
with Emacs, of course, put 10^n n->infinity of those in Emacs, no
problem.
In that sense, if there was a way to disregard *-ts-*.el files in
ELC/ELN compilation and installation when I
compile Emacs _without_ tree-sitter support, the whole picture would be
(once again, IMvHO) much more
coherent.
We don't disregard any Lisp files. When Emacs builds, it compiles all
the files in the source tree. A release tarball comes with *.elc
files already compiled, and *.eln files will only be produced if you
actually load the corresponding *.el package. So I see no problem
here.
From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
Date: Sun, 22 Jan 2023 07:23:17 +0100
Cc: emacs-devel@gnu.org
Eli writes:
What message? I asked to show these messages before, and I didn't see
your answer to that question. We don't intend to have Emacs show any
such messages just because you don't have tree-sitter installed.
Just try M-x c-ts-mode and you'l get this message *four* times (side question, isn't one enough?)
⛔ Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
Thanks. This is an issue we know about, it will be fixed soon,
probably today or tomorrow.
Another question: If I can't use the command, wouldn't it be better if I had no access to it?
The way Emacs implements the "you have no access to the command" is by
signaling an error when/if you try invoking it. So we are okay in
that department.
Message: 5
Date: Sun, 22 Jan 2023 15:44:19 +0800
From: Po Lu <luangruo@yahoo.com>
To: Troy Hinckley <comms@dabrev.com>
Cc: emacs-devel@gnu.org
Subject: Re: Consideration for Rust contributions in Emacs
Message-ID: <
871qnn6mjw.fsf@yahoo.com>
Content-Type: text/plain; charset=utf-8
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.
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.
Message: 6
Date: Sun, 22 Jan 2023 12:46:14 +0200
From: Eli Zaretskii <eliz@gnu.org>
To: paaguti@gmail.com
Cc: emacs-devel@gnu.org
Subject: Re: Make all tree-sitter modes optional
Message-ID: <
83wn5ekft5.fsf@gnu.org>
Content-Type: text/plain; charset=utf-8
Date: Sun, 22 Jan 2023 08:38:31 +0200
From: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
From: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
Date: Sun, 22 Jan 2023 07:23:17 +0100
Cc: emacs-devel@gnu.org
⛔ Warning (treesit): Cannot activate tree-sitter, because tree-sitter library is not compiled with Emacs
Thanks. This is an issue we know about, it will be fixed soon,
probably today or tomorrow.
Should be already fixed on the emacs-29 branch.
Message: 7
Date: Sun, 22 Jan 2023 12:05:51 +0100
From: Daniel Martín <mardani29@yahoo.es>
To: Troy Hinckley <comms@dabrev.com>
Cc: emacs-devel@gnu.org
Subject: Re: Consideration for Rust contributions in Emacs
Message-ID: <
m1k01ej0c0.fsf@yahoo.es>
Content-Type: text/plain; charset=utf-8
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.
Message: 8
Date: Sun, 22 Jan 2023 22:04:11 +0800
From: Po Lu <luangruo@yahoo.com>
To: Daniel Martín <mardani29@yahoo.es>
Cc: Troy Hinckley <comms@dabrev.com>, emacs-devel@gnu.org
Subject: Re: Consideration for Rust contributions in Emacs
Message-ID: <
87pmb664ys.fsf@yahoo.com>
Content-Type: text/plain; charset=utf-8
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.
Subject: Digest Footer
Emacs-devel mailing list
Emacs-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/emacs-devel
End of Emacs-devel Digest, Vol 227, Issue 23
********************************************