Re: Emacs-devel Digest, Vol 227, Issue 23

Re: Emacs-devel Digest, Vol 227, Issue 23

[xiliuya]

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

lists

于 2023年1月23日 GMT+08:00 上午1:00:07, emacs-devel-request@gnu.org 写到:
>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-devel
>or, 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.
>>
>
>
>-- 
>Fragen sind nicht da um beantwortet zu werden,
>Fragen sind da um gestellt zu werden
>Georg Kreisler
>
>Headaches with a Juju log:
>unit-basic-16: 09:17:36 WARNING juju.worker.uniter.operation we should run
>a leader-deposed hook here, but we can't yet
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: <https://lists.gnu.org/archive/html/emacs-devel/attachments/20230122/581f1ca2/attachment.htm>
>
>------------------------------
>
>Message: 4
>Date: Sun, 22 Jan 2023 08:38:31 +0200
>From: Eli Zaretskii <eliz@gnu.org>
>To: Pedro Andres Aranda Gutierrez <paaguti@gmail.com>
>Cc: emacs-devel@gnu.org
>Subject: Re: Make all tree-sitter modes optional
>Message-ID: <83y1pvjcpk.fsf@gnu.org>
>Content-Type: text/plain; charset=utf-8
>
>> 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.
>
>\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.
>
>
>
>------------------------------
>
>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
>********************************************

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