🚀 go-pugleaf

--=-=-Content-Type: text/plain


Philip Kaludercic <philipk@posteo.net> writes:

> Is there a reason we wouldn't want to have support in the core?  Or at
> least GNU ELPA?

Not all of the maintainers of clojure-mode and clojure-ts-mode are on
board with the core development model, particularly copyright
assignment. Initially I wanted to put this straight in the core but
after some discussion we decided not to. I have personally done my
copyright assignment, but for clojure-ts-mode we won't be asking
contributors for it. Therefore, going into GNU ELPA or core then is out
of the question.

> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
> package, from what I see.  From what I recall, the -ts-mode approach was
> a compromise to add some basic support for Tree Sitter in Emacs 29, but
> I am not sure if it was a final decision on the matter, because at least
> from my perspective of following the tree sitter development from a
> close distance, but also from user reports I have heard of since the
> release of Emacs 29, the current approach is slightly confusing.  Adding
> a -ts-mode to ELPA might be misinterpreted as a commitment to the
> current trajectory, and I am not sure if that is intended.

Yeah it is kind of confusing but I'm not sure what the end game is for
all the other *-ts-modes. Non tree-sitter Clojure-mode itself has a lot
of features and is also depended on by some other packages (cider,
inf-clojure). In that regard, we decided trying to keep clojure-ts-mode
and clojure-mode in the same repo would be too complex of a task.
Therefore we put it in it's own repo.

Very long term plans are for clojure-ts-mode to eventually reach feature
parity with clojure-mode and start making it's consumer packages also
use it. That will probably take a number of years though.

>> + (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
>> +  :ignored-files ("doc" "test")
>
> If possible, it is preferable to list ignored files in a .elpaignore
> file, in the repository root directory.

I have made a commit to the repo including one of those .elpaignores.
I'm going to wait a while to tag a new release in case there is other
feedback though. Here is the revised patch


--=-=-Content-Type: text/x-patch
Content-Disposition: attachment;
 filename02-elpa-packages-clojure-ts-mode-new-package.patch

From baf7c0d081cbda5760c8f7523780316fcb041714 Mon Sep 17 00:00:00 2001
From: dannyfreeman <danny@dfreeman.email>
Date: Sat, 12 Aug 2023 14:31:44 -0400
Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 9dac0cd..6ea2057 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -87,6 +87,10 @@
   :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
   :news "CHANGELOG.md")

+ (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
+  :readme "README.md"
+  :news "CHANGELOG.md")
+
  (coffee-mode		:url "https://github.com/defunkt/coffee-mode")

  (corfu-terminal	:url "https://codeberg.org/akib/emacs-corfu-terminal")
--
2.40.1


--=-=-Content-Type: text/plain


--
Danny Freeman

--=-=-=--

Danny Freeman <danny@dfreeman.email> writes:

> Hello,
>
> Clojure-ts-mode is a tree-sitter based mode for clojure editing. I am
> it's maintainer. It can be found here:
> https://github.com/clojure-emacs/clojure-ts-mode
>
> This package is currently listed only on MELPA, but I would also like it
> to be available on NonGNU-ELPA as well.
>
> Please let me know if you have any questions or concerns.

Is there a reason we wouldn't want to have support in the core?  Or at
least GNU ELPA?

If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
package, from what I see.  From what I recall, the -ts-mode approach was
a compromise to add some basic support for Tree Sitter in Emacs 29, but
I am not sure if it was a final decision on the matter, because at least
from my perspective of following the tree sitter development from a
close distance, but also from user reports I have heard of since the
release of Emacs 29, the current approach is slightly confusing.  Adding
a -ts-mode to ELPA might be misinterpreted as a commitment to the
current trajectory, and I am not sure if that is intended.

> From 5d92f6f2054b73cf9fb9a0f81d7ac0064715a6d6 Mon Sep 17 00:00:00 2001
> From: dannyfreeman <danny@dfreeman.email>
> Date: Sat, 12 Aug 2023 14:31:44 -0400
> Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package
>
> ---
>  elpa-packages | 5 +++++
>  1 file changed, 5 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 9dac0cd..6a90468 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -87,6 +87,11 @@
>    :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
>    :news "CHANGELOG.md")
>
> + (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
> +  :ignored-files ("doc" "test")

If possible, it is preferable to list ignored files in a .elpaignore
file, in the repository root directory.

> +  :readme "README.md"
> +  :news "CHANGELOG.md")
> +
>   (coffee-mode		:url "https://github.com/defunkt/coffee-mode")
>
>   (corfu-terminal	:url "https://codeberg.org/akib/emacs-corfu-terminal")
> --
> 2.40.1
>
>
>
> Thank you,

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel <emacs-devel@gnu.org>,  Manuel Uberti
>>  <manuel.uberti@inventati.org>
>> Date: Sat, 12 Aug 2023 19:10:31 +0000
>>
>> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
>> package, from what I see.  From what I recall, the -ts-mode approach was
>> a compromise to add some basic support for Tree Sitter in Emacs 29, but
>> I am not sure if it was a final decision on the matter, because at least
>> from my perspective of following the tree sitter development from a
>> close distance, but also from user reports I have heard of since the
>> release of Emacs 29, the current approach is slightly confusing.  Adding
>> a -ts-mode to ELPA might be misinterpreted as a commitment to the
>> current trajectory, and I am not sure if that is intended.
>
> If you mean that the *-ts-modes could be a minor mode, then I believe
> we found that to be unworkable, except in very rare cases where the
> major mode supporting the same language is very thin and has only a
> couple of simple mode-specific features.  Otherwise, the very
> different way of doing font-lock, indentation, imenu, etc. means that
> basically all the features must be reimplemented anew, and in many
> cases make no sense at all.  So a minor mode is not TRT here.

This was my understanding as well, and while I understand it from a
technical perspective, I have a hunch there must be a tolerable
alternative with a better user interface.

Perhaps this is a point at which the approach at which the major-mode
abstraction breaks down and has to be rethought?  There have been
instances of alternative major modes for different languages in the past
(cperl, perl; js, js2, js3) that have found one way or another to
co-exist, but seeing how this is becoming more and more common, it would
be nice to have some consistent and unified way of expressing these
kinds of alternatives.

> The aspects of these modes that are not yet firmly decided are how to
> activate/deactivate them in a way that would be convenient and simple.
> But I don't think we will be removing the *-ts-modes as major modes,
> no.

I get that we wouldn't want to remove them, out of backwards
compatibility, but is the plan to write more ...-ts-mode major modes?

Danny Freeman <danny@dfreeman.email> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> Is there a reason we wouldn't want to have support in the core?  Or at
>> least GNU ELPA?
>
> Not all of the maintainers of clojure-mode and clojure-ts-mode are on
> board with the core development model, particularly copyright
> assignment. Initially I wanted to put this straight in the core but
> after some discussion we decided not to. I have personally done my
> copyright assignment, but for clojure-ts-mode we won't be asking
> contributors for it. Therefore, going into GNU ELPA or core then is out
> of the question.

That is a pity.  IIRC there is a SLIME-like environment for Clojure,
right?  I don't know if Emacs is also the conventional default
environment for working with the language, but if it is, it seems like
it would be a nice thing to have at least some basic support in the core
:/

Did the discussions on not wanting to contribute anything to the core
take place in some public channel, where one could read up on what the
issues were or clarify some misunderstandings, in case these occurred?

>> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
>> package, from what I see.  From what I recall, the -ts-mode approach was
>> a compromise to add some basic support for Tree Sitter in Emacs 29, but
>> I am not sure if it was a final decision on the matter, because at least
>> from my perspective of following the tree sitter development from a
>> close distance, but also from user reports I have heard of since the
>> release of Emacs 29, the current approach is slightly confusing.  Adding
>> a -ts-mode to ELPA might be misinterpreted as a commitment to the
>> current trajectory, and I am not sure if that is intended.
>
> Yeah it is kind of confusing but I'm not sure what the end game is for
> all the other *-ts-modes. Non tree-sitter Clojure-mode itself has a lot
> of features and is also depended on by some other packages (cider,
> inf-clojure). In that regard, we decided trying to keep clojure-ts-mode
> and clojure-mode in the same repo would be too complex of a task.
> Therefore we put it in it's own repo.
>
> Very long term plans are for clojure-ts-mode to eventually reach feature
> parity with clojure-mode and start making it's consumer packages also
> use it. That will probably take a number of years though.

So you can also confirm Eli's take, that it is unfeasible to merge the
two major modes?

>>> + (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
>>> +  :ignored-files ("doc" "test")
>>
>> If possible, it is preferable to list ignored files in a .elpaignore
>> file, in the repository root directory.
>
> I have made a commit to the repo including one of those .elpaignores.
> I'm going to wait a while to tag a new release in case there is other
> feedback though. Here is the revised patch

I don't think there is much left that can be changed any more, just keep
in mind that ELPA doesn't use tags to designate package releases, but it
consults Git to detect the latest commit to modify the ";; Version:" tag
in the package header.

Philip Kaludercic <philipk@posteo.net> writes:

> That is a pity.  IIRC there is a SLIME-like environment for Clojure,
> right?  I don't know if Emacs is also the conventional default
> environment for working with the language, but if it is, it seems like
> it would be a nice thing to have at least some basic support in the core
> :/

cider is the SLIME-like environment you are referring to. It lives only
in Non-GNU elpa and is in fact a conventional default environment for
experienced clojure developers. I have worked with many of them and most
use a "starter kit" like doom or spacemacs and don't really think about
any of the stuff under the hood. Even among those that have a more
traditional configuration, I have never heard anyone express a desire to
have support in the core. Emacs now ships with Non-GNU ELPA enabled by
default, so it is pretty trivial to start fresh with vanilla emacs and
call `M-x package-install cider` to have a nice IDE experience.

> Did the discussions on not wanting to contribute anything to the core
> take place in some public channel, where one could read up on what the
> issues were or clarify some misunderstandings, in case these occurred?

Some of the conversation was in a github issue, other conversations took
place in closed ecosystems like slack or discord, I don't really
remember which. I don't think there were any misunderstandings and
consider the matter closed, but I will let you judge for yourself. This
was one place I remember having those discussions:
https://github.com/clojure-emacs/clojure-mode/issues/640

There may be more like it here on the mailing list and the various
clojure-emacs issue trackers on github

> So you can also confirm Eli's take, that it is unfeasible to merge the
> two major modes?

Yes I would agree with Eli here. I do think it is unfeasible to merge
them. My first attempt at writing clojure-ts-mode was in
clojure-mode.el, but it was much simpler to keep the packages separate
in my experience.

As a user of a couple different tree-sitter grammars, I found the ones
defined in their own modes easier to configure like c-ts-mode and
typescript-ts-mode (which is a godsend, before this and eglot,
typescript programming in emacs was miserable to configure). That is all
personal opinion of course, other may have a different preference.

> I don't think there is much left that can be changed any more, just keep
> in mind that ELPA doesn't use tags to designate package releases, but it
> consults Git to detect the latest commit to modify the ";; Version:" tag
> in the package header.

Yes, I will be sure to update the package header as well. I have one
other package in gnu-elpa and remember having to do all of that there.

Thank you,
--
Danny Freeman

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: emacs-devel <emacs-devel@gnu.org>,  Manuel Uberti
>  <manuel.uberti@inventati.org>
> Date: Sat, 12 Aug 2023 19:10:31 +0000
>
> If added to GNU ELPA and NonGNU ELPA, this would be the first *-ts-mode
> package, from what I see.  From what I recall, the -ts-mode approach was
> a compromise to add some basic support for Tree Sitter in Emacs 29, but
> I am not sure if it was a final decision on the matter, because at least
> from my perspective of following the tree sitter development from a
> close distance, but also from user reports I have heard of since the
> release of Emacs 29, the current approach is slightly confusing.  Adding
> a -ts-mode to ELPA might be misinterpreted as a commitment to the
> current trajectory, and I am not sure if that is intended.

If you mean that the *-ts-modes could be a minor mode, then I believe
we found that to be unworkable, except in very rare cases where the
major mode supporting the same language is very thin and has only a
couple of simple mode-specific features.  Otherwise, the very
different way of doing font-lock, indentation, imenu, etc. means that
basically all the features must be reimplemented anew, and in many
cases make no sense at all.  So a minor mode is not TRT here.

The aspects of these modes that are not yet firmly decided are how to
activate/deactivate them in a way that would be convenient and simple.
But I don't think we will be removing the *-ts-modes as major modes,
no.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
>> Date: Sat, 12 Aug 2023 20:22:32 +0000
>>
>> This was my understanding as well, and while I understand it from a
>> technical perspective, I have a hunch there must be a tolerable
>> alternative with a better user interface.
>>
>> Perhaps this is a point at which the approach at which the major-mode
>> abstraction breaks down and has to be rethought?  There have been
>> instances of alternative major modes for different languages in the past
>> (cperl, perl; js, js2, js3) that have found one way or another to
>> co-exist, but seeing how this is becoming more and more common, it would
>> be nice to have some consistent and unified way of expressing these
>> kinds of alternatives.
>
> If someone suggests such an arrangement, and demonstrates its
> viability in at least one example, we could discuss that and perhaps
> decide on migration towards such an approach.  So far, no one came
> with any workable ideas, AFAIR.

OK good to know that there is potential interest.  I had a few ideas I
wanted to try out.  As soon as (or if ever) I have something working,
I'll push the code to a feature/ branch and ping this thread again

>> > The aspects of these modes that are not yet firmly decided are how to
>> > activate/deactivate them in a way that would be convenient and simple.
>> > But I don't think we will be removing the *-ts-modes as major modes,
>> > no.
>>
>> I get that we wouldn't want to remove them, out of backwards
>> compatibility, but is the plan to write more ...-ts-mode major modes?
>
> Yes, I think so.  There doesn't seem to be any good alternative in
> existence.

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Sat, 12 Aug 2023 20:22:32 +0000
>
> This was my understanding as well, and while I understand it from a
> technical perspective, I have a hunch there must be a tolerable
> alternative with a better user interface.
>
> Perhaps this is a point at which the approach at which the major-mode
> abstraction breaks down and has to be rethought?  There have been
> instances of alternative major modes for different languages in the past
> (cperl, perl; js, js2, js3) that have found one way or another to
> co-exist, but seeing how this is becoming more and more common, it would
> be nice to have some consistent and unified way of expressing these
> kinds of alternatives.

If someone suggests such an arrangement, and demonstrates its
viability in at least one example, we could discuss that and perhaps
decide on migration towards such an approach.  So far, no one came
with any workable ideas, AFAIR.

> > The aspects of these modes that are not yet firmly decided are how to
> > activate/deactivate them in a way that would be convenient and simple.
> > But I don't think we will be removing the *-ts-modes as major modes,
> > no.
>
> I get that we wouldn't want to remove them, out of backwards
> compatibility, but is the plan to write more ...-ts-mode major modes?

Yes, I think so.  There doesn't seem to be any good alternative in
existence.

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: emacs-devel <emacs-devel@gnu.org>,  Manuel Uberti
>  <manuel.uberti@inventati.org>
> Date: Sat, 12 Aug 2023 20:31:20 +0000
>
> Danny Freeman <danny@dfreeman.email> writes:
>
> > Not all of the maintainers of clojure-mode and clojure-ts-mode are on
> > board with the core development model, particularly copyright
> > assignment. Initially I wanted to put this straight in the core but
> > after some discussion we decided not to. I have personally done my
> > copyright assignment, but for clojure-ts-mode we won't be asking
> > contributors for it. Therefore, going into GNU ELPA or core then is out
> > of the question.
>
> That is a pity.  IIRC there is a SLIME-like environment for Clojure,
> right?  I don't know if Emacs is also the conventional default
> environment for working with the language, but if it is, it seems like
> it would be a nice thing to have at least some basic support in the core
> :/

I agree.  Perhaps the contributions to clojure-ts-mode could be
re-assessed: those that are small don't need copyright assignments.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: emacs-devel <emacs-devel@gnu.org>,  Manuel Uberti
>>  <manuel.uberti@inventati.org>
>> Date: Sat, 12 Aug 2023 20:31:20 +0000
>>
>> Danny Freeman <danny@dfreeman.email> writes:
>>
>> > Not all of the maintainers of clojure-mode and clojure-ts-mode are on
>> > board with the core development model, particularly copyright
>> > assignment. Initially I wanted to put this straight in the core but
>> > after some discussion we decided not to. I have personally done my
>> > copyright assignment, but for clojure-ts-mode we won't be asking
>> > contributors for it. Therefore, going into GNU ELPA or core then is out
>> > of the question.
>>
>> That is a pity.  IIRC there is a SLIME-like environment for Clojure,
>> right?  I don't know if Emacs is also the conventional default
>> environment for working with the language, but if it is, it seems like
>> it would be a nice thing to have at least some basic support in the core
>> :/
>
> I agree.  Perhaps the contributions to clojure-ts-mode could be
> re-assessed: those that are small don't need copyright assignments.

I don't think it's going to be possible. Primary contributors do no want
to put this in core and do not want to require copyright assignment to
contribute to clojure-ts-mode. Clojure-mode and cider were never moved
to the core for the same reason. I have already had this conversation
with them a number of times but was unable to make a convincing
argument. And I am inclined to agree that keeping clojure-ts-mode under
the same development model as the rest of the clojure emacs packages is
the best path forward right now.

I do understand where yall are coming from in desiring to have
clojure-ts-mode in the core. Again, I advocated for doing this for a
while, but that's not the consensus among clojure emacs devs.

Thank you,
--
Danny Freeman

Eli Zaretskii <eliz@gnu.org> writes:
> Don't agree because they oppose that as a matter of principle, or
> don't agree because they think it's too much work?

A matter of principle.

> I'm suggesting to look at the numbers and see who of the contributors
> really needs to sign the legal paperwork.  The results might surprise
> us, but even if they don't, what possible harm could it do to collect
> those LOC counts for each contributor, so that we all are on the same
> page regarding the magnitude of the problem?
>
> Or let me turn the table ans ask: suppose no CA paperwork was needed:
> would they still oppose adding these modes to Emacs?

Yes.

> Maybe the people involved don't really want to see this in core even
> if possible.  But if so, I guess they are unwilling to contribute the
> package to Emacs, which makes this whole discussion futile and
> pointless to begin with.

Even if it's possible, I know the consensus is that we do not want the
package in the core right now. I don't see that consensus changing.

>> Clojure-mode and cider were never moved to the core for the same
>> reason. I have already had this conversation with them a number of
>> times but was unable to make a convincing argument.
>
> What are the counter-arguments?

I will try to re-summarize the arguments in my own words:

1. Copy right assignment paper work is a barrier to contribution.
2. Cider/clojure-mode/inf-clojure/clojure-ts-mode are all developed by
the same group of people. Keeping them under the same development model
is easier to manage and facilitates coordinating changes across all the
packages. Putting one of these in the core would make this harder.
3. Non-GNU ELPA makes it easy for people to get these packages without
much trouble, since it one of the default package repositories the Emacs
ships with.

I agree with the second/third points. We would like to eventually
have clojure-ts-mode be able to take the place of clojure-mode as a
dependency of the other packages like cider. Keeping it under the same
development model is the right choice to reach that goal IMO. Non-GNU
ELPA and licensing with GPL3 is a good compromise, where we keep the
clojure emacs development model, but still have things relatively easy
to get started with out of the box.

Thank you,
--
Danny Freeman

> From: Danny Freeman <danny@dfreeman.email>
> Cc: Philip Kaludercic <philipk@posteo.net>, danny@dfreeman.email,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> Date: Sun, 13 Aug 2023 09:02:20 -0400
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I agree.  Perhaps the contributions to clojure-ts-mode could be
> > re-assessed: those that are small don't need copyright assignments.
>
> I don't think it's going to be possible. Primary contributors do no want
> to put this in core and do not want to require copyright assignment to
> contribute to clojure-ts-mode.

Don't agree because they oppose that as a matter of principle, or
don't agree because they think it's too much work?

I'm suggesting to look at the numbers and see who of the contributors
really needs to sign the legal paperwork.  The results might surprise
us, but even if they don't, what possible harm could it do to collect
those LOC counts for each contributor, so that we all are on the same
page regarding the magnitude of the problem?

Or let me turn the table ans ask: suppose no CA paperwork was needed:
would they still oppose adding these modes to Emacs?

Maybe the people involved don't really want to see this in core even
if possible.  But if so, I guess they are unwilling to contribute the
package to Emacs, which makes this whole discussion futile and
pointless to begin with.

> Clojure-mode and cider were never moved to the core for the same
> reason. I have already had this conversation with them a number of
> times but was unable to make a convincing argument.

What are the counter-arguments?

> From: Danny Freeman <danny@dfreeman.email>
> Cc: Danny Freeman <danny@dfreeman.email>, philipk@posteo.net,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> Date: Sun, 13 Aug 2023 09:35:36 -0400
>
>
> Eli Zaretskii <eliz@gnu.org> writes:
> > Don't agree because they oppose that as a matter of principle, or
> > don't agree because they think it's too much work?
>
> A matter of principle.
>
> > I'm suggesting to look at the numbers and see who of the contributors
> > really needs to sign the legal paperwork.  The results might surprise
> > us, but even if they don't, what possible harm could it do to collect
> > those LOC counts for each contributor, so that we all are on the same
> > page regarding the magnitude of the problem?
> >
> > Or let me turn the table ans ask: suppose no CA paperwork was needed:
> > would they still oppose adding these modes to Emacs?
>
> Yes.

I'm at a loss how people who develop an Emacs package can object to
adding their package to Emacs.  But so be it.

Eli Zaretskii <eliz@gnu.org> writes:

> I'm at a loss how people who develop an Emacs package can object to
> adding their package to Emacs.  But so be it.

Well down the road when clojure-ts-mode has stabilized I will make sure
we will revisit the idea of moving it to the core. Until then, I hope
y'all see the value of making it available in NonGNU ELPA.

Thank you,
--
Danny Freeman

Danny Freeman <danny@dfreeman.email> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'm at a loss how people who develop an Emacs package can object to
>> adding their package to Emacs.  But so be it.
>
> Well down the road when clojure-ts-mode has stabilized I will make sure
> we will revisit the idea of moving it to the core. Until then, I hope
> y'all see the value of making it available in NonGNU ELPA.


Bumping this thread. Will y'all consider listing this on non-gnu elpa?

Thank you,
--
Danny Freeman

Danny Freeman <danny@dfreeman.email> writes:

> Danny Freeman <danny@dfreeman.email> writes:
>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> I'm at a loss how people who develop an Emacs package can object to
>>> adding their package to Emacs.  But so be it.
>>
>> Well down the road when clojure-ts-mode has stabilized I will make sure
>> we will revisit the idea of moving it to the core. Until then, I hope
>> y'all see the value of making it available in NonGNU ELPA.
>
>
> Bumping this thread. Will y'all consider listing this on non-gnu elpa?

There seems to be no objection against adding it, despite the name.  Can
you confirm that this is the latest version of the patch you would like
to have applies to nongnu.git:

From baf7c0d081cbda5760c8f7523780316fcb041714 Mon Sep 17 00:00:00 2001
From: dannyfreeman <danny@dfreeman.email>
Date: Sat, 12 Aug 2023 14:31:44 -0400
Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package

---
 elpa-packages | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/elpa-packages b/elpa-packages
index 9dac0cd..6ea2057 100644
--- a/elpa-packages
+++ b/elpa-packages
@@ -87,6 +87,10 @@
   :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
   :news "CHANGELOG.md")

+ (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
+  :readme "README.md"
+  :news "CHANGELOG.md")
+
  (coffee-mode		:url "https://github.com/defunkt/coffee-mode")

  (corfu-terminal	:url "https://codeberg.org/akib/emacs-corfu-terminal")
--
2.40.1


>
> Thank you,

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

It appears that there is no clojure-mode command in core Emacs.
There is a Clojure mode package, but it is in NonGNU ELPA.

I think that language is important enough that, notwithstanding not
really being similar to Lisp, we ought to have a major mode to support it.
Would someone please work on that?

This could be done by getting copyright assignments for code in the
NonGNU ELPA package, or by writing new code to replace it, or by a
mixture of the two.



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

Philip Kaludercic <philipk@posteo.net> writes:

> There seems to be no objection against adding it, despite the name.  Can
> you confirm that this is the latest version of the patch you would like
> to have applies to nongnu.git:
>
> From baf7c0d081cbda5760c8f7523780316fcb041714 Mon Sep 17 00:00:00 2001
> From: dannyfreeman <danny@dfreeman.email>
> Date: Sat, 12 Aug 2023 14:31:44 -0400
> Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package
>
> ---
>  elpa-packages | 4 ++++
>  1 file changed, 4 insertions(+)
>
> diff --git a/elpa-packages b/elpa-packages
> index 9dac0cd..6ea2057 100644
> --- a/elpa-packages
> +++ b/elpa-packages
> @@ -87,6 +87,10 @@
>    :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
>    :news "CHANGELOG.md")
>
> + (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
> +  :readme "README.md"
> +  :news "CHANGELOG.md")
> +
>   (coffee-mode		:url "https://github.com/defunkt/coffee-mode")
>
>   (corfu-terminal	:url "https://codeberg.org/akib/emacs-corfu-terminal")

Yes, I can confirm this is the patch. The latest version also includes
the .elpaignore file you mentioned so everything should be set.

Thank you,
--
Danny Freeman

Stefan Kangas <stefankangas@gmail.com> writes:

>> Well down the road when clojure-ts-mode has stabilized I will make sure
>> we will revisit the idea of moving it to the core. Until then, I hope
>> y'all see the value of making it available in NonGNU ELPA.
>
> This seems pragmatic given the current resistance to add the package
> to Emacs among some of its developers.  It will, of course, be
> positive for both Emacs and the Clojure community if we can revisit
> this in the future, so it is good that you intend to do that later.

I do intend to. Right now the package is still a long way from being
anywhere near done, which is why I've kept is on major version 0. Once
it has stabilized and can be considered mostly "complete" I will bring
this up again.

The development model Emacs follows is much different than some
developers are accustom to in their day jobs (myself included), and is
not what other contributors to the clojure emacs packages prefer. That
along with the copyright assignment process that some have fundamental
disagreements with makes this a difficult thing to push for. I am not
the only person involved in the clojure emacs projects, indeed I am a
relatively new contributor. Like I said, I will try, but I cannot
guarantee results.

> Thanks for working on this package and for pushing for its inclusion
> on NonGNU ELPA.

Happy to be the one to do it.

Thank you,
--
Danny Freeman

Danny Freeman <danny@dfreeman.email> writes:

> > I'm at a loss how people who develop an Emacs package can object to
> > adding their package to Emacs.  But so be it.

Very much so.  This is not an isolated example, unfortunately.  We are
faced with a seemingly significant pedagogical challenge to better
explain the benefits of including key features in Emacs itself.

The upside here is that people are hacking on Emacs packages, which
can only be a good thing.

> Well down the road when clojure-ts-mode has stabilized I will make sure
> we will revisit the idea of moving it to the core. Until then, I hope
> y'all see the value of making it available in NonGNU ELPA.

This seems pragmatic given the current resistance to add the package
to Emacs among some of its developers.  It will, of course, be
positive for both Emacs and the Clojure community if we can revisit
this in the future, so it is good that you intend to do that later.

Thanks for working on this package and for pushing for its inclusion
on NonGNU ELPA.

Danny Freeman <danny@dfreeman.email> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> There seems to be no objection against adding it, despite the name.  Can
>> you confirm that this is the latest version of the patch you would like
>> to have applies to nongnu.git:
>>
>> From baf7c0d081cbda5760c8f7523780316fcb041714 Mon Sep 17 00:00:00 2001
>> From: dannyfreeman <danny@dfreeman.email>
>> Date: Sat, 12 Aug 2023 14:31:44 -0400
>> Subject: [PATCH] * elpa-packages (clojure-ts-mode): new package
>>
>> ---
>>  elpa-packages | 4 ++++
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/elpa-packages b/elpa-packages
>> index 9dac0cd..6ea2057 100644
>> --- a/elpa-packages
>> +++ b/elpa-packages
>> @@ -87,6 +87,10 @@
>>    :ignored-files ("clojure-mode-extra-font-locking.el" "doc" "test" "test.clj")
>>    :news "CHANGELOG.md")
>>
>> + (clojure-ts-mode   :url "https://github.com/clojure-emacs/clojure-ts-mode"
>> +  :readme "README.md"
>> +  :news "CHANGELOG.md")
>> +
>>   (coffee-mode		:url "https://github.com/defunkt/coffee-mode")
>>
>>   (corfu-terminal	:url "https://codeberg.org/akib/emacs-corfu-terminal")
>
> Yes, I can confirm this is the patch. The latest version also includes
> the .elpaignore file you mentioned so everything should be set.
>
> Thank you,

Done :)

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
> It appears that there is no clojure-mode command in core Emacs.
> There is a Clojure mode package, but it is in NonGNU ELPA.
>
> I think that language is important enough that, notwithstanding not
> really being similar to Lisp, we ought to have a major mode to support it.
> Would someone please work on that?

I had brought this up in the recent clojure-ts-mode thread, that I
assume you are referring to.  Sadly, I have no experience with the
language, but one idea might be to extend lisp-data-mode by whatever the
syntactic differences are, to at least have some basic visual support in
terms of syntax highlighting and the like.

> This could be done by getting copyright assignments for code in the
> NonGNU ELPA package, or by writing new code to replace it, or by a
> mixture of the two.

The issue here is, that the clojure-mode developers are mostly averse to
assigning their code to the FSF.

> From: Danny Freeman <danny@dfreeman.email>
> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> Date: Thu, 24 Aug 2023 21:58:48 -0400
>
> The development model Emacs follows is much different than some
> developers are accustom to in their day jobs (myself included), and is
> not what other contributors to the clojure emacs packages prefer.

IME, the development model of Emacs is an important reason why Emacs
is still alive and kicking almost 40 years since it was first
developed.  And important major modes in Emacs are alive and kicking
with it.  So inclusion in Emacs and the pains of adjusting to a
different development model are justified if one wants the major mode
to remain alive for many years to come.  Something to think about, I
guess.

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

  > > This could be done by getting copyright assignments for code in the
  > > NonGNU ELPA package, or by writing new code to replace it, or by a
  > > mixture of the two.

  > The issue here is, that the clojure-mode developers are mostly averse to
  > assigning their code to the FSF.

What those people think should not be a crucial issue, because writing
a major mode to handle a language is not a big job.  We have dozens of
them in Emacs.  Lots of us here would be able to replace it.

The trick is to start thinking of it as a module to be written,
rather than as a need for something that we can't have;

  > , but one idea might be to extend lisp-data-mode by whatever the
  > syntactic differences are, to at least have some basic visual support in
  > terms of syntax highlighting and the like.

It is fine to copy some code from an existing mode.  I just advise
people not to try to arrange to share the code between the two modes.
I expect that the sharing would make for more complexity than it is
worth.


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

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > > This could be done by getting copyright assignments for code in the
>   > > NonGNU ELPA package, or by writing new code to replace it, or by a
>   > > mixture of the two.
>
>   > The issue here is, that the clojure-mode developers are mostly averse to
>   > assigning their code to the FSF.
>
> What those people think should not be a crucial issue, because writing
> a major mode to handle a language is not a big job.  We have dozens of
> them in Emacs.  Lots of us here would be able to replace it.

IMO it really depends on the level of integration one is aiming for.  As
mentioned in my last message, if it is just basic syntax support, then I
guess anyone with a language specification could do it.  But since
Closure is some sort of a mock-lisp, a user might be interested in
having more complex features such as REPL integration and perhaps some
kind of proper indentation for macros (assuming Clojure has macros).

> The trick is to start thinking of it as a module to be written,
> rather than as a need for something that we can't have;

I still question the need for replicating the labour, if the only
advantage the user has is that they don't have to M-x package-install
the existing major mode from NonGNU ELPA.  Especially when given
functionality like what the "gnu-elpa" package provides, in being able
to suggest the right packages for a file type (which is currently
underutilised and IMO should be moved into package.el itself).

>   > , but one idea might be to extend lisp-data-mode by whatever the
>   > syntactic differences are, to at least have some basic visual support in
>   > terms of syntax highlighting and the like.
>
> It is fine to copy some code from an existing mode.  I just advise
> people not to try to arrange to share the code between the two modes.
> I expect that the sharing would make for more complexity than it is
> worth.

--
Philip Kaludercic

Philip Kaludercic <philipk@posteo.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ 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. ]]]
>>
>>   > > This could be done by getting copyright assignments for code in the
>>   > > NonGNU ELPA package, or by writing new code to replace it, or by a
>>   > > mixture of the two.
>>
>>   > The issue here is, that the clojure-mode developers are mostly averse to
>>   > assigning their code to the FSF.
>>
>> What those people think should not be a crucial issue, because writing
>> a major mode to handle a language is not a big job.  We have dozens of
>> them in Emacs.  Lots of us here would be able to replace it.
>
> IMO it really depends on the level of integration one is aiming for.  As
> mentioned in my last message, if it is just basic syntax support, then I
> guess anyone with a language specification could do it.  But since
> Closure is some sort of a mock-lisp, a user might be interested in
> having more complex features such as REPL integration and perhaps some
> kind of proper indentation for macros (assuming Clojure has macros).
>
>> The trick is to start thinking of it as a module to be written,
>> rather than as a need for something that we can't have;
>
> I still question the need for replicating the labour, if the only
> advantage the user has is that they don't have to M-x package-install
> the existing major mode from NonGNU ELPA.  Especially when given
> functionality like what the "gnu-elpa" package provides, in being able
> to suggest the right packages for a file type (which is currently
> underutilised and IMO should be moved into package.el itself).

I should say to anyone considering writing yet another Clojure major
mode, who is asking for this? I do not see any Clojure developers
anywhere in this thread, or anywhere else, expressing a desire for
another clojure major mode. It would be largely a wasted effort.

Clojure-mode was created 15 years ago as a derivative of lisp-mode. It
pairs with a SLIME-like package called CIDER that has been in
development for almost as long. Any serious Clojure developer will
eventually learn to install these battle tested packages over anything
that comes out of this conversation. I believe adding a third Clojure
mode would just confuse users and be a wasted effort.

To further re-iterate how much of a non-problem this is, the most recent
survey done of Clojure developers found that 42% use Emacs as their
primary development environment. If not being available out of the box
was such a big issue for users of clojure-mode, then that number would
not be so high.

--
Danny Freeman

Dmitry Gutov <dmitry@gutov.dev> writes:

> Perhaps the maintainers of Emacs should make more effort to increase the
> benefits of including packages in Emacs,

What would you propose?

> as well as make it more
> frictionless and user-friendly in the sense that many younger
> programmers are accustomed to.

Fully agreed.  We are still looking for volunteers to work on getting
us onto a forge, for example.  Last time we checked, Sourcehut was
unfortunately not up to scratch: https://todo.sr.ht/~emacs/emacs/1

Perhaps things have changed, though?  I guess it wouldn't hurt if
someone looked into it.

> Rather than just "better explaining" it.

We should be able to work on several things at the same time.

On 26/08/2023 05:05, Richard Stallman wrote:
>    > The issue here is, that the clojure-mode developers are mostly averse to
>    > assigning their code to the FSF.
>
> What those people think should not be a crucial issue, because writing
> a major mode to handle a language is not a big job.  We have dozens of
> them in Emacs.  Lots of us here would be able to replace it.

I would really not recommend increasing user confusion around which is
the recommended major mode, and which one is not.

That affects many third-party packages, as well as configuration
snippets floating around the web.

On 24/08/2023 23:21, Stefan Kangas wrote:
> Danny Freeman<danny@dfreeman.email>  writes:
>
>>> I'm at a loss how people who develop an Emacs package can object to
>>> adding their package to Emacs.  But so be it.
> Very much so.  This is not an isolated example, unfortunately.  We are
> faced with a seemingly significant pedagogical challenge to better
> explain the benefits of including key features in Emacs itself.

Perhaps the maintainers of Emacs should make more effort to increase the
benefits of including packages in Emacs, as well as make it more
frictionless and user-friendly in the sense that many younger
programmers are accustomed to.

Rather than just "better explaining" it.

On 26/08/23 15:48, Danny Freeman wrote:
> To further re-iterate how much of a non-problem this is, the most recent
> survey done of Clojure developers found that 42% use Emacs as their
> primary development environment. If not being available out of the box
> was such a big issue for users of clojure-mode, then that number would
> not be so high.

My 2c.

Personally I am glad that all the people behind clojure-mode and CIDER
decided to made their work available on NonGNU ELPA a while ago, just as
I am happy clojure-ts-mode is available there.

I have always thought that NonGNU ELPA was a way to cope with issues
such as this: people wanting to share their work (and considerable
amount of time) on Emacs with others but not willing for whatever reason
to go one step further and try GNU ELPA or even Emacs core.

Considering the popularity of clojure-mode (and CIDER) and with NonGNU
ELPA being readily available, why is it so important to invest time and
effort on re-creating a major mode? Put otherwise, should moving
packages on NonGNU ELPA be considered sort of a temporary stage in the
lifetime of a given package?

--
Manuel Uberti
https://manueluberti.eu

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Sat, 26 Aug 2023 21:52:31 +0300
>> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
>>  manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> On 25/08/2023 08:42, Eli Zaretskii wrote:
>> > IME, the development model of Emacs is an important reason why Emacs
>> > is still alive and kicking almost 40 years since it was first
>> > developed.  And important major modes in Emacs are alive and kicking
>> > with it.  So inclusion in Emacs and the pains of adjusting to a
>> > different development model are justified if one wants the major mode
>> > to remain alive for many years to come.  Something to think about, I
>> > guess.
>> 
>> Or the longevity stems from other reasons (e.g. good fundamental ideas, 
>> unique proposition, being part of the original GNU system, ...), and the 
>> development process is the reason the current user base is a fraction of 
>> even Vim's (not to mention popular commercial offerings).
>> 
>> Just an alternative POV to consider. In truth, could be a little of both.
>
> Mine wasn't a POV, it was an observation based on many years of
> watching the development and being part of it.

Correct me if I am wrong: This seems to be related to the fact that the
GitHub-model (thought it probably precedes it) of development has
motivated more and more individuals to maintain packages, instead of
organisations like GNU, Apache, etc.  Or at least I understand that if
there is a collective effort behind maintaining the components of a
system, contributors can come and go without a package being abandoned
-- this is especially true for Emacs due to the extensive
introspectability.  But it appears this reaches a limit, if a component
is too complex (CEDET was mentioned as one example, and if João were to
suddenly loose interest in contributing to Emacs, something similar
might happen to Eglot as well).

I only mention this, because I don't agree with the premise that this
boils down to "mailing-list" or "web-interface".  While it is true that
a lot of people are uncertain and afraid of sending a message to a
mailing list, this fear is unreasonable and worth dispelling.

I think there is a reasonable point to be made that the CA prevents
certain valuable contributions from entering Emacs/GNU ELPA.  IANAL, so
I don't know if a sign-off procedure would be a sufficient alternative?
But if I am a bit cynical, I cannot deny that having a CA-system can
also help filtering out a lot of noise and low-quality code (I'd claim
that the average quality of a ELPA package is higher than that of
packages on MELPA...).

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

  > Perhaps the maintainers of Emacs should make more effort to increase the
  > benefits of including packages in Emacs, as well as make it more
  > frictionless and user-friendly in the sense that many younger
  > programmers are accustomed to.

When it is stated so abstractly, the only response is, "All else being
equal, that would surely be an improvement."

If you state more precisely what you have in mind, we could start to
identify specific obstacles, problems and downsides.

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

[[[ 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 those people think should not be a crucial issue, because writing
  > > a major mode to handle a language is not a big job.  We have dozens of
  > > them in Emacs.  Lots of us here would be able to replace it.

  > I would really not recommend increasing user confusion around which is
  > the recommended major mode, and which one is not.

That argument is too vague to support any particular conclusion.

If we install a command called clojure-mode in the core Emacs, that
will in a sense be the preferred one.  If you type M-x clojure-mode in
Emacs, that is the one you'll get.

We could avoid confusion with the NonGNU ELPA package by renaming
that one.  Asking to load it using its new name would make it clear
that that's the package you want.

  > That affects many third-party packages, as well as configuration
  > snippets floating around the web.

Sorry, I don't follow you.  Would you please spell out what you mean?

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

On 25/08/2023 08:42, Eli Zaretskii wrote:
>> From: Danny Freeman<danny@dfreeman.email>
>> Cc: Eli Zaretskii<eliz@gnu.org>,philipk@posteo.net,emacs-devel@gnu.org,
>>   manuel.uberti@inventati.org
>> Date: Thu, 24 Aug 2023 21:58:48 -0400
>>
>> The development model Emacs follows is much different than some
>> developers are accustom to in their day jobs (myself included), and is
>> not what other contributors to the clojure emacs packages prefer.
> IME, the development model of Emacs is an important reason why Emacs
> is still alive and kicking almost 40 years since it was first
> developed.  And important major modes in Emacs are alive and kicking
> with it.  So inclusion in Emacs and the pains of adjusting to a
> different development model are justified if one wants the major mode
> to remain alive for many years to come.  Something to think about, I
> guess.

Or the longevity stems from other reasons (e.g. good fundamental ideas,
unique proposition, being part of the original GNU system, ...), and the
development process is the reason the current user base is a fraction of
even Vim's (not to mention popular commercial offerings).

Just an alternative POV to consider. In truth, could be a little of both.

> Date: Sat, 26 Aug 2023 21:52:31 +0300
> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 25/08/2023 08:42, Eli Zaretskii wrote:
> > IME, the development model of Emacs is an important reason why Emacs
> > is still alive and kicking almost 40 years since it was first
> > developed.  And important major modes in Emacs are alive and kicking
> > with it.  So inclusion in Emacs and the pains of adjusting to a
> > different development model are justified if one wants the major mode
> > to remain alive for many years to come.  Something to think about, I
> > guess.
>
> Or the longevity stems from other reasons (e.g. good fundamental ideas,
> unique proposition, being part of the original GNU system, ...), and the
> development process is the reason the current user base is a fraction of
> even Vim's (not to mention popular commercial offerings).
>
> Just an alternative POV to consider. In truth, could be a little of both.

Mine wasn't a POV, it was an observation based on many years of
watching the development and being part of it.

On 26/08/2023 22:05, Eli Zaretskii wrote:
>> Or the longevity stems from other reasons (e.g. good fundamental ideas,
>> unique proposition, being part of the original GNU system, ...), and the
>> development process is the reason the current user base is a fraction of
>> even Vim's (not to mention popular commercial offerings).
>>
>> Just an alternative POV to consider. In truth, could be a little of both.
> Mine wasn't a POV, it was an observation based on many years of
> watching the development and being part of it.

Are you talking about Emacs as a whole, or sub-packages inside it?

I meant the former, but as for the latter, CEDET is a good
counter-example in several respects.

> Date: Sat, 26 Aug 2023 22:09:47 +0300
> Cc: danny@dfreeman.email, stefankangas@gmail.com, philipk@posteo.net,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 26/08/2023 22:05, Eli Zaretskii wrote:
> >> Or the longevity stems from other reasons (e.g. good fundamental ideas,
> >> unique proposition, being part of the original GNU system, ...), and the
> >> development process is the reason the current user base is a fraction of
> >> even Vim's (not to mention popular commercial offerings).
> >>
> >> Just an alternative POV to consider. In truth, could be a little of both.
> > Mine wasn't a POV, it was an observation based on many years of
> > watching the development and being part of it.
>
> Are you talking about Emacs as a whole, or sub-packages inside it?

The former, of course.

On 26/08/2023 22:32, Eli Zaretskii wrote:
>> Date: Sat, 26 Aug 2023 22:09:47 +0300
>> Cc:danny@dfreeman.email,stefankangas@gmail.com,philipk@posteo.net,
>>   emacs-devel@gnu.org,manuel.uberti@inventati.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> On 26/08/2023 22:05, Eli Zaretskii wrote:
>>>> Or the longevity stems from other reasons (e.g. good fundamental ideas,
>>>> unique proposition, being part of the original GNU system, ...), and the
>>>> development process is the reason the current user base is a fraction of
>>>> even Vim's (not to mention popular commercial offerings).
>>>>
>>>> Just an alternative POV to consider. In truth, could be a little of both.
>>> Mine wasn't a POV, it was an observation based on many years of
>>> watching the development and being part of it.
>> Are you talking about Emacs as a whole, or sub-packages inside it?
> The former, of course.

Then I don't see what your baseline is.

I used Vim as an example (30 years old project, more popular these days,
in part thanks to NeoVim).

On 26/08/2023 17:31, Stefan Kangas wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> Perhaps the maintainers of Emacs should make more effort to increase the
>> benefits of including packages in Emacs,
>
> What would you propose?
>
>> as well as make it more
>> frictionless and user-friendly in the sense that many younger
>> programmers are accustomed to.
>
> Fully agreed.  We are still looking for volunteers to work on getting
> us onto a forge, for example.  Last time we checked, Sourcehut was
> unfortunately not up to scratch: https://todo.sr.ht/~emacs/emacs/1

If it's not, it's not. *shrug*

But if no existing solution agrees with us, that seems to say something
about us too, right?

> Perhaps things have changed, though?  I guess it wouldn't hurt if
> someone looked into it.

I'm not sure SourceHut is much of an improvement in the way of
development experience, but at this point any change would likely be a
positive.

I have to note, though, that their bug tracking solution is either
non-existent or entirely merged into "mailing lists". Which, no matter
how well we explain them (and we should try, time permitting) will
remain alien to a significant fraction of our users.

These are the two main areas in Emacs I would try to address, if I had
more time and authority:

- Talking to our users (better, more familiar access to bug tracking
first and foremost, but anything that makes mailing lists friendlier
would also be a win; GitHub has "Discussions" which are pretty nice, but
that seems entirely out of reach).

- The initial experience for new users (standard bindings; reworked
tutorial; reworking of the menu; first install wizards with suggested
settings presets; etc). I don't have anything new to add here. It's a
difficult, very poorly defined endeavor without a lot of consensus, so
even little progress in that area is great.

But the first point in particular (easier user communication) would also
be important in attracting more third-party developers to contribute
code to Emacs. Not that it's necessary for all code: I think ELPA is
perfectly fine for most.

Everything else is secondary.

>> Rather than just "better explaining" it.
>
> We should be able to work on several things at the same time.

Sure. On the subject of explaining things, I also hope we'll be able to
reach the point where the leadership doesn't act dismissive toward the
broader development community and we can finally agree that "What those
people think" definitely is "a crucial issue" in many situations.

On 26/08/2023 23:14, Philip Kaludercic wrote:
> I only mention this, because I don't agree with the premise that this
> boils down to "mailing-list" or "web-interface".  While it is true that
> a lot of people are uncertain and afraid of sending a message to a
> mailing list, this fear is unreasonable and worth dispelling.

It's not so much a matter of being afraid. We're not squirrels. Using
Debbugs is an exercise in frustration because a random user won't know
how to respond to an existing issue (finding them is clunky, but
doable), how to respond to a particular comment without having been
subscribed to the mailing list previously (there's no way to do that,
and it's a common feature in most bug trackers and discussion
platforms), how to properly respond to an email from a bug tracker that
does arrive in your inbox, how to avoid dropping people from
conversations, how to avoid being dropped themselves at some point. And
so on.

Anybody who doesn't have enough patience to google how to do the most
basic things, we just don't see.

Another thing we're missing, is an easy-to-access list of most recent
conversations and bug reports. Which for many projects partially serves
as an invitation to join in, too (as long as it's easy to do from there).

> I think there is a reasonable point to be made that the CA prevents
> certain valuable contributions from entering Emacs/GNU ELPA.  IANAL, so
> I don't know if a sign-off procedure would be a sufficient alternative?
> But if I am a bit cynical, I cannot deny that having a CA-system can
> also help filtering out a lot of noise and low-quality code (I'd claim
> that the average quality of a ELPA package is higher than that of
> packages on MELPA...).

Virtually any barrier would increase the average quality of the code. If
we required everybody to do fifty squats, film that, and attach together
with the first patch submission, that would also increase the average
quality, filtering out the less motivated.

I'm not sure the cost-benefit ratio is good, though.

On 27/08/2023 00:27, Dmitry Gutov wrote:
> I have to note, though, that their bug tracking solution is either
> non-existent or ...

Ah no, I see it, just behind your link to todo.sr.ht. And it *would* be
an improvement.

Too bad it's not linked to from the "project page" (e.g. from
https://git.sr.ht/~emacs/emacs in this example).

On 27/08/2023 04:35, 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 those people think should not be a crucial issue, because writing
>    > > a major mode to handle a language is not a big job.  We have dozens of
>    > > them in Emacs.  Lots of us here would be able to replace it.
>
>    > I would really not recommend increasing user confusion around which is
>    > the recommended major mode, and which one is not.
>
> That argument is too vague to support any particular conclusion.
>
> If we install a command called clojure-mode in the core Emacs, that
> will in a sense be the preferred one.  If you type M-x clojure-mode in
> Emacs, that is the one you'll get.
>
> We could avoid confusion with the NonGNU ELPA package by renaming
> that one.  Asking to load it using its new name would make it clear
> that that's the package you want.

NonGNU ELPA now has the package called clojure-ts-mode, it doesn't
conflict. But it's specifically for use with tree-sitter grammar.

>    > That affects many third-party packages, as well as configuration
>    > snippets floating around the web.
>
> Sorry, I don't follow you.  Would you please spell out what you mean?

clojure-mode is an existing package with thousands (tens of thousands?
millions?) users and certain existing functionality. Other (also
third-party) packages rely on it for various functionality. It's not a
bare-bones major mode with basic functionality only.

If we simply overtook the name but didn't reimplement it 1-to-1, that
would break a lot of user configurations, many existing recipes "how to
develop in Clojure with Emacs" posted around the web, not to mention
that would be an insult toward the developers of the existing package.

There wouldn't be too much point in that either, because very few only
use the major mode for development without additional niceties like CIDER.

> Date: Sat, 26 Aug 2023 22:48:42 +0300
> Cc: danny@dfreeman.email, stefankangas@gmail.com, philipk@posteo.net,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 26/08/2023 22:32, Eli Zaretskii wrote:
> >> Date: Sat, 26 Aug 2023 22:09:47 +0300
> >> Cc:danny@dfreeman.email,stefankangas@gmail.com,philipk@posteo.net,
> >>   emacs-devel@gnu.org,manuel.uberti@inventati.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> On 26/08/2023 22:05, Eli Zaretskii wrote:
> >>>> Or the longevity stems from other reasons (e.g. good fundamental ideas,
> >>>> unique proposition, being part of the original GNU system, ...), and the
> >>>> development process is the reason the current user base is a fraction of
> >>>> even Vim's (not to mention popular commercial offerings).
> >>>>
> >>>> Just an alternative POV to consider. In truth, could be a little of both.
> >>> Mine wasn't a POV, it was an observation based on many years of
> >>> watching the development and being part of it.
> >> Are you talking about Emacs as a whole, or sub-packages inside it?
> > The former, of course.
>
> Then I don't see what your baseline is.

The state of Emacs, its features (both editing and display), its
continued development, and the quality of its code and documentation.

> I used Vim as an example (30 years old project, more popular these days,
> in part thanks to NeoVim).

Does Vim or NeoVim support bidirectional editing?

--00000000000006cd3d0603e1a141
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 26, 2023, 21:15 Philip Kaludercic <philipk@posteo.net> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Date: Sat, 26 Aug 2023 21:52:31 +0300
> >> Cc: stefankangas@gmail.com, philipk@posteo.net, emacs-devel@gnu.org,
> >>  manuel.uberti@inventati.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >> On 25/08/2023 08:42, Eli Zaretskii wrote:
> >> > IME, the development model of Emacs is an important reason why Emacs
> >> > is still alive and kicking almost 40 years since it was first
> >> > developed.  And important major modes in Emacs are alive and kicking
> >> > with it.  So inclusion in Emacs and the pains of adjusting to a
> >> > different development model are justified if one wants the major mode
> >> > to remain alive for many years to come.  Something to think about, I
> >> > guess.
> >>
> >> Or the longevity stems from other reasons (e.g. good fundamental ideas,
> >> unique proposition, being part of the original GNU system, ...), and
> the
> >> development process is the reason the current user base is a fraction
> of
> >> even Vim's (not to mention popular commercial offerings).
> >>
> >> Just an alternative POV to consider. In truth, could be a little of
> both.
> >
> > Mine wasn't a POV, it was an observation based on many years of
> > watching the development and being part of it.
>
> Correct me if I am wrong: This seems to be related to the fact that the
> GitHub-model (thought it probably precedes it) of development has
> motivated more and more individuals to maintain packages, instead of
> organisations like GNU, Apache, etc.  Or at least I understand that if
> there is a collective effort behind maintaining the components of a
> system, contributors can come and go without a package being abandoned
> -- this is especially true for Emacs due to the extensive
> introspectability.  But it appears this reaches a limit, if a component
> is too complex (CEDET was mentioned as one example, and if João were to
> suddenly loose interest in contributing to Emacs, something similar
> might happen to Eglot as well).
>

I don't know if you've ever compared the source of both packages,
but in terms of complexity Eglot pales in comparison to CEDET
This is by design, of course.  Also, many moons ago, circa Emacs 22,
I actually tried to get CEDET working for a full C++ dev environment
in a company setting.  I went through a lot of its code doing changes
(never published).  I was a different programmer but I think I
would still find it just as impenetrable today.

Things are much better -- radically better -- these days.  Not
thanks to Eglot but thanks primarily to LSP and the continued
quality work on half-decent protocols for connecting it to our
UI. Things like like xref, project, eldoc, flymake, company,
etc.

I'm a bit perplexed why you picked me as the star of "what if
he were to disappear?" but I guess I'm as good a candidate as
Michael, Lars, Dmitry or so many others.

So let me then offer my 2c on what is fast becoming the customary
yearly round of "whither Emacs?".  Whenever GitHub looks to be the
essential catalyst of vibrant and effective software, look again.
The reason why so many projects looks like be they're going a million
km an hour is because they are, and they're accumulating loads of
bloat and technical debt in under-reviewed design decisions just
because it is so easy to press a green button to merge something.
You may as well have ChatGPT at the helm.

When they aren't, it's because a small group of devs is actively
curating and protecting the project, or because GitHub in itself
doesn't bring about any game-changing dynamic, such as happened with
SLIME which -- much like CL itself -- was half-moribund ca 2012 when
I helped move it to GitHub (with similar illusions to many others about
its redemptive power) and is half-moribund today (which is another word
for "reasonably stable" in the end).

So the lure of the "GitHub-model" is deceptive. More likely some devs of
some successful projects there are just sticking to it because they happen
to already know it very well and resist changing.  Just like many devs
in "our" camp.  More likely those "GitHub model" devs just don't dig
the vibe around these parts that much -- perfectly legitimate -- but are
a bit afraid to say so, so they say it's the CA requirement and the
patches model.

After all, this mailing list, for all the talk of obsolete mails etc,
is very heavily participated and even more heavily read.  Just the fact
of having one's work scrutinized in such a big forum is not to everyone's
liking.  And that's perfectly legitimate, too.  Developing a package
outside Emacs is a liberating experience by comparison.  Inside, there
is a completely new set of concerns, completely independent of the forge
you use.  The format of manuals, coding style, commands you can
and cannot add, even the upgrade options you offer to your user base
are affected.   As I've recently learned, moving a package from
the outside to the inside is a bit like getting married: you better
be prepared to  give some things up and fight actively for others.
You have to love Emacs very much to make it work ;-)

In my personal case I find no significant difference in working with
either model.  I find certain GitHub discussions and issue threads
just as pleasant or toxic as the things I find here.  I find email
reviews of patches no more complicated than those sophisticated
boxes.  Trivial patches to typos and stuff are indeed a little
harder to apply here compared with the the big green button.  But
then trivial patches aren't the things moving a project
forward anyway.  I could switch to SourceHut, of course, or anything
-- including GitHub.  It won't make that big of a difference I think.

João

>

--00000000000006cd3d0603e1a141
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir="ltr"><div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 26, 2023, 21:15 Philip Kaludercic <<a href="mailto:philipk@posteo.net" rel="noreferrer noreferrer" target="_blank">philipk@posteo.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Eli Zaretskii <<a href="mailto:eliz@gnu.org" rel="noreferrer noreferrer noreferrer" target="_blank">eliz@gnu.org</a>> writes:<br>
<br>
>> Date: Sat, 26 Aug 2023 21:52:31 +0300<br>
>> Cc: <a href="mailto:stefankangas@gmail.com" rel="noreferrer noreferrer noreferrer" target="_blank">stefankangas@gmail.com</a>, <a href="mailto:philipk@posteo.net" rel="noreferrer noreferrer noreferrer" target="_blank">philipk@posteo.net</a>, <a href="mailto:emacs-devel@gnu.org" rel="noreferrer noreferrer noreferrer" target="_blank">emacs-devel@gnu.org</a>,<br>
>>  <a href="mailto:manuel.uberti@inventati.org" rel="noreferrer noreferrer noreferrer" target="_blank">manuel.uberti@inventati.org</a><br>
>> From: Dmitry Gutov <<a href="mailto:dmitry@gutov.dev" rel="noreferrer noreferrer noreferrer" target="_blank">dmitry@gutov.dev</a>><br>
>> <br>
>> On 25/08/2023 08:42, Eli Zaretskii wrote:<br>
>> > IME, the development model of Emacs is an important reason why Emacs<br>
>> > is still alive and kicking almost 40 years since it was first<br>
>> > developed.  And important major modes in Emacs are alive and kicking<br>
>> > with it.  So inclusion in Emacs and the pains of adjusting to a<br>
>> > different development model are justified if one wants the major mode<br>
>> > to remain alive for many years to come.  Something to think about, I<br>
>> > guess.<br>
>> <br>
>> Or the longevity stems from other reasons (e.g. good fundamental ideas, <br>
>> unique proposition, being part of the original GNU system, ...), and the <br>
>> development process is the reason the current user base is a fraction of <br>
>> even Vim's (not to mention popular commercial offerings).<br>
>> <br>
>> Just an alternative POV to consider. In truth, could be a little of both.<br>
><br>
> Mine wasn't a POV, it was an observation based on many years of<br>
> watching the development and being part of it.<br>
<br>
Correct me if I am wrong: This seems to be related to the fact that the<br>
GitHub-model (thought it probably precedes it) of development has<br>
motivated more and more individuals to maintain packages, instead of<br>
organisations like GNU, Apache, etc.  Or at least I understand that if<br>
there is a collective effort behind maintaining the components of a<br>
system, contributors can come and go without a package being abandoned<br>
-- this is especially true for Emacs due to the extensive<br>
introspectability.  But it appears this reaches a limit, if a component<br>
is too complex (CEDET was mentioned as one example, and if João were to<br>
suddenly loose interest in contributing to Emacs, something similar<br>
might happen to Eglot as well).<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I don't know if you've ever compared the source of both packages, </div><div dir="auto">but in terms of complexity Eglot pales in comparison to CEDET </div><div dir="auto">This is by design, of course.  Also, many moons ago, circa Emacs 22, </div><div dir="auto">I actually tried to get CEDET working for a full C++ dev environment </div><div dir="auto">in a company setting.  I went through a lot of its code doing changes</div><div dir="auto">(never published).  I was a different programmer but I think I </div><div dir="auto">would still find it just as impenetrable today.</div><div dir="auto"><br></div><div dir="auto">Things are much better -- radically better -- these days.  Not </div><div dir="auto">thanks to Eglot but thanks primarily to LSP and the continued</div><div dir="auto">quality work on half-decent protocols for connecting it to our</div><div dir="auto">UI. Things like like xref, project, eldoc, flymake, company, </div><div dir="auto">etc.</div><div dir="auto"><br></div><div dir="auto">I'm a bit perplexed why you picked me as the star of "what if </div><div dir="auto">he were to disappear?" but I guess I'm as good a candidate as</div><div dir="auto">Michael, Lars, Dmitry or so many others.</div><div dir="auto"><br></div><div dir="auto">So let me then offer my 2c on what is fast becoming the customary </div><div dir="auto">yearly round of "whither Emacs?".  Whenever GitHub looks to be the</div><div dir="auto">essential catalyst of vibrant and effective software, look again. </div><div dir="auto">The reason why so many projects looks like be they're going a million</div><div dir="auto">km an hour is because they are, and they're accumulating loads of </div><div dir="auto">bloat and technical debt in under-reviewed design decisions just </div><div dir="auto">because it is so easy to press a green button to merge something.  </div><div dir="auto">You may as well have ChatGPT at the helm.</div><div dir="auto"><br></div><div dir="auto">When they aren't, it's because a small group of devs is actively </div><div dir="auto">curating and protecting the project, or because GitHub in itself </div><div dir="auto">doesn't bring about any game-changing dynamic, such as happened with </div><div dir="auto">SLIME which -- much like CL itself -- was half-moribund ca 2012 when </div><div dir="auto">I helped move it to GitHub (with similar illusions to many others about </div><div dir="auto">its redemptive power) and is half-moribund today (which is another word </div><div dir="auto">for "reasonably stable" in the end).</div><div dir="auto"><br></div><div dir="auto">So the lure of the "GitHub-model" is deceptive. More likely some devs of </div><div dir="auto">some successful projects there are just sticking to it because they happen </div><div dir="auto">to already know it very well and resist changing.  Just like many devs </div><div dir="auto">in "our" camp.  More likely those "GitHub model" devs just don't dig </div><div dir="auto">the vibe around these parts that much -- perfectly legitimate -- but are </div><div dir="auto">a bit afraid to say so, so they say it's the CA requirement and the </div><div dir="auto">patches model.<br></div><div dir="auto"><br></div><div dir="auto">After all, this mailing list, for all the talk of obsolete mails etc, </div><div dir="auto">is very heavily participated and even more heavily read.  Just the fact</div><div dir="auto">of having one's work scrutinized in such a big forum is not to everyone's </div><div dir="auto">liking.  And that's perfectly legitimate, too.  Developing a package</div><div>outside Emacs is a liberating experience by comparison.  Inside, there</div><div>is a completely new set of concerns, completely independent of the forge </div><div>you use.  The format of manuals, coding style, commands you can </div><div>and cannot add, even the upgrade options you offer to your user base</div><div>are affected.   As I've recently learned, moving a package from </div><div>the outside to the inside is a bit like getting married: you better </div><div>be prepared to  give some things up and fight actively for others.  </div><div>You have to love Emacs very much to make it work ;-)<br></div><div><br></div><div dir="auto">In my personal case I find no significant difference in working with </div><div dir="auto">either model.  I find certain GitHub discussions and issue threads</div><div>just as pleasant or toxic as the things I find here.  I find email</div><div>reviews of patches no more complicated than those sophisticated</div><div>boxes.  Trivial patches to typos and stuff are indeed a little </div><div>harder to apply here compared with the the big green button.  But </div><div>then trivial patches aren't the things moving a project </div><div>forward anyway.  I could switch to SourceHut, of course, or anything </div><div>-- including GitHub.  It won't make that big of a difference I think.</div><div><br></div><div>João</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>
</div>

--00000000000006cd3d0603e1a141--

> Date: Sun, 27 Aug 2023 00:41:35 +0300
> Cc: danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
>
> On 26/08/2023 23:14, Philip Kaludercic wrote:
> > I only mention this, because I don't agree with the premise that this
> > boils down to "mailing-list" or "web-interface".  While it is true that
> > a lot of people are uncertain and afraid of sending a message to a
> > mailing list, this fear is unreasonable and worth dispelling.
>
> It's not so much a matter of being afraid. We're not squirrels. Using
> Debbugs is an exercise in frustration because a random user won't know
> how to respond to an existing issue (finding them is clunky, but
> doable), how to respond to a particular comment without having been
> subscribed to the mailing list previously (there's no way to do that,
> and it's a common feature in most bug trackers and discussion
> platforms), how to properly respond to an email from a bug tracker that
> does arrive in your inbox, how to avoid dropping people from
> conversations, how to avoid being dropped themselves at some point. And
> so on.
>
> Anybody who doesn't have enough patience to google how to do the most
> basic things, we just don't see.
>
> Another thing we're missing, is an easy-to-access list of most recent
> conversations and bug reports. Which for many projects partially serves
> as an invitation to join in, too (as long as it's easy to do from there).
>
> > I think there is a reasonable point to be made that the CA prevents
> > certain valuable contributions from entering Emacs/GNU ELPA.  IANAL, so
> > I don't know if a sign-off procedure would be a sufficient alternative?
> > But if I am a bit cynical, I cannot deny that having a CA-system can
> > also help filtering out a lot of noise and low-quality code (I'd claim
> > that the average quality of a ELPA package is higher than that of
> > packages on MELPA...).
>
> Virtually any barrier would increase the average quality of the code. If
> we required everybody to do fifty squats, film that, and attach together
> with the first patch submission, that would also increase the average
> quality, filtering out the less motivated.
>
> I'm not sure the cost-benefit ratio is good, though.

IMNSHO, the above is an extremely optimistic and naïve view of the
actual state of matters.  Significantly, it emphasizes the advantages
of the proposed changes/alternatives and consistently and completely
ignores the disadvantages (which are known and were described and
discussed many times).

But the important part is what was said many times in this and other
similar discussions: those who want these deep changes are invited to
step up and become Emacs (co)-maintainers, and then make the changes
and actually use them for Emacs development, instead of telling others
how to do their jobs.  It is at least unfair to expect us to do our
job well, and then tell us how to do it and what tools to use for it.
And that is even before we recall that those alternative tools are
either semi-broken or lack important features (or both) that the
existing "obsolete" tools offer us basically for zero cost.  And none
of the alternatives withstood the test of time and/or the magnitude of
the project.

> From: dick <dick.r.chiang@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Dmitry Gutov <dmitry@gutov.dev>,
>   danny@dfreeman.email,  stefankangas@gmail.com,  philipk@posteo.net,
>   emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Sun, 27 Aug 2023 00:47:01 -0400
>
> Also, few emacs users could tell you what bidi is, and even fewer
> care.

I suggest that you realign your views with the reality (to put it
mildly).

As a matter of fact, just a few days ago I was approached by a Neovim
user/developer who asked for my advice on adding bidi to NeoVim.  And
if you search the Internet with suitable keywords, you will see how
frequently the request to add this support to NeoVim comes up on their
forums.

Modern text editing and display are woefully incomplete without this
and other similar display-time capabilities.

> I cringe every time EZ hangs his hat on bidi given how hamfistedly
> it was shoehorned into the display code.

I did what I was able to do, when no one else intended to work on
that, let alone was working on it.  And I did it 15 years ago, when I
had only a very superficial and inaccurate ideas of how the Emacs 21
display engine works, nowhere near what I know today.  The Emacs
requirements for bidi reordering are unique, and AFAIK unlike those in
any other editor, due to how our display engine works.  The
algorithmic solution is also quite unique, and required me to struggle
with the language of UAX#9, because UAX#9 is written with a very
different implementation in mind.

But if someone wants to reimplement or redesign the bidi support in
Emacs, they are welcome and will have my full support.

> From: João Távora <joaotavora@gmail.com>
> Date: Sun, 27 Aug 2023 07:26:55 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dmitry@gutov.dev>,
>  Danny Freeman <danny@dfreeman.email>,
>  Stefan Kangas <stefankangas@gmail.com>, emacs-devel <emacs-devel@gnu.org>,
>  Manuel Uberti <manuel.uberti@inventati.org>
>
> So let me then offer my 2c on what is fast becoming the customary
> yearly round of "whither Emacs?". [...]

Beautifully written, João.  Cannot agree more.  Thank you for taking
the time to write this.

Eli Zaretskii <eliz@gnu.org> writes:

> Does Vim or NeoVim support bidirectional editing?

Or more succinctly: image display, multiple frames and terminals, and
variable width fonts?

To say nothing of other GUI features that only Emacs provides...

João Távora <joaotavora@gmail.com> writes:

> So the lure of the "GitHub-model" is deceptive. More likely some devs
> of some successful projects there are just sticking to it because they
> happen to already know it very well and resist changing.  Just like
> many devs in "our" camp.  More likely those "GitHub model" devs just
> don't dig the vibe around these parts that much -- perfectly
> legitimate -- but are a bit afraid to say so, so they say it's the CA
> requirement and the patches model.
>
> After all, this mailing list, for all the talk of obsolete mails etc,
> is very heavily participated and even more heavily read.  Just the
> fact of having one's work scrutinized in such a big forum is not to
> everyone's liking.  And that's perfectly legitimate, too.  Developing
> a package outside Emacs is a liberating experience by comparison.
> Inside, there is a completely new set of concerns, completely
> independent of the forge you use.  The format of manuals, coding
> style, commands you can and cannot add, even the upgrade options you
> offer to your user base are affected.  As I've recently learned,
> moving a package from the outside to the inside is a bit like getting
> married: you better be prepared to give some things up and fight
> actively for others.  You have to love Emacs very much to make it work
> ;-)
>
> In my personal case I find no significant difference in working with
> either model.  I find certain GitHub discussions and issue threads
> just as pleasant or toxic as the things I find here.  I find email
> reviews of patches no more complicated than those sophisticated boxes.
> Trivial patches to typos and stuff are indeed a little harder to apply
> here compared with the the big green button.  But then trivial patches
> aren't the things moving a project forward anyway.  I could switch to
> SourceHut, of course, or anything -- including GitHub.  It won't make
> that big of a difference I think.

Very well said, thanks.

Compounding all of this is the additional impediment imposed by GitHub's
demand that all users of their system register an account irrespective
of their intent, whether it be to merely report a bug or to create a new
repository.  This has undoubtedly played the role of a deterrent to the
detriment of users and developers alike.

Po Lu <luangruo@yahoo.com> writes:

> Compounding all of this is the additional impediment imposed by GitHub's
> demand that all users of their system register an account irrespective
> of their intent, whether it be to merely report a bug or to create a new
> repository.  This has undoubtedly played the role of a deterrent to the
> detriment of users and developers alike.

By the way:

João Távora <joaotavora@gmail.com> writes:

> I'm a bit perplexed why you picked me as the star of "what if he were
> to disappear?" but I guess I'm as good a candidate as Michael, Lars,
> Dmitry or so many others.

Lars is taking an unexplained and prolonged leave of absence, with no
catastrophic effect on Emacs.  I think that shines a positive light on
our present practices.