New Package for NonGNU-ELPA: clojure-ts-mode

New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

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.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-elpa-packages-clojure-ts-mode-new-package.patch --]
[-- Type: text/x-patch, Size: 829 bytes --]

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")
+  :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


[-- Attachment #3: Type: text/plain, Size: 30 bytes --]


Thank you,
-- 
Danny Freeman

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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,

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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


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


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0002-elpa-packages-clojure-ts-mode-new-package.patch --]
[-- Type: text/x-patch, Size: 795 bytes --]

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


[-- Attachment #3: Type: text/plain, Size: 19 bytes --]


-- 
Danny Freeman

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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,

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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

Clojure mode

[Richard Stallman]

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

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)

Re: Clojure mode

[Philip Kaludercic]

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.

Re: Clojure mode

[Richard Stallman]

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

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

Re: Clojure mode

[Philip Kaludercic]

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

Re: Clojure mode

[Danny Freeman]

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

Re: Clojure mode

[Manuel Uberti]

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

Re: Clojure mode

[Dmitry Gutov]

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.

Re: Clojure mode

[Richard Stallman]

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

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

Re: Clojure mode

[Dmitry Gutov]

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.

Re: Clojure mode

[Bozhidar Batsov]

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

Here's another discussion that kind of frustrates me. (I'm the primary maintainer of clojure-mode) We already have clojure-mode, we've had it for something like 15 years, I've taken the time to submit to NonGNU ELPA. Not to mention that https://github.com/clojure-emacs/ is a big organization with many maintainers, so there's little risk about the long-term maintenance of any of the packages there. What's the purpose of this discussion? What's the problem that needs to be solved?

There's so much tooling that currently depends on clojure-mode (and will eventually depend on clojure-ts-mode several years down the line) that creating some new mode just for the sake of doing it makes 0 sense. If someone wants to do it - be my guest. But conversations like this one are what's alienating people from Emacs's core.  

On Sun, Aug 27, 2023, at 4:42 AM, Dmitry Gutov wrote:
> 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.
> 
> 

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

Re: Clojure mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 21:55:23 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Danny Freeman" <danny@dfreeman.email>,
>  "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> Here's another discussion that kind of frustrates me. (I'm the primary maintainer of clojure-mode) We
> already have clojure-mode, we've had it for something like 15 years, I've taken the time to submit to
> NonGNU ELPA. Not to mention that https://github.com/clojure-emacs/ is a big organization with many
> maintainers, so there's little risk about the long-term maintenance of any of the packages there.
> What's the purpose of this discussion? What's the problem that needs to be solved?

It's very simple, really: Clojure is an important programming
language, and Emacs should have support for it OOTB.  That's the
problem we'd like to solve.

Re: Clojure mode

[Bozhidar Batsov]

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

Support for it is just one package-install command away, so I'd say Emacs supports it almost out of the box. Not to mention that for a language like Clojure you also need some REPL-interaction package to be able to evaluate code, so you won't get very far without an extra package like inf-clojure or CIDER. Re-implementing those would be a huge waste of time IMO and fracture an already tiny programming community. 

To me it makes little sense to have support for everything built-in, as this doesn't scale very well. You end up distributing with Emacs a ton of functionality few people are going to use. That's why I've always been fond of having a slim core and lots of packages that people can install on demand. The package already is in NonGNU ELPA, which is pretty good for most users I'd reckon.

On Sun, Aug 27, 2023, at 9:58 PM, Eli Zaretskii wrote:
> > Date: Sun, 27 Aug 2023 21:55:23 +0300
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: "Danny Freeman" <danny@dfreeman.email>,
> >  "Emacs Devel" <emacs-devel@gnu.org>,
> >  "Manuel Uberti" <manuel.uberti@inventati.org>
> > 
> > Here's another discussion that kind of frustrates me. (I'm the primary maintainer of clojure-mode) We
> > already have clojure-mode, we've had it for something like 15 years, I've taken the time to submit to
> > NonGNU ELPA. Not to mention that https://github.com/clojure-emacs/ is a big organization with many
> > maintainers, so there's little risk about the long-term maintenance of any of the packages there.
> > What's the purpose of this discussion? What's the problem that needs to be solved?
> 
> It's very simple, really: Clojure is an important programming
> language, and Emacs should have support for it OOTB.  That's the
> problem we'd like to solve.
> 
> 

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

Re: Clojure mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 22:08:57 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Dmitry Gutov" <dmitry@gutov.dev>, "Richard Stallman" <rms@gnu.org>,
>  "Danny Freeman" <danny@dfreeman.email>, "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> Support for it is just one package-install command away, so I'd say Emacs supports it almost out of
> the box. Not to mention that for a language like Clojure you also need some REPL-interaction
> package to be able to evaluate code, so you won't get very far without an extra package like
> inf-clojure or CIDER. Re-implementing those would be a huge waste of time IMO and fracture an
> already tiny programming community. 

Which is why we prefer to include these existing packages, not to
invent new ones.

> To me it makes little sense to have support for everything built-in, as this doesn't scale very well.

We agree about that.  We are talking about clojure-mode, not about
everything.  Not every package offered for ELPAs triggers such
discussions, far from that.  Only very few do.

Re: Clojure mode

[chad]

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

This is obviously an area where the shifting models of software in general
and emacs in particular have changed over time (by a rough count, non-Gnu
Elpa is roughly the 8th-10th "emacs lisp archive" I've personally used),
and there are clear experiments in play right now. As a practical matter,
how would people feel about a sort of autoload variation, included in emacs
(30) core, that points users at relevant packages in [non-]GNU Elpa, which
would be overridden by code included in an actual package? The idea is to
combine a thin pointer with a potential indirection point that allow users
(who had not already chosen) to choose between alternatives such as
clojure-mode and clojure-ts-mode.

Hope that helps,
~Chad

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

Re: Clojure mode

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Mon, 28 Aug 2023 12:35:02 -0400
> Cc: Bozhidar Batsov <bozhidar@batsov.dev>, dmitry@gutov.dev, rms@gnu.org, 
> 	danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> As a practical matter, how
> would people feel about a sort of autoload variation, included in emacs (30) core, that points users
> at relevant packages in [non-]GNU Elpa, which would be overridden by code included in an actual
> package? The idea is to combine a thin pointer with a potential indirection point that allow users (who
> had not already chosen) to choose between alternatives such as clojure-mode and clojure-ts-mode.

You will have to present a more detailed proposal, because up front I
don't see how will this work.  For example, "autoloading"
clojure-ts-mode from ELPA will need:

  . download the Lisp files
  . byte-compile the Lisp files
  . add the directory of Lisp files to load-path
  . download the clojure grammar library
  . build a shared library from the grammar library
  . install the shared library

IOW, you will need to do what package.el does, but in batch and behind
the user's back.  Plus, it will take some non-negligible time.  How is
such "autoloading" useful?

The current idea of including ELPA packages is to include them in the
release tarball, so that for the end-user it looks exactly like a core
package.  What advantages does your proposal have wrt this idea?

Re: Clojure mode

[chad]

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

On Mon, Aug 28, 2023 at 1:05 PM Eli Zaretskii <eliz@gnu.org> wrote:

> You will have to present a more detailed proposal, because up front I
> don't see how will this work.
>

Entirely fair; I was presenting a pretty rough sketch. Let me try to make
it more concrete.

What I had in mind was something akin to autoload that, rather than
providing _any_ clojure mode (in this specific example), instead provides
the user with a buffer conveying that Clojure support in emacs is
available, but is not currently bundled directly, and offers the user a
short description of each of the two packages clojure-mode and
clojure-ts-mode, along with buttons to install and activate each package.

Thus, if a new user started a freshly downloaded emacs, they would find
some guidance (rather than, for example, "[No match]" from M-x or
fundamental-mode from opening test.clj), and we could provide some short
info backed by the full package description in cases where there was no
current always-recommend. The message/guidance could be conceptually
similar to the disable-command machinery.

I had autoload in mind based on the idea that this guidance code would be
supplanted by an actually installed package (and, I think, ideally restored
if the package was later removed). In other words, I'm suggesting adding an
optional dispatching step for the paths most likely to invoke a
not-directly-supported-in-core language.

Perhaps *eventually* something similar could be done for suggesting say,
c-sharp-ts-mode and cc-mode for a fresh emacs and "C-x C-f test.cs". I
imagine that there are refinements that could be useful for someone who
wanted to try assembling a small-core emacs, but I'd be surprised if there
weren't important lessons to learn before that point.

I hope this description is clearer; please let me know if I missed or
forgot anything important.

~Chad

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

Re: Clojure mode

[Stefan Kangas]

chad <yandros@gmail.com> writes:

> What I had in mind was something akin to autoload that, rather than providing _any_ clojure mode (in this specific example), instead provides the user with a buffer conveying that Clojure support in emacs is available, but is not currently bundled directly, and offers the user a short description of each of the two packages clojure-mode and clojure-ts-mode, along with buttons to install and activate each package.

How would your idea compare to this?:

    https://elpa.gnu.org/packages/gnu-elpa.html

If the idea is similar, perhaps you could try to work your ideas into
that package.

Re: Clojure mode

[Stefan Monnier]

> How would your idea compare to this?:
>
>     https://elpa.gnu.org/packages/gnu-elpa.html
>
> If the idea is similar, perhaps you could try to work your ideas into
> that package.

FWIW, that package has some serious implementation issues:

If you do (autoload 'closure-mode ...) and arrange for that autoload to
prompt the user to install the package (which is how the `gnu-elpa`
works), it tends to cause problems in all kinds of circumstances.

The "easy" ones look like:
- When the users already said they're not interested.

The harder ones look like:
- When the caller already decided to use `clojure-mode` rather than
  something else because it's `fboundp`.
- When the function wasn't called at all, but instead someone just asked
  to see its doc (and it somehow triggered an autoload).
- When the function wasn't called at all, but instead the macroexpander
  decided to autoload the function just to see what it's about.
...
A grep of `autoload-do-load` will give you an idea of the breadth of
the problem.

Maybe we should go for a different implementation strategy.


        Stefan

Re: Clojure mode

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: chad <yandros@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Mon, 28 Aug 2023 23:21:50 -0400
> 
> Maybe we should go for a different implementation strategy.

I think if we want to offer such a feature, we need first to come up
with some friendly enough UI: when exactly to pop the suggestion, how
to allow users to decline, how to install and configure if they say
yes, etc.  Then there would be a need for some kind of DB with popular
features that are not built-in and that people may wish to want; the
challenge here is not to make the DB list too many features, otherwise
we will be popping suggestions every single second...

Re: Clojure mode

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: chad <yandros@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
>> Date: Mon, 28 Aug 2023 23:21:50 -0400
>> 
>> Maybe we should go for a different implementation strategy.
>
> I think if we want to offer such a feature, we need first to come up
> with some friendly enough UI: when exactly to pop the suggestion, how
> to allow users to decline, how to install and configure if they say
> yes, etc.  Then there would be a need for some kind of DB with popular
> features that are not built-in and that people may wish to want; the
> challenge here is not to make the DB list too many features, otherwise
> we will be popping suggestions every single second...

How about splitting this into two separate tasks?  E.g. when a more
specific mode is found, a message is displayed in the minibuffer.  This
can occur once a session or once for every file.  The message would
instruct the user to invoke the appropriate command (e.g. a custom
command or by using the future history for `package-install').

To make a concrete suggestion: The database would probably consist of
possible extensions to `auto-mode-alist', `magic-mode-alist' and
`interpreter-mode-alist'.

Re: Clojure mode

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> How about splitting this into two separate tasks?  E.g. when a more
> specific mode is found, a message is displayed in the minibuffer.

FWIW, my ideal scenario looks like this:

"You seem to have opened a Clojure file.  Would you like to install
clojure-mode (yes/no/help)?"

When the user types "yes RET", the package gets installed, loaded in
the running session, and enabled in the relevant buffer.

Re: Clojure mode

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> How about splitting this into two separate tasks?  E.g. when a more
>> specific mode is found, a message is displayed in the minibuffer.
>
> FWIW, my ideal scenario looks like this:
>
> "You seem to have opened a Clojure file.  Would you like to install
> clojure-mode (yes/no/help)?"
>
> When the user types "yes RET", the package gets installed, loaded in
> the running session, and enabled in the relevant buffer.

This seems invasive, especially if the database has false-positives for
a user.  If anything, I think this kind of behaviour sound be opt-in.
But you are right, package-install is not sufficient, enabling the right
mode for all the relevant buffer(s) seems like the right thing to do.

Re: Clojure mode

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> > FWIW, my ideal scenario looks like this:
> >
> > "You seem to have opened a Clojure file.  Would you like to install
> > clojure-mode (yes/no/help)?"
> >
> > When the user types "yes RET", the package gets installed, loaded in
> > the running session, and enabled in the relevant buffer.
>
> This seems invasive, especially if the database has false-positives for
> a user.

With false positives it would suck, of course.  On the other hand,
perhaps adding a "don't ask me again" would make it more tolerable.

> If anything, I think this kind of behaviour sound be opt-in.

One idea would be to make the less-invasive "message in minibuffer"
variant the default, and the more-invasive "in your face prompt"
variant opt-in.

Re: Clojure mode

[Philip Kaludercic]

Stefan Kangas <stefankangas@gmail.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> > FWIW, my ideal scenario looks like this:
>> >
>> > "You seem to have opened a Clojure file.  Would you like to install
>> > clojure-mode (yes/no/help)?"
>> >
>> > When the user types "yes RET", the package gets installed, loaded in
>> > the running session, and enabled in the relevant buffer.
>>
>> This seems invasive, especially if the database has false-positives for
>> a user.
>
> With false positives it would suck, of course.  On the other hand,
> perhaps adding a "don't ask me again" would make it more tolerable.
>
>> If anything, I think this kind of behaviour sound be opt-in.
>
> One idea would be to make the less-invasive "message in minibuffer"
> variant the default, and the more-invasive "in your face prompt"
> variant opt-in.

So we are thinking about a user-option like `package-autosuggest' that
would have the values

- always :: always prompt the user when a more specific package is
  available
- once (or t) :: ask the user once per session, when a more specific
  package is available
- message :: only print a message if a more specific package is
  available
- nil :: do not look for more specific packages at all

Re: Clojure mode

[Stefan Kangas]

Philip Kaludercic <philipk@posteo.net> writes:

> So we are thinking about a user-option like `package-autosuggest' that
> would have the values
>
> - always :: always prompt the user when a more specific package is
>   available
> - once (or t) :: ask the user once per session, when a more specific
>   package is available
> - message :: only print a message if a more specific package is
>   available
> - nil :: do not look for more specific packages at all

Makes sense to me.

Re: Clojure mode

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  stefankangas@gmail.com,
>   yandros@gmail.com,  bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Tue, 29 Aug 2023 20:13:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I think if we want to offer such a feature, we need first to come up
> > with some friendly enough UI: when exactly to pop the suggestion, how
> > to allow users to decline, how to install and configure if they say
> > yes, etc.  Then there would be a need for some kind of DB with popular
> > features that are not built-in and that people may wish to want; the
> > challenge here is not to make the DB list too many features, otherwise
> > we will be popping suggestions every single second...
> 
> How about splitting this into two separate tasks?  E.g. when a more
> specific mode is found, a message is displayed in the minibuffer.  This
> can occur once a session or once for every file.  The message would
> instruct the user to invoke the appropriate command (e.g. a custom
> command or by using the future history for `package-install').

Something like that, yes.  But maybe there are other ideas?

> To make a concrete suggestion: The database would probably consist of
> possible extensions to `auto-mode-alist', `magic-mode-alist' and
> `interpreter-mode-alist'.

That'd be the anchor, definitely, at least for major modes.  It could
be a single function that is called if no suitable entry is found in
any of these variables.

Re: Clojure mode

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  stefankangas@gmail.com,
>>   yandros@gmail.com,  bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
>> Date: Tue, 29 Aug 2023 20:13:43 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I think if we want to offer such a feature, we need first to come up
>> > with some friendly enough UI: when exactly to pop the suggestion, how
>> > to allow users to decline, how to install and configure if they say
>> > yes, etc.  Then there would be a need for some kind of DB with popular
>> > features that are not built-in and that people may wish to want; the
>> > challenge here is not to make the DB list too many features, otherwise
>> > we will be popping suggestions every single second...
>> 
>> How about splitting this into two separate tasks?  E.g. when a more
>> specific mode is found, a message is displayed in the minibuffer.  This
>> can occur once a session or once for every file.  The message would
>> instruct the user to invoke the appropriate command (e.g. a custom
>> command or by using the future history for `package-install').
>
> Something like that, yes.  But maybe there are other ideas?

Another idea might be to indicate that a package can be installed in the
mode-line.  If the user interacts with it, some the right package would
be installed, activated and enabled in the applicable buffers.

>> To make a concrete suggestion: The database would probably consist of
>> possible extensions to `auto-mode-alist', `magic-mode-alist' and
>> `interpreter-mode-alist'.
>
> That'd be the anchor, definitely, at least for major modes.  It could
> be a single function that is called if no suitable entry is found in
> any of these variables.

What could be a single function?

-- 
Philip Kaludercic

Re: Clojure mode

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: monnier@iro.umontreal.ca,  stefankangas@gmail.com,  yandros@gmail.com,
>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Wed, 30 Aug 2023 11:51:37 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> To make a concrete suggestion: The database would probably consist of
> >> possible extensions to `auto-mode-alist', `magic-mode-alist' and
> >> `interpreter-mode-alist'.
> >
> > That'd be the anchor, definitely, at least for major modes.  It could
> > be a single function that is called if no suitable entry is found in
> > any of these variables.
> 
> What could be a single function?

That function would look up some database and suggest a package if it
exists.

Re: Clojure mode

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: monnier@iro.umontreal.ca,  stefankangas@gmail.com,  yandros@gmail.com,
>>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
>> Date: Wed, 30 Aug 2023 11:51:37 +0000
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> To make a concrete suggestion: The database would probably consist of
>> >> possible extensions to `auto-mode-alist', `magic-mode-alist' and
>> >> `interpreter-mode-alist'.
>> >
>> > That'd be the anchor, definitely, at least for major modes.  It could
>> > be a single function that is called if no suitable entry is found in
>> > any of these variables.
>> 
>> What could be a single function?
>
> That function would look up some database and suggest a package if it
> exists.

Ah, yes that is true.

Are there any other examples, where we would want to have minor modes
for specific file types?  These sorts of entries would probably have to
be added manually.

I am glad to see that there is interest in this proposal.  I can try and
create an example of how this could work, and push it to a feature
branch for further review, some time soon.  As mentioned elsewhere, this
might or might not be related to updating the "archive-contents" format
and adding package.el to GNU ELPA, as mentioned in [0]

[0] https://mail.gnu.org/archive/html/emacs-devel/2023-08/msg00667.html

-- 
Philip Kaludercic

Re: Clojure mode

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: monnier@iro.umontreal.ca,  stefankangas@gmail.com,  yandros@gmail.com,
>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
> Date: Wed, 30 Aug 2023 12:25:20 +0000
> 
> Are there any other examples, where we would want to have minor modes
> for specific file types?  These sorts of entries would probably have to
> be added manually.

I don't know, maybe someone else has an idea.

> I am glad to see that there is interest in this proposal.  I can try and
> create an example of how this could work, and push it to a feature
> branch for further review, some time soon.

I think this could be useful, yes.

package-autosuggest

[Philip Kaludercic]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: monnier@iro.umontreal.ca,  stefankangas@gmail.com,  yandros@gmail.com,
>>   bozhidar@batsov.dev,  dmitry@gutov.dev,  rms@gnu.org,
>>   danny@dfreeman.email,  emacs-devel@gnu.org,  manuel.uberti@inventati.org
>> Date: Wed, 30 Aug 2023 12:25:20 +0000
>> 
>> Are there any other examples, where we would want to have minor modes
>> for specific file types?  These sorts of entries would probably have to
>> be added manually.
>
> I don't know, maybe someone else has an idea.
>
>> I am glad to see that there is interest in this proposal.  I can try and
>> create an example of how this could work, and push it to a feature
>> branch for further review, some time soon.
>
> I think this could be useful, yes.

Here is a quick and rough draft of how this feature could look like:


[-- Attachment #2: Type: text/plain, Size: 4933 bytes --]

diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
index e1172d69bf0..723900318c5 100644
--- a/lisp/emacs-lisp/package.el
+++ b/lisp/emacs-lisp/package.el
@@ -4534,6 +4534,116 @@ package-get-version
             (or (lm-header "package-version")
                 (lm-header "version")))))))))
 
+\f
+;;;; Autosuggest
+
+(defvar package-autosuggest-database
+  '((sml-mode auto-mode-alist "\\.sml\\'")
+    (lua-mode auto-mode-alist "\\.lua\\'" )
+    (ada-mode auto-mode-alist "\\.ada\\'")
+    ;; ...
+    ;;
+    ;; this is just for testing, in practice I think this data should
+    ;; be generated and bundled with Emacs, and would ideally be
+    ;; loaded in at compile-time.  When the "archive-contents" file
+    ;; format is updated, we can include more information in there
+    ;; that would be added to this database.
+    )
+  "Database of hints for packages to suggest installing.")
+
+(define-minor-mode package-autosuggest-mode
+  "Enable the automatic suggestion and installation of packages."
+  :init-value 'message :global t
+  (funcall (if package-autosuggest-mode #'add-hook #'remove-hook)
+           'after-change-major-mode-hook
+           #'package--autosuggest-after-change-mode))
+
+(defun package--suggestion-applies-p (pkg-sug)
+  "Check if a suggestion PKG-SUG is applicable to the current buffer."
+  (pcase pkg-sug
+    (`(,(pred package-installed-p) . _) nil)
+    ((or `(,_ auto-mode-alist ,ext _)
+         `(,_ auto-mode-alist ,ext))
+     (and (string-match-p ext (buffer-name)) t))
+    ((or `(,_ magic-mode-alist ,mag _)
+         `(,_ magic-mode-alist ,mag))
+     (save-restriction
+       (widen)
+       (save-excursion
+         (goto-char (point-min))
+         (looking-at-p mag))))
+    ((or `(,_ interpreter-mode-alist ,magic _)
+         `(,_ interpreter-mode-alist ,magic))
+     (save-restriction
+       (widen)
+       (save-excursion
+         (goto-char (point-min))
+         (and (looking-at auto-mode-interpreter-regexp)
+              (string-match-p
+               (concat "\\`" (file-name-nondirectory (match-string 2)) "\\'")
+               magic)))))))
+
+(defun package--autosuggest-find-candidates ()
+  "Return a list of packages that might be interesting the current buffer."
+  (and package-autosuggest-mode
+       (let (suggetions)
+         (dolist (sug package-autosuggest-database)
+           (when (package--suggestion-applies-p sug)
+             (push sug suggetions)))
+         suggetions)))
+
+(defun package--autosuggest-install-and-enable (pkg-sug)
+  "Install and enable a package suggestion PKG-ENT.
+PKG-SUG has the same form as an element of
+`package-autosuggest-database'."
+  (package-install (car pkg-sug))
+  (with-demoted-errors "Failed to enable: %S"
+    (dolist (buf (buffer-list))
+      (with-current-buffer buf
+        (when (and (eq major-mode 'fundamental-mode) (buffer-file-name)
+                   (package--suggestion-applies-p pkg-sug))
+          (funcall-interactively (or (cadddr pkg-sug) (car pkg-sug))))))))
+
+(defvar package--autosuggest-suggested '()
+  "List of packages that have already been suggested.")
+
+(defun package--autosuggest-after-change-mode ()
+  "Hook function to suggest packages for installation."
+  (when-let ((avail (seq-difference (package--autosuggest-find-candidates)
+                                    package--autosuggest-suggested))
+             (pkgs (mapconcat #'symbol-name
+                              (delete-dups (mapcar #'car avail))
+                              ", ")))
+    (pcase package-autosuggest-mode
+      ('always
+       (when (yes-or-no-p (format "Install suggested packages (%s)?" pkg))
+         (mapc #'package--autosuggest-install-and-enable avail)))
+      ('once
+       (when (yes-or-no-p (format "Install suggested packages (%s)?" pkg))
+         (mapc #'package--autosuggest-install-and-enable avail))
+       (setq package--autosuggest-suggested (append avail package--autosuggest-suggested)))
+      ('message
+       (message
+        (substitute-command-keys
+         (format "Found suggested packages: %s.  Install using \\[package-autosuggest]"
+                 pkgs)))))))
+
+(defun package-autosuggest ()
+  "Prompt the user for suggested packages."
+  (interactive)
+  (let* ((avail (or (package--autosuggest-find-candidates)
+                    (user-error "No suggestions found")))
+         (pkgs (completing-read-multiple
+                "Install suggested packages: " avail
+                nil t
+                (mapconcat #'symbol-name
+                           (delete-dups (mapcar #'car avail))
+                           ",")))
+         (choice (concat "\\`" (regexp-opt pkgs) "\\'")))
+    (dolist (ent avail)
+      (when (string-match-p choice (symbol-name (car ent)))
+        (package--autosuggest-install-and-enable ent)))))
+
 \f
 ;;;; Quickstart: precompute activation actions for faster start up.
 

[-- Attachment #3: Type: text/plain, Size: 250 bytes --]


The documentation is obviously lacking and incomplete, I just wanted to
have a POC to discuss the idea.

I am not sure if the default option 'message is still too aggressive, as
opinions differ on how and who should print messages in the echo area.

Re: package-autosuggest

[Stefan Monnier]

> +(defun package--suggestion-applies-p (pkg-sug)
> +  "Check if a suggestion PKG-SUG is applicable to the current buffer."
> +  (pcase pkg-sug
> +    (`(,(pred package-installed-p) . _) nil)

I think we should strive to minimize the dependency on `package.el` (as
well as the performance impact) so we should try and use something like
`fboundp` here instead (testing "the function" provided by the package
when it's installed).


        Stefan

Re: package-autosuggest

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> +(defun package--suggestion-applies-p (pkg-sug)
>> +  "Check if a suggestion PKG-SUG is applicable to the current buffer."
>> +  (pcase pkg-sug
>> +    (`(,(pred package-installed-p) . _) nil)
>
> I think we should strive to minimize the dependency on `package.el` (as
> well as the performance impact) so we should try and use something like
> `fboundp` here instead (testing "the function" provided by the package
> when it's installed).

Would you argue it would be better to implement this feature outside of
package.el?  And by function we mean something like the major mode of a
package, right?

>
>         Stefan

Re: package-autosuggest

[Stefan Monnier]

> Would you argue it would be better to implement this feature outside of
> package.el?

That too, but it's less important.  I think he dependency on ELPA (and
`package.el`) should be limited to:

- Providing an option to install the package via `package-install` (tho
  it would be good to make it configurable so people can also use other
  options like `package-vc-install`).

- Potentially populate the `package-autosuggest-database` via a script
  that extracts the info from `elpa.git` or `elpa.gnu.org` or some such.

> And by function we mean something like the major mode of a
> package, right?

How to test whether a given package is already available is not always
the same, so `package-installed-p` can sometimes come in handy, but in
the present case of packages providing (major) modes, then testing
`fboundp` on the major mode function is a better option: it's faster
and it gives the right answer also when the package was installed via
some other means than `package.el`.


        Stefan

Re: package-autosuggest

[Eshel Yaron]

Thanks for putting together a concrete proposal, Philip.

I really like this idea, I think it could be really useful for new
users.  A couple of thoughts:

Philip Kaludercic <philipk@posteo.net> writes:

> Here is a quick and rough draft of how this feature could look like:
>
> diff --git a/lisp/emacs-lisp/package.el b/lisp/emacs-lisp/package.el
> index e1172d69bf0..723900318c5 100644
> --- a/lisp/emacs-lisp/package.el
> +++ b/lisp/emacs-lisp/package.el
> @@ -4534,6 +4534,116 @@ package-get-version
>              (or (lm-header "package-version")
>                  (lm-header "version")))))))))
>
> +\f
> +;;;; Autosuggest
> +
> +(defvar package-autosuggest-database
> +  '((sml-mode auto-mode-alist "\\.sml\\'")
> +    (lua-mode auto-mode-alist "\\.lua\\'" )
> +    (ada-mode auto-mode-alist "\\.ada\\'")
> +    ;; ...
> +    ;;
> +    ;; this is just for testing, in practice I think this data should
> +    ;; be generated and bundled with Emacs, and would ideally be
> +    ;; loaded in at compile-time.  When the "archive-contents" file
> +    ;; format is updated, we can include more information in there
> +    ;; that would be added to this database.
> +    )
> +  "Database of hints for packages to suggest installing.")
> +

IMO, the suggestions "database" should be slightly more sophisticated,
and manually curated:

- Sophisticated: each hint should have a confidence/certainty indicator,
  possibly a symbol among `certain`, `probable`, `possible`.  Some
  "hint" (detection mechanisms for missing packages) rely on stronger
  signals than others, and that affects the probability of false
  positives.  Consider, for example, `sxhkdrc-mode` from GNU ELPA.  If a
  user opens a file named `sxhkdrc`, it's almost certain they could
  benefit from this package and Emacs should assertively suggest it.  On
  the other hand, the extensions `.sml` is used for many file formats
  other than Standard ML, so it's a relatively weaker signal for
  suggesting `sml-mode`.  These confidence levels can help Emacs use the
  correct UI/wording for different package suggestions.

- Manually curated: Emacs should only push suggestions for packages that
  the project whole-heartedly recommends.  Crucially, it's not enough
  for a package to declare that it provides a major mode for a certain
  file format to guarantee that it actually provides a good user
  experience.  The only way I see for guaranteeing the quality of these
  suggestions is by manually curating them, similarly to the way GNU and
  NonGNU ELPA are curated.


Best,

Eshel

Re: package-autosuggest

[Stefan Monnier]

> - Sophisticated: each hint should have a confidence/certainty indicator,
>   possibly a symbol among `certain`, `probable`, `possible`.

We don't bother with such distinction for all the other entries we
include by default on `auto-mode-alist`, so I'm not sure it's worth
the trouble.

AFAICT the code would only suggest the use of the external package when
it's "instead of falling back to `fundamental-mode`", so I think it's
good enough.  Even if it's not the right package, it might help the users
realize that they should look for an appropriate major mode :-)

> - Manually curated: Emacs should only push suggestions for packages that
>   the project whole-heartedly recommends.

While the quality of the package matters in a certain sense, in practice
the choice of what to include in Emacs or (Non)GNU ELPA comes down to
many other criteria, and there are packages there which I would
*not* recommend (and definitely not "whole-heartedly").

Instead, I think the criteria should be based on the likelihood that the
recommendation is helpful.


        Stefan

Re: package-autosuggest

[Eshel Yaron]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> - Sophisticated: each hint should have a confidence/certainty indicator,
>>   possibly a symbol among `certain`, `probable`, `possible`.
>
> AFAICT the code would only suggest the use of the external package when
> it's "instead of falling back to `fundamental-mode`", so I think it's
> good enough.

Fair enough.

> Even if it's not the right package, it might help the users realize
> that they should look for an appropriate major mode :-)

That'd indeed already be an improvement, my point is that in some cases
we would know that it really is the right package with very high
certainty.  From a user perspective, if Emacs package suggestions are
sometimes great and sometimes not exactly what they were looking for,
it's natural to take all suggestions with a grain of salt.  Suggestions
with a grain of salt is already a pretty good scenario, of course.  But
if Emacs would have a special message that it displays when it has a
suggestion it's really quite sure about, and those are always right on
the money, then the user can learn to confirm those suggestions more
freely and keep their second thoughts for the other (less certain)
suggestions.  So, my suggestion to keep some more metadata is meant to
allow Emacs to have such distinctions, perhaps not right off the bat.

>> - Manually curated: Emacs should only push suggestions for packages that
>>   the project whole-heartedly recommends.
>
> While the quality of the package matters in a certain sense, in practice
> the choice of what to include in Emacs or (Non)GNU ELPA comes down to
> many other criteria, and there are packages there which I would
> *not* recommend (and definitely not "whole-heartedly").
>
> Instead, I think the criteria should be based on the likelihood that the
> recommendation is helpful.
>

Here I think we mostly agree.  IMO since (Non)GNU ELPA accepts packages
that are possibly somewhat work-in-progress, Emacs probably shouldn't
automatically recommend them to users, so some manual curation would be
needed to guarantee that the recommendation is helpful, as you say.

>
>         Stefan

Re: package-autosuggest

[Stefan Kangas]

Eshel Yaron <me@eshelyaron.com> writes:

> That'd indeed already be an improvement, my point is that in some cases
> we would know that it really is the right package with very high
> certainty.

Shouldn't that just be the criterion, then?  In other words, isn't
that what it would mean to only recommend things that are likely to be
helpful?

Re: package-autosuggest

[Eshel Yaron]

Hello Stefan,

Stefan Kangas <stefankangas@gmail.com> writes:

> Eshel Yaron <me@eshelyaron.com> writes:
>
>> That'd indeed already be an improvement, my point is that in some cases
>> we would know that it really is the right package with very high
>> certainty.
>
> Shouldn't that just be the criterion, then?  In other words, isn't
> that what it would mean to only recommend things that are likely to be
> helpful?

I'm not sure.  In Philip's draft, I don't think that this is the case.
(Correct me if I've missed anything, please.)  The way I see it there
are two parameters to consider for each recommendation.  Let's call them
potential and confidence.  Potential is how much value the user can
obtain from Emacs's recommendation.  That depends mostly on the
recommended package itself.  Confidence is how certain Emacs is that
this user should use this package.  For example, again, in the current
draft we have a recommendation for `sml-mode` based on files with
extension `.sml`.  This recommendation has great potential to benefit
Standard ML users (I assume, I haven't tried it out myself), but the
confidence for this recommendation isn't that high, because it's prone
to false positives (not all `.sml` files are Standard ML).

The crux is that the quality of a recommendation depends not only on the
quality of the package but also on the strength of the signal that leads
Emacs to recommend it (the quality of the "hint").

Personally, I think that even with a chance of false positives,
suggesting `sml-mode` to a user that opens `foo.sml` is great.  For this
reason, I proposed that Emacs should make both high-confidence and
low-confidence recommendations, but use different messages for the two
cases (or three, if you want to also have "medium-confidence").


Best,

Eshel

Re: package-autosuggest

[Philip Kaludercic]

Eshel Yaron <me@eshelyaron.com> writes:

> Hello Stefan,
>
> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Eshel Yaron <me@eshelyaron.com> writes:
>>
>>> That'd indeed already be an improvement, my point is that in some cases
>>> we would know that it really is the right package with very high
>>> certainty.
>>
>> Shouldn't that just be the criterion, then?  In other words, isn't
>> that what it would mean to only recommend things that are likely to be
>> helpful?
>
> I'm not sure.  In Philip's draft, I don't think that this is the case.
> (Correct me if I've missed anything, please.)  

The assumption in my draft was that the database would only be
populated with entries that would be considered helpful, or rather if
the database were to be generated from GNU ELPA and NonGNU ELPA
packages, it shouldn't recommend unhelpful packages, as all packages in
GNU and NonGNU ELPA are supposed to be helpful in the first place.

>                                                The way I see it there
> are two parameters to consider for each recommendation.  Let's call them
> potential and confidence.  Potential is how much value the user can
> obtain from Emacs's recommendation.  That depends mostly on the
> recommended package itself.  Confidence is how certain Emacs is that
> this user should use this package.  For example, again, in the current
> draft we have a recommendation for `sml-mode` based on files with
> extension `.sml`.  This recommendation has great potential to benefit
> Standard ML users (I assume, I haven't tried it out myself), but the
> confidence for this recommendation isn't that high, because it's prone
> to false positives (not all `.sml` files are Standard ML).

That is a legitimate point, but one that Emacs suffers from in general.
I frequently find Perl and Prolog files that both end in .pl, but there
can only be one entry in auto-mode-list (unless you manually do a
`c-or-c++-mode').

> The crux is that the quality of a recommendation depends not only on the
> quality of the package but also on the strength of the signal that leads
> Emacs to recommend it (the quality of the "hint").

So are you thinking of a numerical value?  And wouldn't the value depend
on the file contents?  And how do you think this valuation should be
used?

> Personally, I think that even with a chance of false positives,
> suggesting `sml-mode` to a user that opens `foo.sml` is great.  For this
> reason, I proposed that Emacs should make both high-confidence and
> low-confidence recommendations, but use different messages for the two
> cases (or three, if you want to also have "medium-confidence").

The current proposal wouldn't install anything automatically anyway, it
would prompt the user if they are interested in this kind of a file

>
> Best,
>
> Eshel

Re: package-autosuggest

[Stefan Monnier]

> The current proposal wouldn't install anything automatically anyway, it
> would prompt the user if they are interested in this kind of a file

Also, the system should make it easy to "just say no", so the prompt
should only appear once (unless the user explicitly chooses to "do
nothing for now, but remind me later").


        Stefan

Re: package-autosuggest

[Philip Kaludercic]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> The current proposal wouldn't install anything automatically anyway, it
>> would prompt the user if they are interested in this kind of a file
>
> Also, the system should make it easy to "just say no", so the prompt
> should only appear once (unless the user explicitly chooses to "do
> nothing for now, but remind me later").

Right, which is why I think that the user option to aggressively prompt
the user to install a package is misguided.  The most sensible options I
think are to generate a message every time a fundamental-mode buffer is
found with a matching package, or just once for every package. 

Re: package-autosuggest

[chad]

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

This might be over-engineering at this point, but it was my not-so-secret
hope when suggesting along this line that there would be a good place to
add a branch in the middle, where the system would offer more than one
(incompatible, at least sometimes) choice to the user, with the hope of
eventually being a bridge to "hey, this looks like C-Sharp. Would you like
c-sharp-ts-mode or CC-mode for this? (Now/future/ask again later)" and
maybe also "This is probably Perl or Prolog code. Would you like perl-mode,
cperl-mode, perl-ts-mode, prolog-mode, or...."

I hope this helps,
~Chad

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

Re: package-autosuggest

[Philip Kaludercic]

chad <yandros@gmail.com> writes:

> This might be over-engineering at this point, but it was my not-so-secret
> hope when suggesting along this line that there would be a good place to
> add a branch in the middle, where the system would offer more than one
> (incompatible, at least sometimes) choice to the user, with the hope of
> eventually being a bridge to "hey, this looks like C-Sharp. Would you like
> c-sharp-ts-mode or CC-mode for this? (Now/future/ask again later)" 

From my testing, a prompt like this seems too aggressive and annoying.
The best alternative, it seems to me is a message in the echo area or a
lighter in the mode line.  I am leaning more and more towards the
latter, since might make the most mouse-friendly interface that
newcomers are likely to appreciate.

>                                                                    and
> maybe also "This is probably Perl or Prolog code. Would you like perl-mode,
> cperl-mode, perl-ts-mode, prolog-mode, or...."

My last proposal used completing-read-multiple, but another idea would
be to pop open a filtered down *Packages* buffer, assuming that isn't to
confusing of an interface.

> I hope this helps,
> ~Chad

Re: Clojure mode

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Mon, 28 Aug 2023 16:51:12 -0400
> Cc: bozhidar@batsov.dev, dmitry@gutov.dev, rms@gnu.org, danny@dfreeman.email, 
> 	emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> What I had in mind was something akin to autoload that, rather than providing _any_ clojure mode (in
> this specific example), instead provides the user with a buffer conveying that Clojure support in
> emacs is available, but is not currently bundled directly, and offers the user a short description of
> each of the two packages clojure-mode and clojure-ts-mode, along with buttons to install and activate
> each package. 
> 
> Thus, if a new user started a freshly downloaded emacs, they would find some guidance (rather than,
> for example, "[No match]" from M-x or fundamental-mode from opening test.clj), and we could provide
> some short info backed by the full package description in cases where there was no current
> always-recommend. The message/guidance could be conceptually similar to the disable-command
> machinery.
> 
> I had autoload in mind based on the idea that this guidance code would be supplanted by an actually
> installed package (and, I think, ideally restored if the package was later removed). In other words, I'm
> suggesting adding an optional dispatching step for the paths most likely to invoke a
> not-directly-supported-in-core language.
> 
> Perhaps *eventually* something similar could be done for suggesting say, c-sharp-ts-mode and
> cc-mode for a fresh emacs and "C-x C-f test.cs". I imagine that there are refinements that could be
> useful for someone who wanted to try assembling a small-core emacs, but I'd be surprised if there
> weren't important lessons to learn before that point.
> 
> I hope this description is clearer; please let me know if I missed or forgot anything important.

Thanks, it's more clear now.

However, this is a kind of feature we never had in Emacs, so I think
we should first discuss how to present such suggestions to users, and
also how to keep the database of packages we'd like to suggest
installing in this way.

Re: Clojure mode

[Richard Stallman]

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

  > What I had in mind was something akin to autoload that, rather than
  > providing _any_ clojure mode (in this specific example), instead provides
  > the user with a buffer conveying that Clojure support in emacs is
  > available, but is not currently bundled directly, and offers the user a
  > short description of each of the two packages clojure-mode and
  > clojure-ts-mode, along with buttons to install and activate each package.

That would be more convenient for people editing Clojure programs.
But it has a downside: it would tend to fuzz the distinction between
GNU Emacs and NonGNU ELPA.

That distinction is important, and it is important for users
to know about it.

This is why loading anything whatsoever from NonGNU ELPA has to be an
explicit request from the user.  Nothing should ever enable it
implicitly.

Perhaps we can find a way to modify this suggestion to avoid that
downside.  The crucial thing is not to aim to make it smooth or
automatic, but on the contrary to impress on the user that this
is crossing a gulf.


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

Re: Clojure mode

[Gregor Zattler]

* Richard Stallman <rms@gnu.org> [2023-08-30; 22:07 -04]:
> [[[ 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 I had in mind was something akin to autoload that, rather than
>   > providing _any_ clojure mode (in this specific example), instead provides
>   > the user with a buffer conveying that Clojure support in emacs is
>   > available, but is not currently bundled directly, and offers the user a
>   > short description of each of the two packages clojure-mode and
>   > clojure-ts-mode, along with buttons to install and activate each package.
>
> That would be more convenient for people editing Clojure programs.
> But it has a downside: it would tend to fuzz the distinction between
> GNU Emacs and NonGNU ELPA.
>
> That distinction is important, and it is important for users
> to know about it.
>
> This is why loading anything whatsoever from NonGNU ELPA has to be an
> explicit request from the user.  Nothing should ever enable it
> implicitly.
>
> Perhaps we can find a way to modify this suggestion to avoid that
> downside.  The crucial thing is not to aim to make it smooth or
> automatic, but on the contrary to impress on the user that this
> is crossing a gulf.

why is this crossing a gulf?

The packages in NonGnu ELPA are selected by the Emacs
developers, and according to
https://git.savannah.gnu.org/cgit/emacs/nongnu.git/plain/README.org,
there "* Guidance for accepting packages", a package in
NonGnu ELPA is GPL-3+ (for documentation and education
other licenses are prescribed), does not refer users to
any nonfree software or nonfree documentation, in
general does not run code that it has fetched over the
internet, delivers its full functionality and
convenience on a completely free platform based on the
GNU operating system, only provides features on
non-free systems which are already provides on free
ones, may communicate with a class of remote services
only if this is for communication or to access
published material, may not use remote services to do
the user's own computational processing, may not
advertise anything commercial with material in the
NonGNU ELPA package or this repository with the
exception of paid service for said package; the Emacs
developers even may change/maintain it.

So the only difference to Gnu ELPA is the copyright
assignment.  Why does that amount to crossing a gulf
for the user?

Re: Clojure mode

[Richard Stallman]

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

  > The current idea of including ELPA packages is to include them in the
  > release tarball, so that for the end-user it looks exactly like a core
  > package.

We can do that with some GNU ELPA packages, but the GNU Project cannot
distribute NonGNU ELPA packages as part of GNU Emacs.

The point of NonGNU ELPA is to make it easier for users to access some
of the packages that we can't include in GNU Emacs.  But it is still
indirect.  We cannot do anything that treats them as part of GNU
Emacs.

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

Re: Clojure mode

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 30 Aug 2023 22:07:44 -0400
> 
>   > The current idea of including ELPA packages is to include them in the
>   > release tarball, so that for the end-user it looks exactly like a core
>   > package.
> 
> We can do that with some GNU ELPA packages, but the GNU Project cannot
> distribute NonGNU ELPA packages as part of GNU Emacs.

It is indeed planned to do that only with packages on GNU ELPA.  But
we haven't yet figured some important aspects of including ELPA
packages in release tarballs, so the idea is there, but it is not yet
actionable.

Re: Bundling ELPA packages with Emacs

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Richard Stallman <rms@gnu.org>
>> Cc: emacs-devel@gnu.org
>> Date: Wed, 30 Aug 2023 22:07:44 -0400
>> 
>>   > The current idea of including ELPA packages is to include them in the
>>   > release tarball, so that for the end-user it looks exactly like a core
>>   > package.
>> 
>> We can do that with some GNU ELPA packages, but the GNU Project cannot
>> distribute NonGNU ELPA packages as part of GNU Emacs.
>
> It is indeed planned to do that only with packages on GNU ELPA.  But
> we haven't yet figured some important aspects of including ELPA
> packages in release tarballs, so the idea is there, but it is not yet
> actionable.

I was under the assumption that issue was resolved, if
`package-directory-list' would contain the right directory?

Re: Bundling ELPA packages with Emacs

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: rms@gnu.org,  emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 06:10:17 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > It is indeed planned to do that only with packages on GNU ELPA.  But
> > we haven't yet figured some important aspects of including ELPA
> > packages in release tarballs, so the idea is there, but it is not yet
> > actionable.
> 
> I was under the assumption that issue was resolved, if
> `package-directory-list' would contain the right directory?

That's not the only issue we need to resolve.  See

  https://lists.gnu.org/archive/html/emacs-devel/2020-12/msg00917.html
  https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01017.html
  https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01373.html

for the previous discussions, where the issues were raised and
discussed.

Re: Clojure mode

[Richard Stallman]

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

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

This underscores my point: clojure-mode is an important feature, so
Emacs should provide it.  It should be a full-fledged part of Emacs,
documented in Emacs.  To leave these jobs to nonrecommended add-ons,
such as found in NonGNU-ELPA, is not doing a good job.

We hope that Emacs users who write extensions will appreciate Emacs
enough to contribute them to Emacs.  Usually they do.  When they
don't, that's unfortunate -- but we can make up for it.  It isn't an
lot of work compared with all the work we do on Emacs in a year.

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

Re: Clojure mode

[Dmitry Gutov]

On 29/08/2023 04:52, Richard Stallman wrote:
>    > 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.
> 
> This underscores my point: clojure-mode is an important feature, so
> Emacs should provide it.  It should be a full-fledged part of Emacs,
> documented in Emacs.  To leave these jobs to nonrecommended add-ons,
> such as found in NonGNU-ELPA, is not doing a good job.
> 
> We hope that Emacs users who write extensions will appreciate Emacs
> enough to contribute them to Emacs.  Usually they do.  When they
> don't, that's unfortunate -- but we can make up for it.  It isn't an
> lot of work compared with all the work we do on Emacs in a year.

It's an important feature for an existing ecosystem of packages whose 
authors chose to develop and distribute them the way they did.

Hijacking the name, at the very least, would bring a lot of problems.

Re: Clojure mode

[Danny Freeman]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 29/08/2023 04:52, Richard Stallman wrote:
>>    > 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.
>> This underscores my point: clojure-mode is an important feature, so
>> Emacs should provide it.  It should be a full-fledged part of Emacs,
>> documented in Emacs.  To leave these jobs to nonrecommended add-ons,
>> such as found in NonGNU-ELPA, is not doing a good job.
>> We hope that Emacs users who write extensions will appreciate Emacs
>> enough to contribute them to Emacs.  Usually they do.  When they
>> don't, that's unfortunate -- but we can make up for it.  It isn't an
>> lot of work compared with all the work we do on Emacs in a year.
>
> It's an important feature for an existing ecosystem of packages whose authors chose to develop and
> distribute them the way they did.
>
> Hijacking the name, at the very least, would bring a lot of problems.

This is the main source of my concern, summed up better than I am able
to put things.

If the concern is having a decent out of the box experience for reading
and editing clojure source files, would enabling `lisp-mode` out of the
box for clojure-mode files be a decent middle ground? That would provide
decent font-locking and indentation, with a simple modification to the
auto-mode-alist. I just tried it on a clojure project and it looks and
behaves decently.

If a user wants a more IDE like experience they could reach for CIDER
from NonGNU Elpa.

-- 
Danny Freeman

Brand new clojure support in Emacs ;-)

[João Távora]

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

On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
> 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

I don't know if this counts as "work on that" but here's two interesting lines
Elisp:

  (define-derived-mode clojure-mode lisp-data-mode "Clojure"
"Barebones Clojure")
  (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))

Since it is a lisp dialect many things works here, like indentation,
symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.

And then there's LSP, right?

So I installed clojure-lsp from here:
https://aur.archlinux.org/packages/clojure-lsp-bin

I created a hello world project with the "lein" tool, git init, found the
src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
at-point-documentation, diagnostics, lots of refactorings, completion, etc.

The thing that's a bit minimal is the syntax highlighting, but it's
not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
highlighting.  I have no idea what it takes to add TreeSitter support
to such a bare-bones mode (but shouldn't it be really easy like mapping
syntactic symbols to faces?)

No idea if this works with the CIDER or SLIME backends for clojure.
Don't ask me to test any more cause I've just uninstalled it all
but any clojurians rading can have a go.

João

[-- Attachment #2: clojure-mode-and-eglot.png --]
[-- Type: image/png, Size: 16692 bytes --]

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

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

> On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>>
>> 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
>
> I don't know if this counts as "work on that" but here's two interesting lines
> Elisp:
>
>   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> "Barebones Clojure")
>   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))

I suggested something along these lines up the thread, but didn't try it
out myself.  Nice to see that the idea works.  To avoid confusion, I
think it might be a good idea to not call this `clojure-mode' as well,
but something like "clojure-proto-mode" or "primitive-clojure-mode".

> Since it is a lisp dialect many things works here, like indentation,
> symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>
> And then there's LSP, right?
>
> So I installed clojure-lsp from here:
> https://aur.archlinux.org/packages/clojure-lsp-bin
>
> I created a hello world project with the "lein" tool, git init, found the
> src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>
> The thing that's a bit minimal is the syntax highlighting, but it's
> not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> highlighting.  I have no idea what it takes to add TreeSitter support
> to such a bare-bones mode (but shouldn't it be really easy like mapping
> syntactic symbols to faces?)
>
> No idea if this works with the CIDER or SLIME backends for clojure.
> Don't ask me to test any more cause I've just uninstalled it all
> but any clojurians rading can have a go.

I would guess that anyone who is seriously interested in working with
Clojure, would install the proper major mode and the proper packages.

> João

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

> I suggested something along these lines up the thread, but didn't try it
> out myself.

Yes, I read your suggestion, that's why I quoted you ;-)

> Nice to see that the idea works.  To avoid confusion, I
> think it might be a good idea to not call this `clojure-mode' as well,
> but something like "clojure-proto-mode" or "primitive-clojure-mode".

Why?  If the NonGNU people are "too cool for school" after having been
invited to GNU, why should the GNU project make even more special
accomodations for them?  Not up to me to decide anyway.

>> No idea if this works with the CIDER or SLIME backends for clojure.
>> Don't ask me to test any more cause I've just uninstalled it all
>> but any clojurians rading can have a go.
>
> I would guess that anyone who is seriously interested in working with
> Clojure, would install the proper major mode and the proper packages.

I don't know: for some people and/or some tasks, a 3000 LOC major mode
may feel quite bloated, at least when compared one which is -- quite
literally -- a thousand times smaller.

So, not being a Clojure programmer, I wouldn't "guess" what such
programmer would do.  I would just compare one by one what features are
provided by the two modes -- when complemented by LSP of course.

Also, I would try to establish if the CIDER environment can be invoked
from this new major mode, or if it is strongly coupled to the NonGNU
Clojure mode.  If it works anything like SLIME or SLY, it should be some
kind of minor mode which manages a network connection, and thus
theoretically composable.

João

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> I suggested something along these lines up the thread, but didn't try it
>> out myself.
>
> Yes, I read your suggestion, that's why I quoted you ;-)

Oh, did you know I can't read ^^

>> Nice to see that the idea works.  To avoid confusion, I
>> think it might be a good idea to not call this `clojure-mode' as well,
>> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>
> Why?  If the NonGNU people are "too cool for school" after having been
> invited to GNU, why should the GNU project make even more special
> accomodations for them?  Not up to me to decide anyway.

Mainly because this will affect users, not the maintainer.  For example,
if a user has a (fboundp 'clojure-mode) check in their configuration
somewhere, their script might falsely assume that the entire package has
been installed.  I know, their check was not particularly robust, but
personal configurations are often lenient on these issues.

Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
disagree with their reasoning and fear they have been misinformed, but
the best way to remedy situations like these is to be understanding and
prove ourselves to be cooperative by example (IMO).

>>> No idea if this works with the CIDER or SLIME backends for clojure.
>>> Don't ask me to test any more cause I've just uninstalled it all
>>> but any clojurians rading can have a go.
>>
>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper packages.
>
> I don't know: for some people and/or some tasks, a 3000 LOC major mode
> may feel quite bloated, at least when compared one which is -- quite
> literally -- a thousand times smaller.
>
> So, not being a Clojure programmer, I wouldn't "guess" what such
> programmer would do.  I would just compare one by one what features are
> provided by the two modes -- when complemented by LSP of course.
>
> Also, I would try to establish if the CIDER environment can be invoked
> from this new major mode, or if it is strongly coupled to the NonGNU
> Clojure mode.  If it works anything like SLIME or SLY, it should be some
> kind of minor mode which manages a network connection, and thus
> theoretically composable.

I suppose so too, but can also just guess, since I don't use the
language.

> João

-- 
Philip Kaludercic

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Philip Kaludercic <philipk@posteo.net> writes:

>> Why?  If the NonGNU people are "too cool for school" after having been
>> invited to GNU, why should the GNU project make even more special
>> accomodations for them?  Not up to me to decide anyway.
>
> Mainly because this will affect users, not the maintainer.  
> [...]
> Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
> disagree with their reasoning and fear they have been misinformed, but
> the best way to remedy situations like these is to be understanding and
> prove ourselves to be cooperative by example (IMO).

You seem to be under the misguided impression that my proposal is meant
to bother, provoke or help change the minds of the NonGNU Clojure
maintainers?  It's not.

I simply think they shouldn't have a say in how the Emacs project
answers Richard's original request of a Clojure editing mode in Emacs
propoer.

Richard says writing a major mode is not that hard, and I agree.  My
proposal is an extreme answer to that, writing a fully functional,
featureful major mode in just two lines of code.

Of course, it took advantage of the fact the fact that the language to
support is a Lisp dialect and there is an excellent LSP server for it.
But there's no reason _not_ to take advantage of that.

As to naming, it's not my call, so let's have Richard chime in.
clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
not a Clojure user.

That said, I _would_ like to see a mode built from the ground up to work
entirely on top of LSP, not unlike some modes today are being built on
top of TreeSitter.  For example, the few lines of code to add to those
two could be the automatic installation of the clojure-lsp language
server.

João

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> Why?  If the NonGNU people are "too cool for school" after having been
>>> invited to GNU, why should the GNU project make even more special
>>> accomodations for them?  Not up to me to decide anyway.
>>
>> Mainly because this will affect users, not the maintainer.  
>> [...]
>> Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
>> disagree with their reasoning and fear they have been misinformed, but
>> the best way to remedy situations like these is to be understanding and
>> prove ourselves to be cooperative by example (IMO).
>
> You seem to be under the misguided impression that my proposal is meant
> to bother, provoke or help change the minds of the NonGNU Clojure
> maintainers?  It's not.

Not so much that that is the intention, but just that the Clojure-mode
developers might not like using the same name, when for this example a
different name would have the same use.  There are a few here in the
thread, perhaps they can comment on it.

Re: Brand new clojure support in Emacs ;-)

[Kévin Le Gouguec]

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

> Philip Kaludercic <philipk@posteo.net> writes:
>
>>> Why?  If the NonGNU people are "too cool for school" after having been
>>> invited to GNU, why should the GNU project make even more special
>>> accomodations for them?  Not up to me to decide anyway.
>>
>> Mainly because this will affect users, not the maintainer.  
>> [...]
>> Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
>> disagree with their reasoning and fear they have been misinformed, but
>> the best way to remedy situations like these is to be understanding and
>> prove ourselves to be cooperative by example (IMO).
>
> You seem to be under the misguided impression that my proposal is meant
> to bother, provoke or help change the minds of the NonGNU Clojure
> maintainers?  It's not.
>
> I simply think they shouldn't have a say in how the Emacs project
> answers Richard's original request of a Clojure editing mode in Emacs
> propoer.

IMHO that is disproportionately combative.  Regardless of whether
clojure-mode maintainers contribute to core and/or GNU ELPA, they
contribute to Emacs's continued success by serving their users's needs
and keeping these users invested in Emacs.

I think they deserve the courtesy of not encroaching if alternatives can
be found; I second Philip's assessment above.

> As to naming, it's not my call, so let's have Richard chime in.
> clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
> not a Clojure user.

My 2¢, as a passive observer, not a Clojure programmer either, whose
only interests lie in (a) alienating as few people as possible (b)
getting dopamine hits from finding specks of consistency amidst chaos:

* "lisp-clojure-mode", following other "FAMILY-DIALECT-mode" examples
  like "makefile-gmake-mode",

* no specific name (keep the name from the inherited mode,
  lisp-data-mode in your example), just a mode-line hint, following
  other "FAMILY[DIALECT]" examples like sh-script and
  "Shell-script[bash]".

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>>> Why?  If the NonGNU people are "too cool for school" after having been
>>>> invited to GNU, why should the GNU project make even more special
>>>> accomodations for them?  Not up to me to decide anyway.
>>>
>>> Mainly because this will affect users, not the maintainer.  
>>> [...]
>>> Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
>>> disagree with their reasoning and fear they have been misinformed, but
>>> the best way to remedy situations like these is to be understanding and
>>> prove ourselves to be cooperative by example (IMO).
>>
>> You seem to be under the misguided impression that my proposal is meant
>> to bother, provoke or help change the minds of the NonGNU Clojure
>> maintainers?  It's not.
>>
>> I simply think they shouldn't have a say in how the Emacs project
>> answers Richard's original request of a Clojure editing mode in Emacs
>> propoer.
>
> IMHO that is disproportionately combative.  Regardless of whether
> clojure-mode maintainers contribute to core and/or GNU ELPA, they
> contribute to Emacs's continued success by serving their users's needs
> and keeping these users invested in Emacs.
>
> I think they deserve the courtesy of not encroaching if alternatives can
> be found; I second Philip's assessment above.
>
>> As to naming, it's not my call, so let's have Richard chime in.
>> clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
>> not a Clojure user.
>
> My 2¢, as a passive observer, not a Clojure programmer either, whose
> only interests lie in (a) alienating as few people as possible (b)
> getting dopamine hits from finding specks of consistency amidst chaos:
>
> * "lisp-clojure-mode", following other "FAMILY-DIALECT-mode" examples
>   like "makefile-gmake-mode",
>
> * no specific name (keep the name from the inherited mode,
>   lisp-data-mode in your example), just a mode-line hint, following
>   other "FAMILY[DIALECT]" examples like sh-script and
>   "Shell-script[bash]".

I like these ideas as well, even though I am hesitant to call Clojure a
Lisp proper ;)

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> I think they deserve the courtesy of not encroaching if alternatives can
> be found;

That's curious, because "encroaching" goes both ways I could see you ask
that very thing of the other camp.  I guess it's a question of who can
legitimately lay claim to a name in a finite namespace.  I've said
before I don't think "I saw it first" should be a criteria.

Philip Kaludercic <philipk@posteo.net> writes:

>> My 2¢, as a passive observer, not a Clojure programmer either, whose
>> only interests lie in (a) alienating as few people as possible (b)
>> getting dopamine hits from finding specks of consistency amidst chaos:
>>
>> * "lisp-clojure-mode", following other "FAMILY-DIALECT-mode" examples
>>   like "makefile-gmake-mode",
>>
>> * no specific name (keep the name from the inherited mode,
>>   lisp-data-mode in your example), just a mode-line hint, following
>>   other "FAMILY[DIALECT]" examples like sh-script and
>>   "Shell-script[bash]".
>
> I like these ideas as well, even though I am hesitant to call Clojure a
> Lisp proper ;)

No problem about the first, but I think the second doesn't work with
Eglot, I think.  It needs a unique major mode symbol.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Your response is spot on IMO!

We're all on the same side supposedly (building a better Emacs and a stronger Emacs community), yet such discussions feel very hostile to me. And the Emacs maintainers claim that I'm being hostile to them. I can't see how the Emacs community will gain something useful out of such unpleasant exchanges. For me the net result so far is that I'd be less willing to engage in work with Emacs's upstream, just because I don't like the tone of the conversations here and the implied accusations that only the Emacs team knows what's best for the Emacs users. 

On Thu, Aug 31, 2023, at 8:46 AM, Kévin Le Gouguec wrote:
> João Távora <joaotavora@gmail.com> writes:
> 
> > Philip Kaludercic <philipk@posteo.net> writes:
> >
> >>> Why?  If the NonGNU people are "too cool for school" after having been
> >>> invited to GNU, why should the GNU project make even more special
> >>> accomodations for them?  Not up to me to decide anyway.
> >>
> >> Mainly because this will affect users, not the maintainer.  
> >> [...]
> >> Also, I don't see a reason to provoke the Clojure-mode maintainers.  I
> >> disagree with their reasoning and fear they have been misinformed, but
> >> the best way to remedy situations like these is to be understanding and
> >> prove ourselves to be cooperative by example (IMO).
> >
> > You seem to be under the misguided impression that my proposal is meant
> > to bother, provoke or help change the minds of the NonGNU Clojure
> > maintainers?  It's not.
> >
> > I simply think they shouldn't have a say in how the Emacs project
> > answers Richard's original request of a Clojure editing mode in Emacs
> > propoer.
> 
> IMHO that is disproportionately combative.  Regardless of whether
> clojure-mode maintainers contribute to core and/or GNU ELPA, they
> contribute to Emacs's continued success by serving their users's needs
> and keeping these users invested in Emacs.
> 
> I think they deserve the courtesy of not encroaching if alternatives can
> be found; I second Philip's assessment above.
> 
> > As to naming, it's not my call, so let's have Richard chime in.
> > clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
> > not a Clojure user.
> 
> My 2¢, as a passive observer, not a Clojure programmer either, whose
> only interests lie in (a) alienating as few people as possible (b)
> getting dopamine hits from finding specks of consistency amidst chaos:
> 
> * "lisp-clojure-mode", following other "FAMILY-DIALECT-mode" examples
>   like "makefile-gmake-mode",
> 
> * no specific name (keep the name from the inherited mode,
>   lisp-data-mode in your example), just a mode-line hint, following
>   other "FAMILY[DIALECT]" examples like sh-script and
>   "Shell-script[bash]".
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 17:09:03 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Philip Kaludercic" <philipk@posteo.net>,
>  "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>,
>  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> We're all on the same side supposedly (building a better Emacs and a stronger Emacs community),
> yet such discussions feel very hostile to me. And the Emacs maintainers claim that I'm being hostile
> to them. I can't see how the Emacs community will gain something useful out of such unpleasant
> exchanges.

The exchange (any exchange) has two sides, you know.

> For me the net result so far is that I'd be less willing to engage in work with Emacs's
> upstream, just because I don't like the tone of the conversations here and the implied accusations
> that only the Emacs team knows what's best for the Emacs users. 

No one said that only the Emacs teams knows what's best for the
_Emacs_users_.  What I said was something different: that it's the
prerogative and responsibility of the Emacs maintainers to decide
what's best for the Emacs _core_project_, exactly as it's your
prerogative and responsibility to decide what's best for the packages
you develop and maintain.

The fairness and the mutual respect should be on both sides, not just
on one of them.

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

  > As to naming, it's not my call, so let's have Richard chime in.
  > clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
  > not a Clojure user.

It is an Emacs convention that the major mode for a language FOO
is named FOO-mode.  Users expect they can tyoe M-x FOO-mode RET to
select that mode.  They expect to be able to put -*-FOO-*- on the first
line to specify that mode in the file.  We should follow that convention.

Lynn wrote:

  > I don't think using the term "hijacking" is productive.  The GNU emacs
  > developers could well say that using a standard functional name like
  > "clojure-mode" with no intent to contribute it to the core was the
  > "hijacking", or perhaps namespace-squatting.  It would be different for
  > "cider" or another non-standard, nonfunctional name.

You've got it right.  The name "cider" does not fit into an Emacs
standard naming convention; it is simply a name someone chose for a
package.  If we want to develop a similar packge that could be part of
Emacs, we would have no reason to use that name.  So we may as well
pick another nmms for the new package.

I'm ok with making small adaptations to cooperate with the developers
of the external Clojure language mode, when that does not cause a
problem for Emacs.  There is no reason to be ornery.  But we should
not do that in ways that mess up our general conventions.

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: philipk@posteo.net, danny@dfreeman.email, eliz@gnu.org,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> Date: Sun, 03 Sep 2023 21:27:38 -0400
> 
>   > As to naming, it's not my call, so let's have Richard chime in.
>   > clojure-mode, newclojure-mode, etc, I personally don't care, since I'm
>   > not a Clojure user.
> 
> It is an Emacs convention that the major mode for a language FOO
> is named FOO-mode.  Users expect they can tyoe M-x FOO-mode RET to
> select that mode.  They expect to be able to put -*-FOO-*- on the first
> line to specify that mode in the file.  We should follow that convention.

That is in general true and preferred, but there are already
deviations from this.  Examples include the venerable cperl-mode and
the recently-added *-ts-mode's.

So, if needed (and I'm not saying it's needed in this case, as the
discussions still continue and the jury is still out on what would be
the final outcome), we can use a slightly non-standard name if there
are good reasons.  Let's not be too dogmatic when the situation is
delicate and requires us to be creative for the greater good.

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

  > So, if needed (and I'm not saying it's needed in this case, as the
  > discussions still continue and the jury is still out on what would be
  > the final outcome), we can use a slightly non-standard name if there
  > are good reasons.

The reason would be to make -*-clojure-*- run the major mode that
is included in Emacs.

The ideal solution would be that the Clojure mode now in NonGNU ELPA
moves into Emacs.

By the way, do we have a feature that can autoload major modes
that are in GNU ELPA?  I think one is needed.


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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Wed, 06 Sep 2023 21:20:43 -0400
> 
>   > So, if needed (and I'm not saying it's needed in this case, as the
>   > discussions still continue and the jury is still out on what would be
>   > the final outcome), we can use a slightly non-standard name if there
>   > are good reasons.
> 
> The reason would be to make -*-clojure-*- run the major mode that
> is included in Emacs.
> 
> The ideal solution would be that the Clojure mode now in NonGNU ELPA
> moves into Emacs.

Agreed on both counts.  I'm just saying that if we decide to have a
slightly less ideal solution, we can.  Having built-in support for
Clojure is more important than having an ideal solution for that.

> By the way, do we have a feature that can autoload major modes
> that are in GNU ELPA?  I think one is needed.

What do you mean by "autoload major modes that are in GNU ELPA"?
Emacs will autoload any mode which is installed on the local computer,
either as part of Emacs or downloaded and installed via package.el.
If you meant something else, please elaborate.

Re: Brand new clojure support in Emacs ;-)

[João Távora]

On Thu, Sep 7, 2023 at 9:23 AM Eli Zaretskii <eliz@gnu.org> wrote:

> Agreed on both counts.  I'm just saying that if we decide to have a
> slightly less ideal solution, we can.  Having built-in support for
> Clojure is more important than having an ideal solution for that.

Fully agree.  Let's give the NonGNU modes time do ponder and if it
doesn't work out, I think a from-scratch solution is the way to go.  If
it comes to that, I can help develop the minimal prototype I presented
into something with decent fontification and possibly also interoperation
with heavier packages like CIDER (with or without that package's
cooperation).

> > By the way, do we have a feature that can autoload major modes
> > that are in GNU ELPA?  I think one is needed.
>
> What do you mean by "autoload major modes that are in GNU ELPA"?
> Emacs will autoload any mode which is installed on the local computer,
> either as part of Emacs or downloaded and installed via package.el.
> If you meant something else, please elaborate.

If I had to guess, I think Richard means something similar to what
Philip was suggesting, something that could be described as perhaps
be described as autoinstall (from GNU ELPA).

João

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> You've got it right.  The name "cider" does not fit into an Emacs
> standard naming convention; it is simply a name someone chose for a
> package.  If we want to develop a similar packge that could be part of
> Emacs, we would have no reason to use that name.  So we may as well
> pick another nmms for the new package.

The name 'cider' isn't the issue here, as CIDER is not the name of
something we're interested in importing into Emacs.

The names 'clojure-mode' and 'clojure-ts-modes' are the issue.  We can't
(easily) use these names for writing a Clojure mode from scratch because
they have already been "taken away" in some sense by two NonGNU
projects.

However, it's unclear at this point if these NonGNU projects will become
GNU after all.  The authors had previously declined an invitation, but
it may not be the end of the story.

> I'm ok with making small adaptations to cooperate with the developers
> of the external Clojure language mode, when that does not cause a
> problem for Emacs.  There is no reason to be ornery.  But we should
> not do that in ways that mess up our general conventions.

If the new Clojure major mode editing mode is to be written from
scratch, we'll have to "mess up" the aforementioned convention slightly,
at least for the foresseable future.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> I would guess that anyone who is seriously interested in working with
> Clojure, would install the proper major mode and the proper package

That's one of the things that bother me the most in the conversations so far - lots of people tell us what the Clojure users need, but other than me and Danny, no one here has any real interest in Clojure. :-) Without an understanding of Clojure and its tooling ecosystem (and it's history) it's hard to make good suggestions about what makes sense and what doesn't. 

I already wrote we tried the "thin layer on top of lisp-mode" and this didn't worked out great in the past. Of course, people are welcome to try and learn from experience themselves if they thing they can do things better/differently. 

On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
> João Távora <joaotavora@gmail.com> writes:
> 
> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
> >>
> >> 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
> >
> > I don't know if this counts as "work on that" but here's two interesting lines
> > Elisp:
> >
> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> > "Barebones Clojure")
> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
> 
> I suggested something along these lines up the thread, but didn't try it
> out myself.  Nice to see that the idea works.  To avoid confusion, I
> think it might be a good idea to not call this `clojure-mode' as well,
> but something like "clojure-proto-mode" or "primitive-clojure-mode".
> 
> > Since it is a lisp dialect many things works here, like indentation,
> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
> >
> > And then there's LSP, right?
> >
> > So I installed clojure-lsp from here:
> > https://aur.archlinux.org/packages/clojure-lsp-bin
> >
> > I created a hello world project with the "lein" tool, git init, found the
> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
> >
> > The thing that's a bit minimal is the syntax highlighting, but it's
> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> > highlighting.  I have no idea what it takes to add TreeSitter support
> > to such a bare-bones mode (but shouldn't it be really easy like mapping
> > syntactic symbols to faces?)
> >
> > No idea if this works with the CIDER or SLIME backends for clojure.
> > Don't ask me to test any more cause I've just uninstalled it all
> > but any clojurians rading can have a go.
> 
> I would guess that anyone who is seriously interested in working with
> Clojure, would install the proper major mode and the proper packages.
> 
> > João
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper package
>
> That's one of the things that bother me the most in the conversations
> so far - lots of people tell us what the Clojure users need, but other
> than me and Danny, no one here has any real interest in Clojure. :-)
> Without an understanding of Clojure and its tooling ecosystem (and
> it's history) it's hard to make good suggestions about what makes
> sense and what doesn't.

This suggestion comes from a different point of view, namely that if I
open a clojure file, that I have anything else but fundamental mode to
structure the file.  And if it is true that LSP integration could
provide xref, imenu, capf, etc. support, one would come a long way for
modest needs with very little code.  Just like with the common-lisp
mode, the support is of course better if you install SLIME or Sly, but
having some basic OOTB support is already a good thing and all this
thread started out with.

Of course, it would be even better if you and your co-maintainers could
be convinced to distribute clojure-mode along with Emacs (again, this
doesn't mean development must be moved away from GitHub), but just like
with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
synchronised with the core.  But IIUC, your main issues is the copyright
assignment and the concern that it might limit who might contribute,
right?

> I already wrote we tried the "thin layer on top of lisp-mode" and this
> didn't worked out great in the past. Of course, people are welcome to
> try and learn from experience themselves if they thing they can do
> things better/differently.
>
> On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
>> João Távora <joaotavora@gmail.com> writes:
>> 
>> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> >>
>> >> 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
>> >
>> > I don't know if this counts as "work on that" but here's two interesting lines
>> > Elisp:
>> >
>> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
>> > "Barebones Clojure")
>> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
>> 
>> I suggested something along these lines up the thread, but didn't try it
>> out myself.  Nice to see that the idea works.  To avoid confusion, I
>> think it might be a good idea to not call this `clojure-mode' as well,
>> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>> 
>> > Since it is a lisp dialect many things works here, like indentation,
>> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>> >
>> > And then there's LSP, right?
>> >
>> > So I installed clojure-lsp from here:
>> > https://aur.archlinux.org/packages/clojure-lsp-bin
>> >
>> > I created a hello world project with the "lein" tool, git init, found the
>> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
>> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>> >
>> > The thing that's a bit minimal is the syntax highlighting, but it's
>> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
>> > highlighting.  I have no idea what it takes to add TreeSitter support
>> > to such a bare-bones mode (but shouldn't it be really easy like mapping
>> > syntactic symbols to faces?)
>> >
>> > No idea if this works with the CIDER or SLIME backends for clojure.
>> > Don't ask me to test any more cause I've just uninstalled it all
>> > but any clojurians rading can have a go.
>> 
>> I would guess that anyone who is seriously interested in working with
>> Clojure, would install the proper major mode and the proper packages.
>> 
>> > João
>> 
>> 

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Of course, it would be even better if you and your co-maintainers could
> be convinced to distribute clojure-mode along with Emacs (again, this
> doesn't mean development must be moved away from GitHub), but just like
> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
> synchronised with the core.  But IIUC, your main issues is the copyright
> assignment and the concern that it might limit who might contribute,
> right?

Other than the contributor agreement there's development overhead to consider:

- where are issues reported? I don't want to use the Emacs issue tracker, but that'd be unavoidable for something built-in, so instead of having one issue tracker you end up with two (one of which I really dislike)
- some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the clojure-mode maintainers would be willing to deal with this
- discussions related to problems/ideas would be happening in different places
- there's also so overhead of keeping the GitHub repo and the code in Emacs in sync

I can go on and on about this - hybrid development models simply come with a lot of overhead. I get that here many people think that GitHub is the root of all evil, but political preferences aside - it's the largest forge in the world by a huge margin and I think it provides unique benefits to projects that can't be replicated elsewhere. At least not today. 

On Sun, Sep 3, 2023, at 5:19 PM, Philip Kaludercic wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> >> I would guess that anyone who is seriously interested in working with
> >> Clojure, would install the proper major mode and the proper package
> >
> > That's one of the things that bother me the most in the conversations
> > so far - lots of people tell us what the Clojure users need, but other
> > than me and Danny, no one here has any real interest in Clojure. :-)
> > Without an understanding of Clojure and its tooling ecosystem (and
> > it's history) it's hard to make good suggestions about what makes
> > sense and what doesn't.
> 
> This suggestion comes from a different point of view, namely that if I
> open a clojure file, that I have anything else but fundamental mode to
> structure the file.  And if it is true that LSP integration could
> provide xref, imenu, capf, etc. support, one would come a long way for
> modest needs with very little code.  Just like with the common-lisp
> mode, the support is of course better if you install SLIME or Sly, but
> having some basic OOTB support is already a good thing and all this
> thread started out with.
> 
> Of course, it would be even better if you and your co-maintainers could
> be convinced to distribute clojure-mode along with Emacs (again, this
> doesn't mean development must be moved away from GitHub), but just like
> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
> synchronised with the core.  But IIUC, your main issues is the copyright
> assignment and the concern that it might limit who might contribute,
> right?
> 
> > I already wrote we tried the "thin layer on top of lisp-mode" and this
> > didn't worked out great in the past. Of course, people are welcome to
> > try and learn from experience themselves if they thing they can do
> > things better/differently.
> >
> > On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
> >> João Távora <joaotavora@gmail.com> writes:
> >> 
> >> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
> >> >>
> >> >> 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
> >> >
> >> > I don't know if this counts as "work on that" but here's two interesting lines
> >> > Elisp:
> >> >
> >> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> >> > "Barebones Clojure")
> >> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
> >> 
> >> I suggested something along these lines up the thread, but didn't try it
> >> out myself.  Nice to see that the idea works.  To avoid confusion, I
> >> think it might be a good idea to not call this `clojure-mode' as well,
> >> but something like "clojure-proto-mode" or "primitive-clojure-mode".
> >> 
> >> > Since it is a lisp dialect many things works here, like indentation,
> >> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
> >> >
> >> > And then there's LSP, right?
> >> >
> >> > So I installed clojure-lsp from here:
> >> > https://aur.archlinux.org/packages/clojure-lsp-bin
> >> >
> >> > I created a hello world project with the "lein" tool, git init, found the
> >> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> >> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
> >> >
> >> > The thing that's a bit minimal is the syntax highlighting, but it's
> >> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> >> > highlighting.  I have no idea what it takes to add TreeSitter support
> >> > to such a bare-bones mode (but shouldn't it be really easy like mapping
> >> > syntactic symbols to faces?)
> >> >
> >> > No idea if this works with the CIDER or SLIME backends for clojure.
> >> > Don't ask me to test any more cause I've just uninstalled it all
> >> > but any clojurians rading can have a go.
> >> 
> >> I would guess that anyone who is seriously interested in working with
> >> Clojure, would install the proper major mode and the proper packages.
> >> 
> >> > João
> >> 
> >> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core.  But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>
> Other than the contributor agreement there's development overhead to consider:
>
> - where are issues reported? I don't want to use the Emacs issue
> tracker, but that'd be unavoidable for something built-in, so instead
> of having one issue tracker you end up with two (one of which I really
> dislike)
> - some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the clojure-mode maintainers would be willing to deal with this
> - discussions related to problems/ideas would be happening in different places

To my knowledge, this is not an issue with the packages I have
mentioned.  Of course there are exceptions, but to my knowledge
basically all conversation about org-mode happens on their mailing
lists, basically all conversation about the modus themes, happen on
Prot's mailing list/issue trackers.

> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync

This is a minor point, IMO, and if it is relevant, it will usually be
because of a downstream change that should be upstreamed anyway
(e.g. someone replaced all occurrences of an inefficient construct, and
happens to do so in clojure-mode as well).

> I can go on and on about this - hybrid development models simply come
> with a lot of overhead. 

The mistake I want to emphasise here is that this is not a "hybrid
development model".  Development continues on your own terms, and just
gets copied over into emacs.git on a regular basis.

>                         I get that here many people think that GitHub
> is the root of all evil, but political preferences aside - it's the
> largest forge in the world by a huge margin and I think it provides
> unique benefits to projects that can't be replicated elsewhere. At
> least not today.

While I disagree, especially with GitHubs recent 2FA push, IIUC I just
want to clarify that this is not what is being discussed.

Other than these points, is the CA the only major issue.  Or to put it
differently, if you could state the conditions for clojure-mode to be
distributed with Emacs, what would your conditions be?  My point here is
just to clarify if there is a solution to this discussion -- in which
case I think it is worth continuing it -- of if you /want to not want
to/ have clojure-mode added to core Emacs?

>
> On Sun, Sep 3, 2023, at 5:19 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper package
>> >
>> > That's one of the things that bother me the most in the conversations
>> > so far - lots of people tell us what the Clojure users need, but other
>> > than me and Danny, no one here has any real interest in Clojure. :-)
>> > Without an understanding of Clojure and its tooling ecosystem (and
>> > it's history) it's hard to make good suggestions about what makes
>> > sense and what doesn't.
>> 
>> This suggestion comes from a different point of view, namely that if I
>> open a clojure file, that I have anything else but fundamental mode to
>> structure the file.  And if it is true that LSP integration could
>> provide xref, imenu, capf, etc. support, one would come a long way for
>> modest needs with very little code.  Just like with the common-lisp
>> mode, the support is of course better if you install SLIME or Sly, but
>> having some basic OOTB support is already a good thing and all this
>> thread started out with.
>> 
>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core.  But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>> 
>> > I already wrote we tried the "thin layer on top of lisp-mode" and this
>> > didn't worked out great in the past. Of course, people are welcome to
>> > try and learn from experience themselves if they thing they can do
>> > things better/differently.
>> >
>> > On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
>> >> João Távora <joaotavora@gmail.com> writes:
>> >> 
>> >> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
>> >> >>
>> >> >> 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
>> >> >
>> >> > I don't know if this counts as "work on that" but here's two interesting lines
>> >> > Elisp:
>> >> >
>> >> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
>> >> > "Barebones Clojure")
>> >> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
>> >> 
>> >> I suggested something along these lines up the thread, but didn't try it
>> >> out myself.  Nice to see that the idea works.  To avoid confusion, I
>> >> think it might be a good idea to not call this `clojure-mode' as well,
>> >> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>> >> 
>> >> > Since it is a lisp dialect many things works here, like indentation,
>> >> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
>> >> >
>> >> > And then there's LSP, right?
>> >> >
>> >> > So I installed clojure-lsp from here:
>> >> > https://aur.archlinux.org/packages/clojure-lsp-bin
>> >> >
>> >> > I created a hello world project with the "lein" tool, git init, found the
>> >> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
>> >> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
>> >> >
>> >> > The thing that's a bit minimal is the syntax highlighting, but it's
>> >> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
>> >> > highlighting.  I have no idea what it takes to add TreeSitter support
>> >> > to such a bare-bones mode (but shouldn't it be really easy like mapping
>> >> > syntactic symbols to faces?)
>> >> >
>> >> > No idea if this works with the CIDER or SLIME backends for clojure.
>> >> > Don't ask me to test any more cause I've just uninstalled it all
>> >> > but any clojurians rading can have a go.
>> >> 
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper packages.
>> >> 
>> >> > João
>> >> 
>> >> 
>> 

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Other than these points, is the CA the only major issue.  Or to put it
> differently, if you could state the conditions for clojure-mode to be
> distributed with Emacs, what would your conditions be?  My point here is
> just to clarify if there is a solution to this discussion -- in which
> case I think it is worth continuing it -- of if you /want to not want
> to/ have clojure-mode added to core Emacs?

If what you said is true (and I guess it is, given that Eli wrote more or less the same), then probably the CA will be the main obstacle. I'll need to discuss this further with the other members of clojure-emacs, as me and Danny are the only people on emacs-devel to my knowledge. In general - tracking down all the contributors and getting them to sign the CA will certainly take some time, but I'm guessing we're not in a rush.

On Sun, Sep 3, 2023, at 6:03 PM, Philip Kaludercic wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> >> Of course, it would be even better if you and your co-maintainers could
> >> be convinced to distribute clojure-mode along with Emacs (again, this
> >> doesn't mean development must be moved away from GitHub), but just like
> >> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
> >> synchronised with the core.  But IIUC, your main issues is the copyright
> >> assignment and the concern that it might limit who might contribute,
> >> right?
> >
> > Other than the contributor agreement there's development overhead to consider:
> >
> > - where are issues reported? I don't want to use the Emacs issue
> > tracker, but that'd be unavoidable for something built-in, so instead
> > of having one issue tracker you end up with two (one of which I really
> > dislike)
> > - some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the clojure-mode maintainers would be willing to deal with this
> > - discussions related to problems/ideas would be happening in different places
> 
> To my knowledge, this is not an issue with the packages I have
> mentioned.  Of course there are exceptions, but to my knowledge
> basically all conversation about org-mode happens on their mailing
> lists, basically all conversation about the modus themes, happen on
> Prot's mailing list/issue trackers.
> 
> > - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync
> 
> This is a minor point, IMO, and if it is relevant, it will usually be
> because of a downstream change that should be upstreamed anyway
> (e.g. someone replaced all occurrences of an inefficient construct, and
> happens to do so in clojure-mode as well).
> 
> > I can go on and on about this - hybrid development models simply come
> > with a lot of overhead. 
> 
> The mistake I want to emphasise here is that this is not a "hybrid
> development model".  Development continues on your own terms, and just
> gets copied over into emacs.git on a regular basis.
> 
> >                         I get that here many people think that GitHub
> > is the root of all evil, but political preferences aside - it's the
> > largest forge in the world by a huge margin and I think it provides
> > unique benefits to projects that can't be replicated elsewhere. At
> > least not today.
> 
> While I disagree, especially with GitHubs recent 2FA push, IIUC I just
> want to clarify that this is not what is being discussed.
> 
> Other than these points, is the CA the only major issue.  Or to put it
> differently, if you could state the conditions for clojure-mode to be
> distributed with Emacs, what would your conditions be?  My point here is
> just to clarify if there is a solution to this discussion -- in which
> case I think it is worth continuing it -- of if you /want to not want
> to/ have clojure-mode added to core Emacs?
> 
> >
> > On Sun, Sep 3, 2023, at 5:19 PM, Philip Kaludercic wrote:
> >> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> >> 
> >> >> I would guess that anyone who is seriously interested in working with
> >> >> Clojure, would install the proper major mode and the proper package
> >> >
> >> > That's one of the things that bother me the most in the conversations
> >> > so far - lots of people tell us what the Clojure users need, but other
> >> > than me and Danny, no one here has any real interest in Clojure. :-)
> >> > Without an understanding of Clojure and its tooling ecosystem (and
> >> > it's history) it's hard to make good suggestions about what makes
> >> > sense and what doesn't.
> >> 
> >> This suggestion comes from a different point of view, namely that if I
> >> open a clojure file, that I have anything else but fundamental mode to
> >> structure the file.  And if it is true that LSP integration could
> >> provide xref, imenu, capf, etc. support, one would come a long way for
> >> modest needs with very little code.  Just like with the common-lisp
> >> mode, the support is of course better if you install SLIME or Sly, but
> >> having some basic OOTB support is already a good thing and all this
> >> thread started out with.
> >> 
> >> Of course, it would be even better if you and your co-maintainers could
> >> be convinced to distribute clojure-mode along with Emacs (again, this
> >> doesn't mean development must be moved away from GitHub), but just like
> >> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
> >> synchronised with the core.  But IIUC, your main issues is the copyright
> >> assignment and the concern that it might limit who might contribute,
> >> right?
> >> 
> >> > I already wrote we tried the "thin layer on top of lisp-mode" and this
> >> > didn't worked out great in the past. Of course, people are welcome to
> >> > try and learn from experience themselves if they thing they can do
> >> > things better/differently.
> >> >
> >> > On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
> >> >> João Távora <joaotavora@gmail.com> writes:
> >> >> 
> >> >> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
> >> >> >>
> >> >> >> 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
> >> >> >
> >> >> > I don't know if this counts as "work on that" but here's two interesting lines
> >> >> > Elisp:
> >> >> >
> >> >> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> >> >> > "Barebones Clojure")
> >> >> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
> >> >> 
> >> >> I suggested something along these lines up the thread, but didn't try it
> >> >> out myself.  Nice to see that the idea works.  To avoid confusion, I
> >> >> think it might be a good idea to not call this `clojure-mode' as well,
> >> >> but something like "clojure-proto-mode" or "primitive-clojure-mode".
> >> >> 
> >> >> > Since it is a lisp dialect many things works here, like indentation,
> >> >> > symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
> >> >> >
> >> >> > And then there's LSP, right?
> >> >> >
> >> >> > So I installed clojure-lsp from here:
> >> >> > https://aur.archlinux.org/packages/clojure-lsp-bin
> >> >> >
> >> >> > I created a hello world project with the "lein" tool, git init, found the
> >> >> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> >> >> > at-point-documentation, diagnostics, lots of refactorings, completion, etc.
> >> >> >
> >> >> > The thing that's a bit minimal is the syntax highlighting, but it's
> >> >> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> >> >> > highlighting.  I have no idea what it takes to add TreeSitter support
> >> >> > to such a bare-bones mode (but shouldn't it be really easy like mapping
> >> >> > syntactic symbols to faces?)
> >> >> >
> >> >> > No idea if this works with the CIDER or SLIME backends for clojure.
> >> >> > Don't ask me to test any more cause I've just uninstalled it all
> >> >> > but any clojurians rading can have a go.
> >> >> 
> >> >> I would guess that anyone who is seriously interested in working with
> >> >> Clojure, would install the proper major mode and the proper packages.
> >> >> 
> >> >> > João
> >> >> 
> >> >> 
> >> 
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

On Sun, Sep 3, 2023 at 10:06 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:

> If what you said is true (and I guess it is, given that Eli wrote
> more or less the same), then probably the CA will be the main obstacle. I'll need
> to discuss this further with the other members of clojure-emacs, as me and Danny
> are the  only people on emacs-devel to my knowledge. In general - tracking down
> all the contributors and getting them to sign the CA will certainly take
> some time, but I'm guessing we're not in a rush.

If you (and/or Danny) are seriously re-considering your position,
I suggest we start with clojure-ts-mode, and the one single
contributor to it who hasn't signed (at least I couldn't find them
on file).

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Yeah, that's definitely one of the options that we'll consider, when we kick-off the discussion with the other clojure-emacs org members. 

On Mon, Sep 4, 2023, at 12:29 AM, João Távora wrote:
> On Sun, Sep 3, 2023 at 10:06 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> 
> > If what you said is true (and I guess it is, given that Eli wrote
> > more or less the same), then probably the CA will be the main obstacle. I'll need
> > to discuss this further with the other members of clojure-emacs, as me and Danny
> > are the  only people on emacs-devel to my knowledge. In general - tracking down
> > all the contributors and getting them to sign the CA will certainly take
> > some time, but I'm guessing we're not in a rush.
> 
> If you (and/or Danny) are seriously re-considering your position,
> I suggest we start with clojure-ts-mode, and the one single
> contributor to it who hasn't signed (at least I couldn't find them
> on file).
> 
> João
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 17:37:07 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: João Távora <joaotavora@gmail.com>,
>  "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>,
>  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> - where are issues reported? I don't want to use the Emacs issue tracker, but that'd be unavoidable
> for something built-in, so instead of having one issue tracker you end up with two (one of which I
> really dislike)

There's no requirement to use debbugs for your package, even if it is
in core.  Org, for example, doesn't.  When people submit bug reports
about Org to debbugs, we redirect them to the Org list.

> - some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the
> clojure-mode maintainers would be willing to deal with this

Same here: there's no requirement to have patches submitted directly
to us.  Quite the contrary: as long as you and your colleagues
actively develop and maintain the package, we'd prefer that patches
are first reviewed by you.

> - discussions related to problems/ideas would be happening in different places

Again, not a requirement.  But yes, the developers should be available
on emacs-devel, because issues could pop up here.  You could have a
representative, though, not all of you.

> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync

Ihor and others should correct me, but what overhead do you have in
mind?  We already have a few packages that are basically developed
outside of Emacs and only merged with Emacs from time to time, so you
will not be the first package to go that way.

> I can go on and on about this - hybrid development models simply come with a lot of overhead. I get
> that here many people think that GitHub is the root of all evil, but political preferences aside - it's the
> largest forge in the world by a huge margin and I think it provides unique benefits to projects that
> can't be replicated elsewhere. At least not today. 

I think the difficulties are not as great as you imagine.  And our
opinions about GitHub are not relevant if the package is regularly
merged into emacs.git.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

That's good to hear and it sounds fairly reasonable to me. I'm guessing that the hardest part will be getting everyone to sign the CA, as there were quite a few contributors over the years. (and ideally we'll need some simple way to get new contributors to sign the CA - I'm not sure what's the process these days)  

One more thing that came to mind is how are we going to deal with updates of package that happen between Emacs major releases. I'm guessing that clojure-mode should also be available on GNU ELPA, so users can update to the latest version, right? 

If you don't mind - I'd like to ask to put the topic on hold for a bit here, so I can discuss it properly with the other members of clojure-emacs and hear how they feel about it. If you truly believe that it'd be important to include clojure-mode in Emacs we'll consider this carefully. I hope you'll agree that's not super time sensitive and there's no need to make hasty decisions. 

Despite the unpleasant tone of the conversation at times, I'm trying to keep an open mind here and I appreciate everyone who has provided some constructive opinions to the discussion. 

On Sun, Sep 3, 2023, at 6:07 PM, Eli Zaretskii wrote:
> > Date: Sun, 03 Sep 2023 17:37:07 +0200
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: João Távora <joaotavora@gmail.com>,
> >  "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>,
> >  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
> >  "Manuel Uberti" <manuel.uberti@inventati.org>
> > 
> > - where are issues reported? I don't want to use the Emacs issue tracker, but that'd be unavoidable
> > for something built-in, so instead of having one issue tracker you end up with two (one of which I
> > really dislike)
> 
> There's no requirement to use debbugs for your package, even if it is
> in core.  Org, for example, doesn't.  When people submit bug reports
> about Org to debbugs, we redirect them to the Org list.
> 
> > - some patches will be submitted on GitHub, some on emacs-devel - I highly doubt that all the
> > clojure-mode maintainers would be willing to deal with this
> 
> Same here: there's no requirement to have patches submitted directly
> to us.  Quite the contrary: as long as you and your colleagues
> actively develop and maintain the package, we'd prefer that patches
> are first reviewed by you.
> 
> > - discussions related to problems/ideas would be happening in different places
> 
> Again, not a requirement.  But yes, the developers should be available
> on emacs-devel, because issues could pop up here.  You could have a
> representative, though, not all of you.
> 
> > - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync
> 
> Ihor and others should correct me, but what overhead do you have in
> mind?  We already have a few packages that are basically developed
> outside of Emacs and only merged with Emacs from time to time, so you
> will not be the first package to go that way.
> 
> > I can go on and on about this - hybrid development models simply come with a lot of overhead. I get
> > that here many people think that GitHub is the root of all evil, but political preferences aside - it's the
> > largest forge in the world by a huge margin and I think it provides unique benefits to projects that
> > can't be replicated elsewhere. At least not today. 
> 
> I think the difficulties are not as great as you imagine.  And our
> opinions about GitHub are not relevant if the package is regularly
> merged into emacs.git.
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> That's good to hear and it sounds fairly reasonable to me. I'm
> guessing that the hardest part will be getting everyone to sign the
> CA, as there were quite a few contributors over the years. (and
> ideally we'll need some simple way to get new contributors to sign the
> CA - I'm not sure what's the process these days)

The process is that you fill out a form, email assign@gnu.org with those
details, and they will let you know the next steps.  IIUC it normally
just involves a PDF to print, sign, and send back.

You can see how John Wiegley collected assignments for use-package here:

    https://github.com/jwiegley/use-package/issues/282

One key point is that it can be done over time.  I don't know if it
makes sense, but perhaps `clojure-ts-mode' could be considered
separately from `clojure-mode', such that one is merged before the
other.

> I'm guessing that clojure-mode should also be available on GNU ELPA,
> so users can update to the latest version, right?

Yes, that is correct.  It can be set up in one of two ways.

1. A package bundled with Emacs is what we call a :core package.

2. A "regular" GNU ELPA package, not bundled with Emacs.  Normally
   changes are automatically pulled from the package repository.

In both cases, the GNU ELPA scripts will automatically detect when the
"Version:" comment header is updated, and release a new version based on
that commit.  If `clojure-mode' is bundled with Emacs (option 1), this
means that you merge your changes into emacs.git, with the new "Version"
header, to release a new version.  If it is not bundled with Emacs
(option 2), you would simply push to your repository.

> If you don't mind - I'd like to ask to put the topic on hold for a bit
> here, so I can discuss it properly with the other members of
> clojure-emacs and hear how they feel about it. If you truly believe
> that it'd be important to include clojure-mode in Emacs we'll consider
> this carefully. I hope you'll agree that's not super time sensitive
> and there's no need to make hasty decisions.

This is sensible, and we will accept, of course.  There is no rush at
all, so take the time you need.

Feel free to ask if any questions come up in the course of your
discussions.  You can write either to the list, or directly to Eli and
me.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Feel free to ask if any questions come up in the course of your
> discussions.  You can write either to the list, or directly to Eli and
> me.

Thanks for all the info! Much appreciated!

> One key point is that it can be done over time.  I don't know if it
> makes sense, but perhaps `clojure-ts-mode' could be considered
> separately from `clojure-mode', such that one is merged before the
> other.

We'll ponder over this potential path as well. 

On Mon, Sep 4, 2023, at 1:36 AM, Stefan Kangas wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > That's good to hear and it sounds fairly reasonable to me. I'm
> > guessing that the hardest part will be getting everyone to sign the
> > CA, as there were quite a few contributors over the years. (and
> > ideally we'll need some simple way to get new contributors to sign the
> > CA - I'm not sure what's the process these days)
> 
> The process is that you fill out a form, email assign@gnu.org with those
> details, and they will let you know the next steps.  IIUC it normally
> just involves a PDF to print, sign, and send back.
> 
> You can see how John Wiegley collected assignments for use-package here:
> 
>     https://github.com/jwiegley/use-package/issues/282
> 
> One key point is that it can be done over time.  I don't know if it
> makes sense, but perhaps `clojure-ts-mode' could be considered
> separately from `clojure-mode', such that one is merged before the
> other.
> 
> > I'm guessing that clojure-mode should also be available on GNU ELPA,
> > so users can update to the latest version, right?
> 
> Yes, that is correct.  It can be set up in one of two ways.
> 
> 1. A package bundled with Emacs is what we call a :core package.
> 
> 2. A "regular" GNU ELPA package, not bundled with Emacs.  Normally
>    changes are automatically pulled from the package repository.
> 
> In both cases, the GNU ELPA scripts will automatically detect when the
> "Version:" comment header is updated, and release a new version based on
> that commit.  If `clojure-mode' is bundled with Emacs (option 1), this
> means that you merge your changes into emacs.git, with the new "Version"
> header, to release a new version.  If it is not bundled with Emacs
> (option 2), you would simply push to your repository.
> 
> > If you don't mind - I'd like to ask to put the topic on hold for a bit
> > here, so I can discuss it properly with the other members of
> > clojure-emacs and hear how they feel about it. If you truly believe
> > that it'd be important to include clojure-mode in Emacs we'll consider
> > this carefully. I hope you'll agree that's not super time sensitive
> > and there's no need to make hasty decisions.
> 
> This is sensible, and we will accept, of course.  There is no rush at
> all, so take the time you need.
> 
> Feel free to ask if any questions come up in the course of your
> discussions.  You can write either to the list, or directly to Eli and
> me.
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 22:59:46 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Philip Kaludercic" <philipk@posteo.net>,
>  João Távora <joaotavora@gmail.com>,
>  "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>,
>  "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> That's good to hear and it sounds fairly reasonable to me. I'm guessing that the hardest part will be
> getting everyone to sign the CA, as there were quite a few contributors over the years. (and ideally
> we'll need some simple way to get new contributors to sign the CA - I'm not sure what's the process
> these days)  

The process is to ask contributors to sign the CA if their
contribution exceeds 15 lines of non-trivial code.

> One more thing that came to mind is how are we going to deal with updates of package that happen
> between Emacs major releases. I'm guessing that clojure-mode should also be available on GNU
> ELPA, so users can update to the latest version, right? 

Yes.

> If you don't mind - I'd like to ask to put the topic on hold for a bit here, so I can discuss it properly with
> the other members of clojure-emacs and hear how they feel about it. If you truly believe that it'd be
> important to include clojure-mode in Emacs we'll consider this carefully. I hope you'll agree that's not
> super time sensitive and there's no need to make hasty decisions. 

Sure, take your time, and thanks.

> Despite the unpleasant tone of the conversation at times, I'm trying to keep an open mind here and I
> appreciate everyone who has provided some constructive opinions to the discussion. 

Thank you.

Re: Brand new clojure support in Emacs ;-)

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync
>
> Ihor and others should correct me, but what overhead do you have in
> mind?  We already have a few packages that are basically developed
> outside of Emacs and only merged with Emacs from time to time, so you
> will not be the first package to go that way.

Backporting upstream commits might be slightly more manual compared to
applying patches specifically submitted for Org. Otherwise, no downside
- you are getting code improvements from Elisp experts behind Emacs
after all :) For example, AFAIR, we got conversion to lexical binding
largely contributed by Emacs devs.

More details in https://orgmode.org/worg/org-maintenance.html#emacs-sync

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Other than the contributor agreement there's development overhead to consider:

Thanks, I found your list of concerns interesting.

> - where are issues reported? I don't want to use the Emacs issue
> tracker, but that'd be unavoidable for something built-in, so instead
> of having one issue tracker you end up with two (one of which I really
> dislike)
> - some patches will be submitted on GitHub, some on emacs-devel - I
> highly doubt that all the clojure-mode maintainers would be willing to
> deal with this

These concerns are valid, but disproportionate.

Most users will not want to send email, and are a million times more
likely to go to GitHub and follow the workflow they are used to there.

With a package like Org-mode, we only have the occasional bug come to
the bug list or emacs-devel, and in short order someone will point them
in the right direction.  But users normally follow the instructions
given to them by the org developers, and send it directly to their list.

Even with use-package, a package that was merged into core and where we
plan to deprecate and eventually archive the GitHub page, more
discussion, issues, and even PRs end up on GitHub.

Basically, the position is that for GNU ELPA packages, we *accept* bugs
in the bug tracker, but we don't necessarily encourage it.  From our
point of view, we are usually much happier if the bugs go to the
maintainers directly, as they are in the best position to resolve them.

> - discussions related to problems/ideas would be happening in
> different places

This will only very occasionally be true, but mostly it will be as
above: expect 99 % of relevant discussions in your preferred forum.

The exceptions will be, for the most part, when Emacs developers need to
ask you something over email, or point some wayward users in your
direction.

> - there's also so overhead of keeping the GitHub repo and the code in Emacs in sync

That's true.  In practice, you could do this one or two times a year, or
even once before every release, and nothing bad would happen.

Some packages merge much less frequently too, but that's not ideal for
obvious reasons.

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 17:04:32 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>, 
>  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> Without an understanding of Clojure and its tooling ecosystem (and it's history) it's hard to
> make good suggestions about what makes sense and what doesn't. 

I disagree with this assertion, and disagree in general, not just
specifically wrt clojure-mode.  One of the important jobs of an Emacs
maintainer is to understand enough about any candidate feature to make
this kind of decisions, without being an expert in its subject matter.
Maybe I'm doing my job not well enough, but you seem to be saying that
this job is impossible to do, and that the only people who can make
good decisions about this are the experts on the subject matter.  That
is certainly incorrect.

It doesn't take a genius to realize that Clojure is an important
programming language, and the way to the decision of having it
supported OOTB in Emacs is very short from there.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Here I was making the point that it's hard to say what'd be a good enough Clojure mode for Emacs unless you actually a subject expert in Clojure. (or at least reasonable familiar with Clojure) This was a response to the statement that simply deriving from lisp-mode would be good enough. Sorry if I didn't make this clear. 

The topic of whether Clojure support should be included OOTB is completely orthogonal to this IMO. 

On Sun, Sep 3, 2023, at 5:42 PM, Eli Zaretskii wrote:
> > Date: Sun, 03 Sep 2023 17:04:32 +0200
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: "Richard Stallman" <rms@gnu.org>, "Danny Freeman" <danny@dfreeman.email>, 
> >  "Eli Zaretskii" <eliz@gnu.org>, "Emacs Devel" <emacs-devel@gnu.org>,
> >  "Manuel Uberti" <manuel.uberti@inventati.org>
> > 
> > Without an understanding of Clojure and its tooling ecosystem (and it's history) it's hard to
> > make good suggestions about what makes sense and what doesn't. 
> 
> I disagree with this assertion, and disagree in general, not just
> specifically wrt clojure-mode.  One of the important jobs of an Emacs
> maintainer is to understand enough about any candidate feature to make
> this kind of decisions, without being an expert in its subject matter.
> Maybe I'm doing my job not well enough, but you seem to be saying that
> this job is impossible to do, and that the only people who can make
> good decisions about this are the experts on the subject matter.  That
> is certainly incorrect.
> 
> It doesn't take a genius to realize that Clojure is an important
> programming language, and the way to the decision of having it
> supported OOTB in Emacs is very short from there.
> 

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

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

  > That's one of the things that bother me the most in the
  > conversations so far - lots of people tell us what the Clojure
  > users need, but other than me and Danny, no one here has any real
  > interest in Clojure.

I have never read a real program in Clojure, and I don't know enough
to try to write one.  So I wouldn't try to say _anything_ about the
specifics of how Clojure mode should behave.  I leave that to the
people who kmow something about the language and have a basis to have
sensible opinions.

The issues where I say something are those that affect uniformity and
coherence of Emacs interfaces.  I know about these points so I can say
that some proposed interface has a problem.

I wouldn't want to propose specific alternatives on my own, though,
because doing that calls for the Clojure knowledge that I don't have.
I would not be confident that my ideas for this would work well.  But
I could propose general avenues to try, or points for Clojure experts
to think about.  With my understanding of general Emacs issus, and
their understanding of Clojure needs, we could come up with good
solutions to problems of this kind.

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

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

What you're doing seems like a start at what I hope to have in Emacs.
Thank you for working on it.

However, since I have never used Clojure, I can't tell how much would
remain to be done.  Also, I don't recognize the names of various
packages you used, so I don't know what they do.  More crucially, for
most of them I can't tell whether they are part of Emacs or not.
(They might be in NonGNU ELPA, or not connected with Emacs at all.)
Those questions would determine whether we could include this in
Emacs.

Could you please describe that status?

By the way, everyone, I never intended to try to convince the
developers of Closure mode to contribute that to Emacs.  I started
this discussion because I was told they were unwilling to do that,
and it seemed their decision was firm.  I saw no point in trying to
convince people whose minds were made up.  It would do no good.

Though I never tried to convince them, people assumed I was trying to,
and argued with me for that in a rather aggressive tone.  I hope this
is clear now.

Instead of that, I thought about what WE, the Emacs developers, should
do, given the situation which existed.  And that's still what I am
thinking about.

What the Closure mode developers are willng to do is one factor in
that decision, because it is part of the objective situation.  But
they have chosen not to be part of GNU Emacs as a project.  They don't
think in terms of what is best for Emacs, and they don't have to, but
that is what Emacs decisions should be based on.

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

Re: Brand new clojure support in Emacs ;-)

[Dmitry Gutov]

On 01/09/2023 04:16, Richard Stallman wrote:
> They don't
> think in terms of what is best for Emacs

What if they do?

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 04:34:46 +0300
> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 04:16, Richard Stallman wrote:
> > They don't
> > think in terms of what is best for Emacs
> 
> What if they do?

If they did, they would have agreed with us, or at least said they'd
like to.

Re: Brand new clojure support in Emacs ;-)

[Dmitry Gutov]

On 01/09/2023 09:44, Eli Zaretskii wrote:
>> Date: Fri, 1 Sep 2023 04:34:46 +0300
>> Cc:emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> On 01/09/2023 04:16, Richard Stallman wrote:
>>> They don't
>>> think in terms of what is best for Emacs
>> What if they do?
> If they did, they would have agreed with us, or at least said they'd
> like to.

But we don't always agree between ourselves. Not on this subject anyway.

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 12:14:21 +0300
> Cc: rms@gnu.org, joaotavora@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 09:44, Eli Zaretskii wrote:
> >> Date: Fri, 1 Sep 2023 04:34:46 +0300
> >> Cc:emacs-devel@gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> On 01/09/2023 04:16, Richard Stallman wrote:
> >>> They don't
> >>> think in terms of what is best for Emacs
> >> What if they do?
> > If they did, they would have agreed with us, or at least said they'd
> > like to.
> 
> But we don't always agree between ourselves. Not on this subject anyway.

Those disagreements are not relevant when the issue is the inclusion
of a package in core.

Re: Brand new clojure support in Emacs ;-)

[Danny Freeman]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Fri, 1 Sep 2023 12:14:21 +0300
>> Cc: rms@gnu.org, joaotavora@gmail.com, emacs-devel@gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> But we don't always agree between ourselves. Not on this subject anyway.
>
> Those disagreements are not relevant when the issue is the inclusion
> of a package in core.

I'd like to think I have the best interests of Emacs at heart, both as
someone who has contributed a handful bug fixes to the core, as a
clojure developer in my day job, and as the maintainer of
clojure-ts-mode.

With that in mind, I won't stand in the way of a new clojure editing
mode for Emacs, in fact I suggested enabling lisp mode for clojure files
somewhere else in this thread. However, I will advocate for not
hijacking the name clojure-mode that has been in active use for 15
years.

There are a lot of users of clojure-mode, and there is no telling how a
builtin mode with the same name might break people's configurations and
workflows. Not to mention what it would do to the various packages that
(require 'clojure-mode), which those same developers use to get their
work done. Philip already made this point, but it is worth re-iterating.

I use clojure-mode and Emacs daily at my work. Nearly every other Emacs
user I have met in real life also uses clojure-mode. I have convinced a
couple of coworkers to abandon proprietary IDEs like intellij in favor
of using Emacs with clojure-mode. Even if it will never be included in
the core it's still a valuable package to Emacs users. IMO the name
clojure-mode should be left as is, and a new name be found for whatever
mode is created as a result of this thread.

-- 
Danny Freeman

Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

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

On Fri, Sep 1, 2023, 9:13 AM Danny Freeman <danny@dfreeman.email> wrote:

>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> Date: Fri, 1 Sep 2023 12:14:21 +0300
> >> Cc: rms@gnu.org, joaotavora@gmail.com, emacs-devel@gnu.org
> >> From: Dmitry Gutov <dmitry@gutov.dev>
> >>
> >> But we don't always agree between ourselves. Not on this subject anyway.
> >
> > Those disagreements are not relevant when the issue is the inclusion
> > of a package in core.
>
> I'd like to think I have the best interests of Emacs at heart, both as
> someone who has contributed a handful bug fixes to the core, as a
> clojure developer in my day job, and as the maintainer of
> clojure-ts-mode.
>
> With that in mind, I won't stand in the way of a new clojure editing
> mode for Emacs, in fact I suggested enabling lisp mode for clojure files
> somewhere else in this thread. However, I will advocate for not
> hijacking the name clojure-mode that has been in active use for 15
> years.


I don't think using the term "hijacking" is productive.  The GNU emacs
developers could well say that using a standard functional name like
"clojure-mode" with no intent to contribute it to the core was the
"hijacking", or perhaps namespace-squatting.  It would be different for
"cider" or another non-standard, nonfunctional name.  It should have been
obvious at the time clojure-mode was originally authored that the name
would have been adopted for a builtin mode if there were going to be one.

Lynn

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

Re: Brand new clojure support in Emacs ;-)

[Danny Freeman]

Lynn Winebarger <owinebar@gmail.com> writes:

> I don't think using the term "hijacking" is productive.

Maybe a better term is "taking over", "co-opting", I don't know. I am
trying to be productive about this.

> The GNU emacs
> developers could well say that using a standard functional name like
> "clojure-mode" with no intent to contribute it to the core was the
> "hijacking", or perhaps namespace-squatting.  It would be different for
> "cider" or another non-standard, nonfunctional name. It should have been
> obvious at the time clojure-mode was originally authored that the name
> would have been adopted for a builtin mode if there were going to be one.

From what I know, the original author is no longer actively involved in
maintaining clojure-mode, so it's hard to speculate about what their
intentions were.

But that is beside the point. I'm not talking about the maintainers of
clojure-mode or their intentions, I'm talking about the users of
clojure-mode, and how taking over the name clojure-mode would affect
them after 15 years of use.

-- 
Danny Freeman

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

That's a pretty disappointing remark, which implies that the Emacs team doesn't really care about having a good collaboration with the authors and maintainers of 3rd party Emacs packages. 

I know that for whatever reason we're now discussing clojure-mode, but there are many other major modes for which one can make exactly the same case (erlang-mode, elixir-mode, haskell-mode, etc). Let's just rush forward and include some stripped down/forked versions of them upstream as well, ignoring the people behind them and their end users (who are bound to face some degree of confusion short term). Adopting such a combative stance across the board would be very harmful for our small community IMO.  

On Fri, Sep 1, 2023, at 3:29 PM, Lynn Winebarger wrote:
> On Fri, Sep 1, 2023, 9:13 AM Danny Freeman <danny@dfreeman.email> wrote:
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> Date: Fri, 1 Sep 2023 12:14:21 +0300
>> >> Cc: rms@gnu.org, joaotavora@gmail.com, emacs-devel@gnu.org
>> >> From: Dmitry Gutov <dmitry@gutov.dev>
>> >> 
>> >> But we don't always agree between ourselves. Not on this subject anyway.
>> >
>> > Those disagreements are not relevant when the issue is the inclusion
>> > of a package in core.
>> 
>> I'd like to think I have the best interests of Emacs at heart, both as
>> someone who has contributed a handful bug fixes to the core, as a
>> clojure developer in my day job, and as the maintainer of
>> clojure-ts-mode.
>> 
>> With that in mind, I won't stand in the way of a new clojure editing
>> mode for Emacs, in fact I suggested enabling lisp mode for clojure files
>> somewhere else in this thread. However, I will advocate for not
>> hijacking the name clojure-mode that has been in active use for 15
>> years.
> 
> I don't think using the term "hijacking" is productive.  The GNU emacs developers could well say that using a standard functional name like "clojure-mode" with no intent to contribute it to the core was the "hijacking", or perhaps namespace-squatting.  It would be different for "cider" or another non-standard, nonfunctional name.  It should have been obvious at the time clojure-mode was originally authored that the name would have been adopted for a builtin mode if there were going to be one.
> 
> Lynn
> 
> 
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 17:15:17 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Dmitry Gutov" <dmitry@gutov.dev>,
>  "Richard Stallman" <rms@gnu.org>,
>  João Távora <joaotavora@gmail.com>,
>  "Emacs Devel" <emacs-devel@gnu.org>
> 
> That's a pretty disappointing remark, which implies that the Emacs team doesn't really care about
> having a good collaboration with the authors and maintainers of 3rd party Emacs packages. 

Not everyone who posts here speaks for the "Emacs team", so please
don't take any random post as an indication of where the project and
its maintainers stand wrt to any particular subject.

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> I don't think using the term "hijacking" is productive.  The GNU
>> emacs developers could well say that using a standard functional name
>> like "clojure-mode" with no intent to contribute it to the core was
>> the "hijacking", or perhaps namespace-squatting.  It would be
>> different for "cider" or another non-standard, nonfunctional name.
>> It should have been obvious at the time clojure-mode was originally
>> authored that the name would have been adopted for a builtin mode if
>> there were going to be one.
>
> That's a pretty disappointing remark, which implies that the Emacs
> team doesn't really care about having a good collaboration with the
> authors and maintainers of 3rd party Emacs packages.

Please do not take everything you see here as the officially sanctioned
position of the Emacs maintainers, GNU, or the core team of developers
as a whole.  That will lead to some serious misunderstandings.

This is a public mailing list, where anyone can say whatever they like.
You don't even need to be subscribed.  Lynn is, I assume, subscribed to
the list and welcome to put forward his views along with everyone else
that follows the rules.  That's all.

Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

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

On Sun, Sep 3, 2023, 11:15 AM Bozhidar Batsov <bozhidar@batsov.dev> wrote:

> That's a pretty disappointing remark, which implies that the Emacs team
> doesn't really care about having a good collaboration with the authors and
> maintainers of 3rd party Emacs packages.
>

I'm an outsider, so you should not regard my view as representative of the
GNU emacs "team", whatever that encompasses.  My interest is primarily in
the extent to which dealing with the employer waiver involved in the
copyright assignment caused your lack of interest in allowing a (presumably
minor) fork to be maintained for use in the core, if no further constraints
were required of the upstream package.  My interest is not in persuading
the GNU project to change its policy, but to see if there is any evidence
of harm to non-profit endeavors like the FSF/GNU project caused by the
ambiguity around the enforceability of assignment clauses in employment
contracts that are not for works created in the course of employment.  Such
evidence might be useful in lobbying law-makers for reform, or
attorneys-general for a broader reading and enforcement of existing laws.


> I know that for whatever reason we're now discussing clojure-mode, but
> there are many other major modes for which one can make exactly the same
> case (erlang-mode, elixir-mode, haskell-mode, etc). Let's just rush forward
> and include some stripped down/forked versions of them upstream as well,
> ignoring the people behind them and their end users (who are bound to face
> some degree of confusion short term). Adopting such a combative stance
> across the board would be very harmful for our small community IMO.
>

I'm not sure what the GNU emacs team will decide is appropriate, but I
think they have been pretty accommodating.  In any case, I don't believe
the GNU project would publish a derivative work of an extant 3rd party
package without the author's consent.  The project's requirement of a clear
copyright assignment, and the assignment's clear assurances regarding the
intent of the author to make the contribution (at the time of the
contribution at least), would make that difficult.

On the other side, I don't believe your labor gives you, or anyone,
proprietary rights to dictate how the GNU emacs team should name libraries
in their project.  Rejecting participation in their development process
*decreases* your influence in the decisions they make.  It would be
perverse to reward someone for rejecting participation by granting them
greater influence.  That's just a generic observation on social
organizations and processes.  Your view on the obligations of etiquette and
goodwill seems asymmetric to me.

What I don't understand is why you (or anyone) publishes software under a
free license and then act aggrieved that someone would make use of the
freedoms the license accords them.  Such developers would seem to prefer a
non-free license that requires contribution back to and acceptance by the
original project.  At least, that's how it seems to me.

Lynn

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Danny Freeman <danny@dfreeman.email> writes:

> With that in mind, I won't stand in the way of a new clojure editing
> mode for Emacs, in fact I suggested enabling lisp mode for clojure files
> somewhere else in this thread. However, I will advocate for not
> hijacking the name clojure-mode that has been in active use for 15
> years.
>
> There are a lot of users of clojure-mode, and there is no telling how a
> builtin mode with the same name might break people's configurations and
> workflows. Not to mention what it would do to the various packages that
> (require 'clojure-mode), which those same developers use to get their
> work done.

I think there is still a fair amount of exaggerated alarm over the
simple issue of Emacs providing a major mode for Clojure in some future
version.  Emacs traditionally provides major modes for every major
programming language.  There is no shred of evidence of any inclination
of the Emacs project to sow chaos in the workflows of Clojure
programmers just for the heck of it.

Of course the naming issue is real, but deciding on it is one of the
very last things to address on and it depends on what the new mode would
be able to do.  So don't put the bulls in front of the carriage.  Not to
mention there is lots of prior-art for technical means to manage
clashing names.  Not only in Emacs, but most everywhere.  For example:
if I ask my system package manager to install "java" I get a number of
possibilities.  None of these options is more "java" than the other.  I
get to choose which one is fits my needs better.  Symlinks to
executables and libraries get setup appropriately, etc.

So, there is no "hijacking" at stake because there isn't (or at least
there shouldn't be) the concept of property or ownership of a name,
especially something as generic as "Clojure mode".  Plus, what matters
to Clojure programmers generally isn't the really the NonGNU provenance
of their daily working tools.  If anything, I've seen evidence of the
contrary, witnessing some users switch to Emacs's core facilities even
if they are _less_ featureful than third-party alternatives, _precisely_
because they trust the Emacs project's stability and longevity.  I've
seen this with Flymake and most recently with Eglot.

What _really_ matters to users is what they can do with their Clojure
tools.

With that in mind, and since you sincerely state you want to move this
discussion in a productive direction, what are -- in your opinion -- the
5 most important features supported by the the NonGNU Clojure mode and
the brand new NonGNU Clojure TreeSitter mode?  As a Clojure programmer,
do you personally use LSP?  What are the LSP and nonLSP commands you
find yourself invoking most often.  Can you say if CIDER is prepared to
work with major modes other than the NonGNU Clojure mode?

Thanks,
João

Re: Brand new clojure support in Emacs ;-)

[Danny Freeman]

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

> I think there is still a fair amount of exaggerated alarm over the
> simple issue of Emacs providing a major mode for Clojure in some future
> version.  Emacs traditionally provides major modes for every major
> programming language.  There is no shred of evidence of any inclination
> of the Emacs project to sow chaos in the workflows of Clojure
> programmers just for the heck of it.
>
> Of course the naming issue is real,

Yes, I'm glad to see you acknowledge this as an issue. The naming issue
is all I'm trying to speak to right now.

> but deciding on it is one of the
> very last things to address on and it depends on what the new mode would
> be able to do.  So don't put the bulls in front of the carriage.  Not to
> mention there is lots of prior-art for technical means to manage
> clashing names.  Not only in Emacs, but most everywhere.  For example:
> if I ask my system package manager to install "java" I get a number of
> possibilities.  None of these options is more "java" than the other.  I
> get to choose which one is fits my needs better.  Symlinks to
> executables and libraries get setup appropriately, etc.

Avoiding name collisions is a great and simple way to deal with this.

> So, there is no "hijacking" at stake because there isn't (or at least
> there shouldn't be) the concept of property or ownership of a name,
> especially something as generic as "Clojure mode".  Plus, what matters
> to Clojure programmers generally isn't the really the NonGNU provenance
> of their daily working tools.  If anything, I've seen evidence of the
> contrary, witnessing some users switch to Emacs's core facilities even
> if they are _less_ featureful than third-party alternatives, _precisely_
> because they trust the Emacs project's stability and longevity.  I've
> seen this with Flymake and most recently with Eglot.

I too have witnessed this recently with Eglot, but only with respect to
switching from lsp-mode, not using Eglot and flymake as a substitute for
CIDER, of which there is some overlap in functionality, but both have
features the other does not offer. CIDER is still the killer feature
that draws clojure programmers to Emacs.

> What _really_ matters to users is what they can do with their Clojure
> tools.
>
> With that in mind, and since you sincerely state you want to move this
> discussion in a productive direction, what are -- in your opinion -- the
> 5 most important features supported by the the NonGNU Clojure mode and
> the brand new NonGNU Clojure TreeSitter mode?

In no particular order:
- Clojure-mode has built in refactoring tools, not all of which exist in
  clojure-lsp (to the best of my knowledge).
- Clojure-mode provides an API for tools like CIDER and inf-clojure to
  interact with clojure buffers.
- Clojure-mode integrates with CIDER to allow clojure macros and
  functions to define indentation rules as part of their metadata. I'm
  not sure if it will even be possible for clojure-ts-mode to do this.

The rest would be run-of-the-mill major mode stuff. The real value of
clojure-mode lies in it's integration with CIDER and to a lesser extent
inf-clojure.

There is nothing very special about clojure-ts-mode that I develop right
now. It is a work in progress and far from finished. It's not even quite
to the point where I can dogfood it at work yet. A long term goal is to
provide everything clojure-mode provides for CIDER with clojure-ts-mode.

> As a Clojure programmer,
> do you personally use LSP?  What are the LSP and nonLSP commands you
> find yourself invoking most often.

Yes, I am a happy user of Eglot and clojure-lsp, a refugee from
lsp-mode that you spoke of above. I mainly use it for
- xref navigation
- eldoc integration
- flymake error reporting
- renaming symbols

It's a very nice experience and pairs well with CIDER, especially when I
don't feel like starting up a repl. As you may remember, I also wrote
the jarchive package to integrate with Eglot for navigating to sources
outside of an existing clojure project. I use jarchive every day.

Non LSP commands I find myself invoking a lot are

- A large array of CIDER repl evaluation commands.
- CIDER documentation commands, which have different contents than those
  provided by clojure-lsp. They are both useful in their own ways.
- The CIDER inspector, almost an application in and of itself which is
  used for examining clojure data.
- The CIDER debugger. It is hands down one of the best debuggers I have
  used. Better than the other de-factor clojure development experience
  offered by the proprietary intellij IDE.
- CIDER test commands (i.e. run tests that exercise the current function
  at point, or current namespace, or last failed test)
- Clojure error examination - clojure is notorious for it's hard to
  understand error messages, cider or clojure mode, not sure which,
  provides a mode for interacting with errors that makes them easier to
  reason about.

> Can you say if CIDER is prepared to
> work with major modes other than the NonGNU Clojure mode?

No I cannot, as I am not a CIDER developer. There is a large overlap
between clojure-mode and CIDER developers though. I can guess that using
the name "clojure-mode" for whatever you land on here will make them
less open to working with a built in mode. Again, I don't speak for
them, but I think this is a good guess.

--  
Danny Freeman

Re: Brand new clojure support in Emacs ;-)

[Yuan Fu]

> On Sep 1, 2023, at 8:53 AM, Danny Freeman <danny@dfreeman.email> wrote:
> 
> 
> João Távora <joaotavora@gmail.com> writes:
> 
>> I think there is still a fair amount of exaggerated alarm over the
>> simple issue of Emacs providing a major mode for Clojure in some future
>> version.  Emacs traditionally provides major modes for every major
>> programming language.  There is no shred of evidence of any inclination
>> of the Emacs project to sow chaos in the workflows of Clojure
>> programmers just for the heck of it.
>> 
>> Of course the naming issue is real,
> 
> Yes, I'm glad to see you acknowledge this as an issue. The naming issue
> is all I'm trying to speak to right now.

From a nontechnical side, taking over a package name that has been around for 15 years, is very popular, is depended by thousands of Emacs users, would leave a bad taste is the mouth for clojure-mode developers and users. And it certainly wouldn’t help with the reputation of Emacs developers being hard to approach.

I don’t get the technical advantage of taking over the name either. For a basic better-than-nothing default mode, the user probably won’t even notice its name—the major mode just starts when one opens a Clojure file. And serious Clojure developers will just install Clojure-mode and CIDER instead.

> 
>> but deciding on it is one of the
>> very last things to address on and it depends on what the new mode would
>> be able to do.  So don't put the bulls in front of the carriage.  Not to
>> mention there is lots of prior-art for technical means to manage
>> clashing names.  Not only in Emacs, but most everywhere.  For example:
>> if I ask my system package manager to install "java" I get a number of
>> possibilities.  None of these options is more "java" than the other.  I
>> get to choose which one is fits my needs better.  Symlinks to
>> executables and libraries get setup appropriately, etc.
> 
> Avoiding name collisions is a great and simple way to deal with this.
> 
>> So, there is no "hijacking" at stake because there isn't (or at least
>> there shouldn't be) the concept of property or ownership of a name,
>> especially something as generic as "Clojure mode".  Plus, what matters
>> to Clojure programmers generally isn't the really the NonGNU provenance
>> of their daily working tools.  If anything, I've seen evidence of the
>> contrary, witnessing some users switch to Emacs's core facilities even
>> if they are _less_ featureful than third-party alternatives, _precisely_
>> because they trust the Emacs project's stability and longevity.  I've
>> seen this with Flymake and most recently with Eglot.
> 
> I too have witnessed this recently with Eglot, but only with respect to
> switching from lsp-mode, not using Eglot and flymake as a substitute for
> CIDER, of which there is some overlap in functionality, but both have
> features the other does not offer. CIDER is still the killer feature
> that draws clojure programmers to Emacs.
> 
>> What _really_ matters to users is what they can do with their Clojure
>> tools.
>> 
>> With that in mind, and since you sincerely state you want to move this
>> discussion in a productive direction, what are -- in your opinion -- the
>> 5 most important features supported by the the NonGNU Clojure mode and
>> the brand new NonGNU Clojure TreeSitter mode?
> 
> In no particular order:
> - Clojure-mode has built in refactoring tools, not all of which exist in
>  clojure-lsp (to the best of my knowledge).
> - Clojure-mode provides an API for tools like CIDER and inf-clojure to
>  interact with clojure buffers.
> - Clojure-mode integrates with CIDER to allow clojure macros and
>  functions to define indentation rules as part of their metadata. I'm
>  not sure if it will even be possible for clojure-ts-mode to do this.
> 
> The rest would be run-of-the-mill major mode stuff. The real value of
> clojure-mode lies in it's integration with CIDER and to a lesser extent
> inf-clojure.
> 
> There is nothing very special about clojure-ts-mode that I develop right
> now. It is a work in progress and far from finished. It's not even quite
> to the point where I can dogfood it at work yet. A long term goal is to
> provide everything clojure-mode provides for CIDER with clojure-ts-mode.
> 
>> As a Clojure programmer,
>> do you personally use LSP?  What are the LSP and nonLSP commands you
>> find yourself invoking most often.
> 
> Yes, I am a happy user of Eglot and clojure-lsp, a refugee from
> lsp-mode that you spoke of above. I mainly use it for
> - xref navigation
> - eldoc integration
> - flymake error reporting
> - renaming symbols
> 
> It's a very nice experience and pairs well with CIDER, especially when I
> don't feel like starting up a repl. As you may remember, I also wrote
> the jarchive package to integrate with Eglot for navigating to sources
> outside of an existing clojure project. I use jarchive every day.
> 
> Non LSP commands I find myself invoking a lot are
> 
> - A large array of CIDER repl evaluation commands.
> - CIDER documentation commands, which have different contents than those
>  provided by clojure-lsp. They are both useful in their own ways.
> - The CIDER inspector, almost an application in and of itself which is
>  used for examining clojure data.
> - The CIDER debugger. It is hands down one of the best debuggers I have
>  used. Better than the other de-factor clojure development experience
>  offered by the proprietary intellij IDE.
> - CIDER test commands (i.e. run tests that exercise the current function
>  at point, or current namespace, or last failed test)
> - Clojure error examination - clojure is notorious for it's hard to
>  understand error messages, cider or clojure mode, not sure which,
>  provides a mode for interacting with errors that makes them easier to
>  reason about.
> 
>> Can you say if CIDER is prepared to
>> work with major modes other than the NonGNU Clojure mode?
> 
> No I cannot, as I am not a CIDER developer. There is a large overlap
> between clojure-mode and CIDER developers though. I can guess that using
> the name "clojure-mode" for whatever you land on here will make them
> less open to working with a built in mode. Again, I don't speak for
> them, but I think this is a good guess.
> 
> --  
> Danny Freeman
> 

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Fri, 1 Sep 2023 10:10:27 -0700
> Cc: João Távora <joaotavora@gmail.com>,
>  Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dmitry@gutov.dev>,
>  Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> >> Of course the naming issue is real,
> > 
> > Yes, I'm glad to see you acknowledge this as an issue. The naming issue
> > is all I'm trying to speak to right now.
> 
> From a nontechnical side, taking over a package name that has been around for 15 years, is very popular, is depended by thousands of Emacs users, would leave a bad taste is the mouth for clojure-mode developers and users. And it certainly wouldn’t help with the reputation of Emacs developers being hard to approach.

No one who speaks for the project suggested anything like that.  It's
a non-issue.

Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

On Fri, Sep 1, 2023 at 1:30 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Yuan Fu <casouri@gmail.com>
> > Date: Fri, 1 Sep 2023 10:10:27 -0700
> > Cc: João Távora <joaotavora@gmail.com>,
> >  Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dmitry@gutov.dev>,
> >  Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> >
> > >> Of course the naming issue is real,
> > >
> > > Yes, I'm glad to see you acknowledge this as an issue. The naming issue
> > > is all I'm trying to speak to right now.
> >
> > From a nontechnical side, taking over a package name that has been around for 15 years, is very popular, is depended by thousands of Emacs users, would leave a bad taste is the mouth for clojure-mode developers and users. And it certainly wouldn’t help with the reputation of Emacs developers being hard to approach.
>
> No one who speaks for the project suggested anything like that.  It's
> a non-issue.
>
So, does RMS not speak for the project?  Am I misreading his message:
https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
To be clear, I am not advocating anything here other than recognizing
the GNU emacs project's rights to use <language>-mode as a library
name based on that project's use of that naming pattern for 40 years.
I don't think any external party should feel they have trademark-type
rights over such a functional name.

It would be better if there were some policy statement in the emacs or
elisp manual regarding library and package naming practices, though.
Especially with libraries in core being treated as packages by the
built-in package system.

Lynn

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Sun, 3 Sep 2023 12:53:11 -0400
> Cc: Yuan Fu <casouri@gmail.com>, danny@dfreeman.email, joaotavora@gmail.com, 
> 	dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
> 
> > No one who speaks for the project suggested anything like that.  It's
> > a non-issue.
> >
> So, does RMS not speak for the project?

Sometimes he does, sometimes he doesn't.  Like all of us: sometimes we
just express a non-obligatory opinions, sometimes we describe a
decision made for the project as a whole.  There's no one answer; you
need to read the fine print.

> Am I misreading his message:
> https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?

If you think he was saying we will necessarily call our mode
clojure-mode, then yes, I believe you are misreading it.  From where I
stand, Richard was describing a way to avoid a name conflict.

In any case, whatever decision is made (and we didn't yet decide to
have our own mode for Clojure), it will have to be agreed upon by
Stefan and myself.

> It would be better if there were some policy statement in the emacs or
> elisp manual regarding library and package naming practices, though.

Taking into consideration how seriously our recommendations for
package names are followed (yeah, right), I very much doubt that we
should spend time and energy on formulating policy that no one will
follow.  We have much more serious and useful tasks to accomplish,
where we have a much better control on the outcome.

Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

On Sun, Sep 3, 2023 at 1:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Sun, 3 Sep 2023 12:53:11 -0400
> >
> > > No one who speaks for the project suggested anything like that.  It's
> > > a non-issue.
> > >
> > So, does RMS not speak for the project?
>
> Sometimes he does, sometimes he doesn't.  Like all of us: sometimes we
> just express a non-obligatory opinions, sometimes we describe a
> decision made for the project as a whole.  There's no one answer; you
> need to read the fine print.
>
> > Am I misreading his message:
> > https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
>
> If you think he was saying we will necessarily call our mode
> clojure-mode, then yes, I believe you are misreading it.  From where I
> stand, Richard was describing a way to avoid a name conflict.

I was rebutting the phrase "suggested anything like that" above.  I
did not imply that RMS had directed a conclusion, but your original
claim is a very strong one.  If you had said "No one has suggested
that while speaking for the project", maybe that would be accurate.
But it seemed to me RMS was suggesting a broader principle of not
allowing external projects to dictate decisions in GNU projects, so
I'm not really clear that he wasn't speaking for GNU Emacs as part of
that.

Lynn

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Sun, 3 Sep 2023 13:16:40 -0400
> Cc: casouri@gmail.com, danny@dfreeman.email, joaotavora@gmail.com, 
> 	dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
> 
> On Sun, Sep 3, 2023 at 1:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > From: Lynn Winebarger <owinebar@gmail.com>
> > > Date: Sun, 3 Sep 2023 12:53:11 -0400
> > >
> > > > No one who speaks for the project suggested anything like that.  It's
> > > > a non-issue.
> > > >
> > > So, does RMS not speak for the project?
> >
> > Sometimes he does, sometimes he doesn't.  Like all of us: sometimes we
> > just express a non-obligatory opinions, sometimes we describe a
> > decision made for the project as a whole.  There's no one answer; you
> > need to read the fine print.
> >
> > > Am I misreading his message:
> > > https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
> >
> > If you think he was saying we will necessarily call our mode
> > clojure-mode, then yes, I believe you are misreading it.  From where I
> > stand, Richard was describing a way to avoid a name conflict.
> 
> I was rebutting the phrase "suggested anything like that" above.

Why would you?  What good would it make?

Please let Stefan and myself decide the policy in these matters here.
It's what we are here for.  If we happen to disagree with Richard, we
will work with him to solve the disagreement.

> But it seemed to me RMS was suggesting a broader principle of not
> allowing external projects to dictate decisions in GNU projects, so
> I'm not really clear that he wasn't speaking for GNU Emacs as part of
> that.

I happen to agree with Richard on the broader principle, but that
doesn't mean the principle gets automatically applied in any
particular case.

Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

On Sun, Sep 3, 2023 at 1:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Sun, 3 Sep 2023 13:16:40 -0400
> > Cc: casouri@gmail.com, danny@dfreeman.email, joaotavora@gmail.com,
> >       dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
> >
> > On Sun, Sep 3, 2023 at 1:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > From: Lynn Winebarger <owinebar@gmail.com>
> > > > Date: Sun, 3 Sep 2023 12:53:11 -0400
> > > >
> > > > > No one who speaks for the project suggested anything like that.  It's
> > > > > a non-issue.
> > > > >
> > > > So, does RMS not speak for the project?
> > >
> > > Sometimes he does, sometimes he doesn't.  Like all of us: sometimes we
> > > just express a non-obligatory opinions, sometimes we describe a
> > > decision made for the project as a whole.  There's no one answer; you
> > > need to read the fine print.
> > >
> > > > Am I misreading his message:
> > > > https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
> > >
> > > If you think he was saying we will necessarily call our mode
> > > clojure-mode, then yes, I believe you are misreading it.  From where I
> > > stand, Richard was describing a way to avoid a name conflict.
> >
> > I was rebutting the phrase "suggested anything like that" above.
>
> Why would you?  What good would it make?

In a discussion, attempts  to deny observable reality, intentional or
not, demean the ability of the other participants to observe that
reality and make decisions based on that observable reality.  In this
case, discussion participants were (and remain) justifiably confused
about whether the emacs project would or will develop a
library/built-in-package "clojure-mode" independently of the extant
third-party package.
I might be able to write a dissertation on why living by and promotion
of decision-making based on observable reality is a virtue (the
classical term for a "good" as you term it).  A consensus that cannot
withstand the weight of observable reality is no consensus at all.

> Please let Stefan and myself decide the policy in these matters here.
> It's what we are here for.  If we happen to disagree with Richard, we
> will work with him to solve the disagreement.

I fail to see how I am obstructing you from doing so.  You might have
made these assurances in private, worked out the policy disagreement
with Richard in private, then announced the resolution once you had
agreement.  I have no objection to your doing so.  I am not advocating
for one policy, or decision versus any other.  What I am advocating,
and defending, is the right of the rest of us to develop our own
viewpoints based on observable reality.  I don't view attempts to
manage feelings by denying observable facts as virtuous.

Believe me when I say that I am happy you and Stefan and whoever are
doing the work of maintaining the overall project and development
goals.  I am happy to defer to you in these matters.  I certainly have
no interest in doing that work.  But that is the extent of my
deference.

Maybe there is some confusion on my part as to the nature of this
mailing list.  The description says it is for "emacs developers".  It
is not restricted even to "GNU Emacs developers", much less "GNU Emacs
contributors".  My understanding of an "emacs developer" is one who
works on emacs code, whether the C source code or programs written in
emacs lisp.  That makes this mailing list a natural place to look for
advice or feedback from experts in emacs development, or make
announcements, recruit assistance, etc from the pool of people
interested in doing emacs development, whether that work will
ultimately be contributed to the GNU emacs project or not (since I
have seen little evidence that statement can be resolved before the
work is in fact in a contributable state, if for no other reason).
From what I have observed, the meat and potatoes work involved in
coordinating maintenance efforts is done via the bugs email-list and
managed by the bug tracker, so these discussions on emacs-devel are
not in fact disruptive to such activities.

Lynn

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Wed, 6 Sep 2023 09:11:23 -0400
> Cc: casouri@gmail.com, danny@dfreeman.email, joaotavora@gmail.com, 
> 	dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
> 
> > > > > Am I misreading his message:
> > > > > https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
> > > >
> > > > If you think he was saying we will necessarily call our mode
> > > > clojure-mode, then yes, I believe you are misreading it.  From where I
> > > > stand, Richard was describing a way to avoid a name conflict.
> > >
> > > I was rebutting the phrase "suggested anything like that" above.
> >
> > Why would you?  What good would it make?
> 
> In a discussion, attempts  to deny observable reality, intentional or
> not, demean the ability of the other participants to observe that
> reality and make decisions based on that observable reality.

That is completely off the mark.  My point was that you are in effect
"rebutting" _my_ interpretation of what Richard wrote.  That cannot
possibly be useful.

> In this case, discussion participants were (and remain) justifiably
> confused about whether the emacs project would or will develop a
> library/built-in-package "clojure-mode" independently of the extant
> third-party package.

You've heard 3 opinions which are almost identical.  Where there are
some differences (which, together with the heated debate, where not
everyone reads everything and understands completely what is being
said, are probably the source of confusion), they don't yet need to be
reconciled because the decision is not on the table yet.  If and when
it will be, the differences, such as they are, will be resolved, and
there will be no place for any confusion.

> > Please let Stefan and myself decide the policy in these matters here.
> > It's what we are here for.  If we happen to disagree with Richard, we
> > will work with him to solve the disagreement.
> 
> I fail to see how I am obstructing you from doing so.

Your post could be interpreted as hinting on some contradictions
between the views of the 3 involved individuals, and even as an
attempt to exaggerate those contradictions, for whatever reasons.
That is once again not useful and doesn't contribute to kinder, calmer
discussions.  I don't know whether you meant that -- I sincerely hope
you didn't -- but such an interpretation is definitely possible.  So I
hope you will try in the future to avoid saying things that could be
interpreted that way.

> What I am advocating, and defending, is the right of the rest of us
> to develop our own viewpoints based on observable reality.

You and others have every right to your viewpoints, but I urge you to
think hard before you divulge each and every one of these viewpoints
in public.  Where neither Richard nor Stefan nor myself see any
conflict of opinions that needs to be resolved, why would you insist
in public that such a conflict exists (or may exist)?

> Maybe there is some confusion on my part as to the nature of this
> mailing list.  The description says it is for "emacs developers".  It
> is not restricted even to "GNU Emacs developers", much less "GNU Emacs
> contributors".  My understanding of an "emacs developer" is one who
> works on emacs code, whether the C source code or programs written in
> emacs lisp.  That makes this mailing list a natural place to look for
> advice or feedback from experts in emacs development, or make
> announcements, recruit assistance, etc from the pool of people
> interested in doing emacs development, whether that work will
> ultimately be contributed to the GNU emacs project or not (since I
> have seen little evidence that statement can be resolved before the
> work is in fact in a contributable state, if for no other reason).
> >From what I have observed, the meat and potatoes work involved in
> coordinating maintenance efforts is done via the bugs email-list and
> managed by the bug tracker, so these discussions on emacs-devel are
> not in fact disruptive to such activities.

That is completely unrelated to the point I was trying to make.  No
one said that your posts were off-topic, and no one said that you
shouldn't be allowed to post here.  It's a non-issue.  The official
purpose of this list is "for communications between Emacs developers".

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

When I said we should aim to have a Clojure mode that is part of
Emacs, following the naming convention `clojure-mode', that's not a
100% firm and fixed decision, but it's close to that.

I'd like to explain again the reason we have NonGNU ELPA and what
purpose it serves, and its contrast with GNU ELPA.

GNU ELPA packages are part of GNU Emacs.  We deal with them like the
rest of GNU Emacs.  However, they are _distibuted_ differently in a
limited practical sense.  Because the only difference is the matter of
how to distribute them, we can move them between GNU ELPA and core
Emacs based on convenience.

After we had GNU ELPA running, we set up NonGNU ELPA to distribute
packages which are very clearly NOT part of GNU Emacs.  That is what
NonGNU ELPA is for.

That distinction is important legally and in terms of development.  We
don't normally maintain those packages at all -- they are developed by
others and normally we leave that to them (though we ask them to agree
to follow a few limited rules so that they don't cause practical
problems).

NonGNU ELPA is meant for packages that are useful for some Emacs users
but not crucial or important.  That being so, it is fine to leave
those packages to their developers -- even if they don't make the very
best choices, it is no biggie, it is still ok.

There are lots of packages which fit fine in NonGNU ELPA and we are
generally happy to keep them there.  They remain nice add-ons but not
crucial.

However, when a package gets to be _important_ somehow in the context of
Emacs, then it doesn't fit there well any more.  For instance,

* We want to include it in core Emacs so every user has it.

* We want to recommend it specifically to Emacs users.

* We may even want to document it in the Emacs manual.

We must not do this with a NonGNU ELPA package because it is not a
part of Emacs.  We must not treat it as one.  But we might find it
very desirable to have such a package as part of GNU Emacs.  That's a
situation we occasionally get into.

Clojure mode is an example.  We should have a Clojure mode that is
part of GNU Emacs.  It is a problem if we find that path blocked.

There are many packages included in core Emacs, or in GNU ELPA, which
continue to be developed and maintained by a certain group of people.
Occasionally we have a discussion with them about how address some
issue within Emacs.  But they are capable, so most of the issues they
encounter don't require a discussion like that.  They simply solve the
problem.

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

On Sun, Sep 3, 2023 at 5:53 PM Lynn Winebarger <owinebar@gmail.com> wrote:

> To be clear, I am not advocating anything here other than recognizing
> the GNU emacs project's rights to use <language>-mode as a library
> name based on that project's use of that naming pattern for 40 years.
> I don't think any external party should feel they have trademark-type
> rights over such a functional name.

I happen to agree with you exactly on principle here.  But -- in reality
-- name clashes do occur and cause some headaches to users.  These
headaches are avoidable with careful craft and technical means, but
it's smart of Emacs maintainers to put this possibility aside at least
for the foreseeable future, until in Emacs 50 we have some kind of
decent namespacing solution (IMHO prefixing doesn't really count and
I don't see  how a system can keep growing and growing without one).

Furthermore the mere suggestion of such a naming clash has put some
people on edge and in a combat-mode, spinning the whole initiave into
some kind of hostile takeover of someone's else work, obviously
distracting for the much more challenging -- and interesting -- aspects
of developing a new major mode.  So in hindsight, my suggestion was a
big fat mistake.


João

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Danny Freeman <danny@dfreeman.email> writes:

>> Of course the naming issue is real,
> Yes, I'm glad to see you acknowledge this as an issue. The naming issue
> is all I'm trying to speak to right now.

Well, again, you are putting the cart before the horse (and yes, I know
earlier I wrote "bulls in front of carriage", which is comically wrong).

> In no particular order:
> - Clojure-mode has built in refactoring tools, not all of which exist in
>   clojure-lsp (to the best of my knowledge).

An example or two would be nice.  

> - Clojure-mode provides an API for tools like CIDER and inf-clojure to
>   interact with clojure buffers.
> - Clojure-mode integrates with CIDER to allow clojure macros and
>   functions to define indentation rules as part of their metadata. I'm
>   not sure if it will even be possible for clojure-ts-mode to do this.

It seems you are saying that it is tightly coupled with CIDER.  Is this
API described anywhere?

> There is nothing very special about clojure-ts-mode that I develop right
> now. It is a work in progress and far from finished. It's not even quite
> to the point where I can dogfood it at work yet. A long term goal is to
> provide everything clojure-mode provides for CIDER with
> clojure-ts-mode.

I might have missed some important from yourself, but if clojure-ts-mode
is in such stages of infancy and you are its author, why don't you
consider placing clojure-ts-mode in a GNU repository?  If CIDER is such
a fundamental tool (like SLIME and SLY are for Common Lisp) your
long-term goals would decidely also apply to any future GNU Clojure
mode for Emacs.

>> Can you say if CIDER is prepared to
>> work with major modes other than the NonGNU Clojure mode?
>
> No I cannot, as I am not a CIDER developer.

It seems you already answered this question above, when you said that
NonGNU clojure-mode provides an API for CIDER to call into.

João

Re: Brand new clojure support in Emacs ;-)

[João Távora]

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

> I might have missed some important from yourself, but if clojure-ts-mode
> is in such stages of infancy and you are its author, why don't you
> consider placing clojure-ts-mode in a GNU repository?  If CIDER is such
> a fundamental tool (like SLIME and SLY are for Common Lisp) your
> long-term goals would decidely also apply to any future GNU Clojure
> mode for Emacs.

Going back to some earlier emails I see you have addressed this earlier.
You wrote:

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

From what I could gather from clojure-ts-mode's GitHub repository, you
and Bozidhar are its main authors.  Then there is a single non-trivial
contribution by a single other author Jason Jackson, bringing the total
number of contributors to 3.  That single contribution is a syntax table
which looks non-trivial in terms of LOC, but it repeats a lot of what is
already lisp-data-mode's syntax table anyway, so probably could be
rewritten very easily).

Therefore, given that both you and Bozidhar have signed CA's and given
that you could happily continue to develop it on GitHub (like I did with
Eglot for many years), I'm astonished how you were convinced to not
bring your creation into the GNU project after initially wanting to.

Personally, I can say that Eglot has over a 100 contributors and I never
saw copyright assignment as a anywhere close to a significant issue
hampering contribution.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Therefore, given that both you and Bozidhar have signed CA's and given
> that you could happily continue to develop it on GitHub (like I did with
> Eglot for many years), I'm astonished how you were convinced to not
> bring your creation into the GNU project after initially wanting to.

And I'm astonished how you can't take "no" as an answer. Once someone makes the case for serious benefits of including something in ELPA/core we'd strongly consider this, but everything that was discussed so far is just extremely subjective. We clearly have different perspective of where value is derived from - I believe in nurturing a community around specific projects, you believe in the power of GNU to provide support and development resources for everything under its hat ad for all time. It's fine for people to value different things and for good outcomes to be achieved by different means. 

I still haven't heard what are the problems that bringing the Clojure support to ELPA or core would solve. I said I don't buy that installing 3rd party packages is a big obstacle. I've also told you we have a big organization of people behind the clojure-emacs community (and a pretty long track record) , so me or Danny are not a bus factor of one. We came and submitted the packages to NonGNU ELPA to make things easier for people who are skeptical of MELPA, etc. From my perspective we've been very accommodating and collaborative, but somehow that's not enough. 

Being part of GNU is great. Not being part of GNU is also great. There's more than one right answer from time to time. 

On Fri, Sep 1, 2023, at 8:12 PM, João Távora wrote:
> João Távora <joaotavora@gmail.com> writes:
> 
> > I might have missed some important from yourself, but if clojure-ts-mode
> > is in such stages of infancy and you are its author, why don't you
> > consider placing clojure-ts-mode in a GNU repository?  If CIDER is such
> > a fundamental tool (like SLIME and SLY are for Common Lisp) your
> > long-term goals would decidely also apply to any future GNU Clojure
> > mode for Emacs.
> 
> Going back to some earlier emails I see you have addressed this earlier.
> You wrote:
> 
> > > 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.
> 
> From what I could gather from clojure-ts-mode's GitHub repository, you
> and Bozidhar are its main authors.  Then there is a single non-trivial
> contribution by a single other author Jason Jackson, bringing the total
> number of contributors to 3.  That single contribution is a syntax table
> which looks non-trivial in terms of LOC, but it repeats a lot of what is
> already lisp-data-mode's syntax table anyway, so probably could be
> rewritten very easily).
> 
> Therefore, given that both you and Bozidhar have signed CA's and given
> that you could happily continue to develop it on GitHub (like I did with
> Eglot for many years), I'm astonished how you were convinced to not
> bring your creation into the GNU project after initially wanting to.
> 
> Personally, I can say that Eglot has over a 100 contributors and I never
> saw copyright assignment as a anywhere close to a significant issue
> hampering contribution.
> 
> João
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> And I'm astonished how you can't take "no" as an answer. Once someone
> makes the case for serious benefits of including something in
> ELPA/core we'd strongly consider this, but everything that was
> discussed so far is just extremely subjective.

Danny has already said he would revisit the matter, so I wouldn't speak
for him.  Of course, if the answer is still no, then something else will
eventually come into Emacs.

As far as I could see, Danny's clojure-ts-mode at the moment is little
more than a basic Lisp editing mode build on top of tree sitter.  Not
much more than what Philip suggested earlier and I implemented.  Namely
it's got no CIDER integration.  At a certain point, someone will have to
make changes to CIDER to support it as well, so it's a good oppornity to
decouple things and that will be good for whatever Clojure mode in Emacs

If integrating a new major mode with CIDER is so difficult, don't fret
about it.  You don't have to help if you don't want to.  I have decent
past experience of dealing with such RPC-based systems (SLIME SLY and
Eglot) and they're really not as transcendental as you make them sound.
In the horizon there are other things such as DAP (Debugger Adapter
Protocol) that Emacs will probably want to support in the future.

And no, I don't have to be A Bozhidar-Certified Clojure Programmer to
want to help out, just as I don't speak 90% of the languages Eglot
supports, for example and I still try them out for time to time.

If I went by instinct or "the gist" of what you seem to be saying I'd
say it really sounds like you want to avoid a new Clojure mode in Emacs
at all costs.  But look, no one is coming for your life's work, really,
noone is trying to beat you, best you or take away your Clojure street
cred that you keep boasting about.  So cool down and enjoy your holiday.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Danny has already said he would revisit the matter, so I wouldn't speak
> for him.  Of course, if the answer is still no, then something else will
> eventually come into Emacs.

I'll leave him to speak for himself, but we've been collaborating a bit since the beginning and I've always intended that eventually clojure-ts-mode will become clojure-mode. (see https://metaredux.com/posts/2023/03/12/clojure-mode-meets-tree-sitter.html) 

> As far as I could see, Danny's clojure-ts-mode at the moment is little
> more than a basic Lisp editing mode build on top of tree sitter.  Not
> much more than what Philip suggested earlier and I implemented.  Namely
> it's got no CIDER integration.  At a certain point, someone will have to
> make changes to CIDER to support it as well, so it's a good oppornity to
> decouple things and that will be good for whatever Clojure mode in Emacs

CIDER will support clojure-ts-mode - that's another things we've discussed with Danny. The work required is not particularly complicated, although a few of the features would be hard to implement in terms of tree-sitter, so we might need to keep around the "legacy" clojure-mode in some form down the road. 

> If integrating a new major mode with CIDER is so difficult, don't fret
> about it.  You don't have to help if you don't want to.  I have decent
> past experience of dealing with such RPC-based systems (SLIME SLY and
> Eglot) and they're really not as transcendental as you make them sound.
> In the horizon there are other things such as DAP (Debugger Adapter
> Protocol) that Emacs will probably want to support in the future.

By all means - go and re-create CIDER as well, oh all mighty Wizard of the RPC! :-) Yeah, I'm totally making shit up just to sound important and you've exposed me to the world! Shame on me!

The core evaluation functionality in CIDER is trivial and I have no doubt that anyone who's determined can re-create it. CIDER was already forked once and kind of rewritten once with a different eval backend. Both projects didn't get very far, but they say that 3rd time is the charm! 

> And no, I don't have to be A Bozhidar-Certified Clojure Programmer to
> want to help out, just as I don't speak 90% of the languages Eglot
> supports, for example and I still try them out for time to time.

Another snarky unwarranted remark, but whatever. Clearly you don't want us to have a civil conversation. 

> If I went by instinct or "the gist" of what you seem to be saying I'd
> say it really sounds like you want to avoid a new Clojure mode in Emacs
> at all costs.  But look, no one is coming for your life's work, really,
> noone is trying to beat you, best you or take away your Clojure street
> cred that you keep boasting about.  So cool down and enjoy your holiday.

Another brilliant insight! I really wonder how the f**k you come up with those accusations??? If you think that my self-esteem in life comes from work on Emacs packages - I have to break it to you, but it doesn't. I get "endless satisfaction" from wasting my spare time on random projects for free, so I can be attacked by people like you on mailing lists, right? Hell, yeah!!!

One a less bitter note - I've welcomed Danny's idea to start work on a replacement for clojure-mode and I believe I've been supportive of his work every step of the way (Danny can, of course, confirm this for himself). I've already shared earlier in this message the rough plan for how clojure-mode and clojure-ts-mode should evolve in the next couple of years. I'm juggling more projects that I have time for and the only reason I got involved in clojure-mode is that there was no one else willing to do the work that was required. And you dare accuse me of pumping my ego by clinging to its "ownership"? I can assure that I have a lot more important things in my life. 

P.S. You were just boasting about your street cred yourself, which I do find is kind of ironic in a conversation like this one. Are trying to solve problems here or measure our street cred? (or something else?)

Anyways, I can be snarky and aggressive myself. I'm not a particularly calm person and I totally don't tolerate when people try to pin their crazy unsubstantiated claims on me. I'll urge once again to abstain from personal attacks if you expect me to take you seriously. 

On Sun, Sep 3, 2023, at 6:07 PM, João Távora wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > And I'm astonished how you can't take "no" as an answer. Once someone
> > makes the case for serious benefits of including something in
> > ELPA/core we'd strongly consider this, but everything that was
> > discussed so far is just extremely subjective.
> 
> Danny has already said he would revisit the matter, so I wouldn't speak
> for him.  Of course, if the answer is still no, then something else will
> eventually come into Emacs.
> 
> As far as I could see, Danny's clojure-ts-mode at the moment is little
> more than a basic Lisp editing mode build on top of tree sitter.  Not
> much more than what Philip suggested earlier and I implemented.  Namely
> it's got no CIDER integration.  At a certain point, someone will have to
> make changes to CIDER to support it as well, so it's a good oppornity to
> decouple things and that will be good for whatever Clojure mode in Emacs
> 
> If integrating a new major mode with CIDER is so difficult, don't fret
> about it.  You don't have to help if you don't want to.  I have decent
> past experience of dealing with such RPC-based systems (SLIME SLY and
> Eglot) and they're really not as transcendental as you make them sound.
> In the horizon there are other things such as DAP (Debugger Adapter
> Protocol) that Emacs will probably want to support in the future.
> 
> And no, I don't have to be A Bozhidar-Certified Clojure Programmer to
> want to help out, just as I don't speak 90% of the languages Eglot
> supports, for example and I still try them out for time to time.
> 
> If I went by instinct or "the gist" of what you seem to be saying I'd
> say it really sounds like you want to avoid a new Clojure mode in Emacs
> at all costs.  But look, no one is coming for your life's work, really,
> noone is trying to beat you, best you or take away your Clojure street
> cred that you keep boasting about.  So cool down and enjoy your holiday.
> 
> João
> 
> 
> 
> 
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

On Sun, Sep 3, 2023 at 7:37 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:

> I'll leave him to speak for himself, but we've been collaborating
> a bit since the beginning and I've always intended that eventually
> clojure-ts-mode will become clojure-mode.

Oh maybe one one of the names you took will free up then. :-)

> CIDER will support clojure-ts-mode - that's another things we've

Sure I got that.  And currently CIDER is strongly coupled to
implementation details of clojure-mode.  So for your plans to take
place, this will require outlining the existing informal API between
the two realities: major mode and CIDER overlay minor mode.  This
will be a good thing in itself, and hopefully it will allow other
Clojure major modes to take advantage of CIDER.

> By all means - go and re-create CIDER as well, oh all mighty
> Wizard of the RPC! :-)

I clearly wrote about integrating with CIDER, not rewriting it.
So, again, you're really reading things that I didn't write.

> Yeah, I'm totally making shit up just to sound important and
> you've exposed me to the world! Shame on me!

Let's see, you wrote in your many recent messages, just as an example:

  > without an understanding of Clojure and its tooling ecosystem
  > (and it's history) it's hard to make good suggestions about
  > what makes sense and what doesn't.

Then you said it's "funny" that my ideas -- which you totally misread
-- are starting from some naive position that you already faced
15 years ago.  Then you talk about your "big organization of people"
and your track record, that there's only two Clojure programmers in
this conversation, that we're not "subject experts".  Instead of
technical arguments, you drop videos of your presentations on youtube
and links to your blog posts.

If all this is not a paternalistic attempt at dissuasion, it's at
least odd from someone who's already said he's not interested
in contributing to this endeavor, and who's not really being
asked to anymore.

> I'm juggling more projects that I have time for and the only reason
> I got involved in clojure-mode is that there was no one else willing
> to do the work that was required.

A good way to help solve your problem would be to contribute it to
GNU Emacs.  I wouldn't expect to become experts overnight, but we'd
do our best.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> Sure I got that.  And currently CIDER is strongly coupled to
> implementation details of clojure-mode.

You say it like it was some design failure, but when there was just a single mode (which is the case like 99% of the time) there's little point to prematurely abstract away such details. 

> I clearly wrote about integrating with CIDER, not rewriting it.
> So, again, you're really reading things that I didn't write.

Well, you did speak about RCP and there's nothing at the RCP level happening between clojure-mode and CIDER. (all the RCP-related code is in CIDER) The APIs that are being used are things like "find the current Clojure namespace", sexp-related functions, etc. 

> Then you said it's "funny" that my ideas -- which you totally misread
> -- are starting from some naive position that you already faced
> 15 years ago.  Then you talk about your "big organization of people"
> and your track record, that there's only two Clojure programmers in
> this conversation, that we're not "subject experts".  Instead of
> technical arguments, you drop videos of your presentations on youtube
> and links to your blog posts.

I don't want to write here again things that I've written about in the past (or presented in the past). I fail to see how sharing such resources is problematic in any way. You might have also noticed that most of the time I use the pronoun "we", because I certainly don't want to claim all the credit for the work done by the broader group of people who are part of clojure-emacs or have contributed to it. And I honest don't understand why you got so hung up on "subject matter experts". I'm not an expert in LSP and I wouldn't dare to lecture you how to do things in eglot, but I do know a bit about Clojure, nREPL and all the Emacs packages and I happen to know what we've tried and didn't work out. You want to brush this aside, for reasons that are still unclear to me. 

I guess I rub you the wrong way for some reason, which seems to go both ways. 

> If all this is not a paternalistic attempt at dissuasion, it's at
> least odd from someone who's already said he's not interested
> in contributing to this endeavor, and who's not really being
> asked to anymore.

What "endeavour" is that exactly? Bringing clojure-mode/clojure-ts-mode to core or replacing them with 2 lines of code? And who started the conversation in a hostile manner? If I didn't happen to be subscribed to emacs-devel I wouldn't even know what was being discussed here, given how events unfolded. Is it really surprising I'd be unhappy about the communication on the topic so far?   

On Sun, Sep 3, 2023, at 9:30 PM, João Távora wrote:
> On Sun, Sep 3, 2023 at 7:37 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> 
> > I'll leave him to speak for himself, but we've been collaborating
> > a bit since the beginning and I've always intended that eventually
> > clojure-ts-mode will become clojure-mode.
> 
> Oh maybe one one of the names you took will free up then. :-)
> 
> > CIDER will support clojure-ts-mode - that's another things we've
> 
> Sure I got that.  And currently CIDER is strongly coupled to
> implementation details of clojure-mode.  So for your plans to take
> place, this will require outlining the existing informal API between
> the two realities: major mode and CIDER overlay minor mode.  This
> will be a good thing in itself, and hopefully it will allow other
> Clojure major modes to take advantage of CIDER.
> 
> > By all means - go and re-create CIDER as well, oh all mighty
> > Wizard of the RPC! :-)
> 
> I clearly wrote about integrating with CIDER, not rewriting it.
> So, again, you're really reading things that I didn't write.
> 
> > Yeah, I'm totally making shit up just to sound important and
> > you've exposed me to the world! Shame on me!
> 
> Let's see, you wrote in your many recent messages, just as an example:
> 
>   > without an understanding of Clojure and its tooling ecosystem
>   > (and it's history) it's hard to make good suggestions about
>   > what makes sense and what doesn't.
> 
> Then you said it's "funny" that my ideas -- which you totally misread
> -- are starting from some naive position that you already faced
> 15 years ago.  Then you talk about your "big organization of people"
> and your track record, that there's only two Clojure programmers in
> this conversation, that we're not "subject experts".  Instead of
> technical arguments, you drop videos of your presentations on youtube
> and links to your blog posts.
> 
> If all this is not a paternalistic attempt at dissuasion, it's at
> least odd from someone who's already said he's not interested
> in contributing to this endeavor, and who's not really being
> asked to anymore.
> 
> > I'm juggling more projects that I have time for and the only reason
> > I got involved in clojure-mode is that there was no one else willing
> > to do the work that was required.
> 
> A good way to help solve your problem would be to contribute it to
> GNU Emacs.  I wouldn't expect to become experts overnight, but we'd
> do our best.
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>  Sure I got that.  And currently CIDER is strongly coupled to
>  implementation details of clojure-mode.
>
> You say it like it was some design failure,

No, I didn't.  You're again imagining things.  I'm just stating
objective facts which are pretty relevant if one wants to add CIDER
interoperation capability to the new major mode that is the subject of
this thread.

> The APIs that are being used are things like "find the current Clojure
> namespace", sexp-related functions, etc.

Yes, that's what I meant by "the existing informal API between the two
realities: major mode and CIDER overlay minor mode".  Those things you
mention are very similar to the coupling between SLIME/SLY and
lisp-mode.  If someone wanted to make a new Common Lisp mode (say, a
TreeSitter one) and they wanted to use SLY with it, the same problem
would arise.  And yes, it is easily solved.

>  I clearly wrote about integrating with CIDER, not rewriting it.
>  So, again, you're really reading things that I didn't write.
>
> Well, you did speak about RCP and there's nothing at the RCP level
> happening between clojure-mode and CIDER. (all the RCP-related code is
> in CIDER) The APIs that are being used are things like "find the
> current Clojure namespace", sexp-related functions, etc.

What I wrote is that there's nothing transcendental that I can detect
about the architecture of an RPC system for Emacs like CIDER.  There's a
major mode, a collection of minor modes and a reflection backend in the
host language.

> experts". I'm not an expert in LSP and I wouldn't dare to lecture you
> how to do things in eglot, but I do know a bit about Clojure, nREPL
> and all the Emacs packages and I happen to know what we've tried and
> didn't work out. You want to brush this aside, for reasons that are
> still unclear to me.

That's the thing: Noone is lecturing you on anything.  Noone's even
asking you for anything.  If anything it's the other way round, you seem
want us to literally sit through a lecture of yours on the subject.

>  If all this is not a paternalistic attempt at dissuasion, it's at
>  least odd from someone who's already said he's not interested
>  in contributing to this endeavor, and who's not really being
>  asked to anymore.
>
> What "endeavour" is that exactly? Bringing
> clojure-mode/clojure-ts-mode to core or replacing them with 2 lines of
> code?

Writing a new major mode, of course, a direct:

* consequence of Richard's request
* your refusal to integrate clojure-mode or clojure-ts-mode
* Philip's interesting suggestion

It's the top message of this discussion, have you read it?  And yes it's
two lines of code, but you have to start somewhere and that's what I
did.  TreeSitter could also be useful later on, for font-locking, etc...

> And who started the conversation in a hostile manner?  If I didn't
> happen to be subscribed to emacs-devel I wouldn't even know what was
> being discussed here, given how events unfolded. Is it really
> surprising I'd be unhappy about the communication on the topic so far?

What hostile manner?  Do we need permission from you to start discussing
Clojure editing facilities here?

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> What hostile manner?  Do we need permission from you to start discussing
> Clojure editing facilities here

You don't need my permission to do anything. But in my book it's good manners to try to get people involved in a conversation that might benefit from their presence. One day perhaps you'll learn that things happen a lot smoother if you put some minimal efforts to be more considerate when you communicate with others - a point I've been trying to make in quite a few messages. 

I'll leave most of the other points without a response, given that at this point we're not really discussing anything other than who misunderstood who, which I'm tired of. 

On Mon, Sep 4, 2023, at 12:21 AM, João Távora wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> >  Sure I got that.  And currently CIDER is strongly coupled to
> >  implementation details of clojure-mode.
> >
> > You say it like it was some design failure,
> 
> No, I didn't.  You're again imagining things.  I'm just stating
> objective facts which are pretty relevant if one wants to add CIDER
> interoperation capability to the new major mode that is the subject of
> this thread.
> 
> > The APIs that are being used are things like "find the current Clojure
> > namespace", sexp-related functions, etc.
> 
> Yes, that's what I meant by "the existing informal API between the two
> realities: major mode and CIDER overlay minor mode".  Those things you
> mention are very similar to the coupling between SLIME/SLY and
> lisp-mode.  If someone wanted to make a new Common Lisp mode (say, a
> TreeSitter one) and they wanted to use SLY with it, the same problem
> would arise.  And yes, it is easily solved.
> 
> >  I clearly wrote about integrating with CIDER, not rewriting it.
> >  So, again, you're really reading things that I didn't write.
> >
> > Well, you did speak about RCP and there's nothing at the RCP level
> > happening between clojure-mode and CIDER. (all the RCP-related code is
> > in CIDER) The APIs that are being used are things like "find the
> > current Clojure namespace", sexp-related functions, etc.
> 
> What I wrote is that there's nothing transcendental that I can detect
> about the architecture of an RPC system for Emacs like CIDER.  There's a
> major mode, a collection of minor modes and a reflection backend in the
> host language.
> 
> > experts". I'm not an expert in LSP and I wouldn't dare to lecture you
> > how to do things in eglot, but I do know a bit about Clojure, nREPL
> > and all the Emacs packages and I happen to know what we've tried and
> > didn't work out. You want to brush this aside, for reasons that are
> > still unclear to me.
> 
> That's the thing: Noone is lecturing you on anything.  Noone's even
> asking you for anything.  If anything it's the other way round, you seem
> want us to literally sit through a lecture of yours on the subject.
> 
> >  If all this is not a paternalistic attempt at dissuasion, it's at
> >  least odd from someone who's already said he's not interested
> >  in contributing to this endeavor, and who's not really being
> >  asked to anymore.
> >
> > What "endeavour" is that exactly? Bringing
> > clojure-mode/clojure-ts-mode to core or replacing them with 2 lines of
> > code?
> 
> Writing a new major mode, of course, a direct:
> 
> * consequence of Richard's request
> * your refusal to integrate clojure-mode or clojure-ts-mode
> * Philip's interesting suggestion
> 
> It's the top message of this discussion, have you read it?  And yes it's
> two lines of code, but you have to start somewhere and that's what I
> did.  TreeSitter could also be useful later on, for font-locking, etc...
> 
> > And who started the conversation in a hostile manner?  If I didn't
> > happen to be subscribed to emacs-devel I wouldn't even know what was
> > being discussed here, given how events unfolded. Is it really
> > surprising I'd be unhappy about the communication on the topic so far?
> 
> What hostile manner?  Do we need permission from you to start discussing
> Clojure editing facilities here?
> 
> João
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>  What hostile manner?  Do we need permission from you to start discussing
>  Clojure editing facilities here
>
> You don't need my permission to do anything. But in my book it's good
> manners to try to get people involved in a conversation that might
> benefit from their presence.

All I did when I started this thread was grab this message from Philip
Kaludercic:

  https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00968.html

I hit "reply to all" and changed the subject line for clarity.  By then,
you had already made very clear to Eli and others that your Clojure
modes would not come to GNU Emacs.  Your opening "I've said a million
times" email didn't exactly sound exactly very chummy either:

    I've been maintaining almost all of the Clojure dev tooling for
    Emacs for over a decade, so I do believe that by now I know what I'm
    doing and how I want to do things. I've said a million times by now
    that I don't want contributors to have to deal with copyright
    agreements.

In:

  https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01127.html

So excuse me for not issuing a special scented invitation to His
Highness, but I did believe he was above Being Bothered with GNU
trivialities.

> One day perhaps you'll learn that things 

"good manners"?? "one day perhaps you'll learn"??? You can't make this
stuff up.  Send me your youtube video on good manners, too?

Let's be clear: your help -- would there have been any -- would of
course have been welcomed.  But I didn't see it as essential: none of
your code was involved I was explicitly starting from scratch.  And to
be frank you didn't even pop in my head when starting the thread, so I
did was "reply to all".  Anyone can read these emails, after all.  You
did finally find the thread.  But then all you did was try to
intimidate, scaremonger and dissuade.

Given that you're now backtracking, err... reviewing your position, we
might have your Clojure modes in GNU in the end.  So I guess something
decent might come of those 2 lines of code after all.

João

Re: Brand new clojure support in Emacs ;-)

[Po Lu]

This thread has devolved into a cacophony of vague insinuations
concerning the conduct and motivations of each of its participants,
which suggests that it is perhaps time for it to stop.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

I fully agree. I've already indicated willingness to revisit the topic with the rest of our team and that's what I intend to do. I appreciate the thoughtful comments from everyone who provided any. 

I am also emotionally drained by the exchanges with Joao and I'm taking a break from this thread and going back to enjoying my vacation. 

On Mon, Sep 4, 2023, at 10:42 AM, Po Lu wrote:
> This thread has devolved into a cacophony of vague insinuations
> concerning the conduct and motivations of each of its participants,
> which suggests that it is perhaps time for it to stop.
> 

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

Clojure Mode in Emacs - an exercise in counter-productive communication

[Bozhidar Batsov]

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

Okay. I tried to conclude our conversation on good terms but clearly you believe I'm not doing something right by you. I don't have to tolerate your bulshit and snarky remarks.  

Keep being a jerk if you insist to. And keep believing you know all the answers. That aggressive attitude is the main reason why so many people steer clear of emacs-devel. That's the last message exchange I'll have with you on the subject. 

On Mon, Sep 4, 2023, at 10:25 AM, João Távora wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> >  What hostile manner?  Do we need permission from you to start discussing
> >  Clojure editing facilities here
> >
> > You don't need my permission to do anything. But in my book it's good
> > manners to try to get people involved in a conversation that might
> > benefit from their presence.
> 
> All I did when I started this thread was grab this message from Philip
> Kaludercic:
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00968.html
> 
> I hit "reply to all" and changed the subject line for clarity.  By then,
> you had already made very clear to Eli and others that your Clojure
> modes would not come to GNU Emacs.  Your opening "I've said a million
> times" email didn't exactly sound exactly very chummy either:
> 
>     I've been maintaining almost all of the Clojure dev tooling for
>     Emacs for over a decade, so I do believe that by now I know what I'm
>     doing and how I want to do things. I've said a million times by now
>     that I don't want contributors to have to deal with copyright
>     agreements.
> 
> In:
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01127.html
> 
> So excuse me for not issuing a special scented invitation to His
> Highness, but I did believe he was above Being Bothered with GNU
> trivialities.
> 
> > One day perhaps you'll learn that things 
> 
> "good manners"?? "one day perhaps you'll learn"??? You can't make this
> stuff up.  Send me your youtube video on good manners, too?
> 
> Let's be clear: your help -- would there have been any -- would of
> course have been welcomed.  But I didn't see it as essential: none of
> your code was involved I was explicitly starting from scratch.  And to
> be frank you didn't even pop in my head when starting the thread, so I
> did was "reply to all".  Anyone can read these emails, after all.  You
> did finally find the thread.  But then all you did was try to
> intimidate, scaremonger and dissuade.
> 
> Given that you're now backtracking, err... reviewing your position, we
> might have your Clojure modes in GNU in the end.  So I guess something
> decent might come of those 2 lines of code after all.
> 
> João
> 

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

Re: Clojure Mode in Emacs - an exercise in counter-productive communication

[João Távora]

On Mon, Sep 4, 2023 at 9:49 AM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
>
> Okay. I tried to conclude our conversation on good terms but clearly you believe I'm not doing something right by you.

Your last message did nothing but chafe about my poor
manners for not inviting you specially to a discussion
and offered me life advice on being productive.
That's hardly "on good terms", but I too am happy to end
it here.  Do enjoy your holiday, sincerely.

Re: Clojure Mode in Emacs - an exercise in counter-productive communication

[Bozhidar Batsov]

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

For the record - that wasn't my last reply to you. Perhaps you missed it, perhaps you just enjoy insulting me. I honestly don't give a fuck at this point. 

I tried to listen to the perspective of others, despite my initial position. You are directly telling me now that you believe you have bullied/forced me to reconsider. Do you honestly believe this is a healthy way to work together with others???

I told you that nicer communication is more productive, not that it'd make you more productive. You twist the meaning of half the things I say, you keep mocking me and you make zero effort to change our tone. 

Everyone here can decide for themselves who's constructive and who's an asshole. Just leave me alone and go live in your magical GNU castle. 

On Mon, Sep 4, 2023, at 10:55 AM, João Távora wrote:
> On Mon, Sep 4, 2023 at 9:49 AM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> >
> > Okay. I tried to conclude our conversation on good terms but clearly you believe I'm not doing something right by you.
> 
> Your last message did nothing but chafe about my poor
> manners for not inviting you specially to a discussion
> and offered me life advice on being productive.
> That's hardly "on good terms", but I too am happy to end
> it here.  Do enjoy your holiday, sincerely.
> 
> 

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

Re: Clojure Mode in Emacs - an exercise in counter-productive communication

[João Távora]

On Mon, Sep 4, 2023 at 1:30 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
>
> For the record - that wasn't my last reply to you.

Didn't you say you wanted to stop this thread?
Stop repeatedly calling me names and patronizing me, just
stop, it's an embarrassment.

Re: Clojure Mode in Emacs - an exercise in counter-productive communication

[Bozhidar Batsov]

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

Thread stopped. 

On Mon, Sep 4, 2023, at 2:35 PM, João Távora wrote:
> On Mon, Sep 4, 2023 at 1:30 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> >
> > For the record - that wasn't my last reply to you.
> 
> Didn't you say you wanted to stop this thread?
> Stop repeatedly calling me names and patronizing me, just
> stop, it's an embarrassment.
> 
> 

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

Re: Clojure Mode in Emacs - an exercise in counter-productive communication

[Eli Zaretskii]

> Date: Mon, 04 Sep 2023 10:48:54 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Danny Freeman" <danny@dfreeman.email>, "Eli Zaretskii" <eliz@gnu.org>,
>  "Dmitry Gutov" <dmitry@gutov.dev>, "Richard Stallman" <rms@gnu.org>,
>  "Emacs Devel" <emacs-devel@gnu.org>
> 
> Okay. I tried to conclude our conversation on good terms but clearly you believe I'm not doing
> something right by you.

Yes, you are.  It is just that it's time to stop this side discussion
and move on.  We have reached a point where we understand the issues
and the concerns of each other, and can take this forward to greater
common good.

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Cc: "Danny Freeman" <danny@dfreeman.email>,  "Eli Zaretskii" <eliz@gnu.org>,
>  "Dmitry Gutov" <dmitry@gutov.dev>,  "Richard Stallman" <rms@gnu.org>,
>  "Emacs Devel" <emacs-devel@gnu.org>
> Date: Mon, 04 Sep 2023 09:25:50 +0100
> 
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> >  What hostile manner?  Do we need permission from you to start discussing
> >  Clojure editing facilities here
> >
> > You don't need my permission to do anything. But in my book it's good
> > manners to try to get people involved in a conversation that might
> > benefit from their presence.
> 
> All I did when I started this thread was grab this message from Philip
> Kaludercic:
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg00968.html
> 
> I hit "reply to all" and changed the subject line for clarity.  By then,
> you had already made very clear to Eli and others that your Clojure
> modes would not come to GNU Emacs.  Your opening "I've said a million
> times" email didn't exactly sound exactly very chummy either:
> 
>     I've been maintaining almost all of the Clojure dev tooling for
>     Emacs for over a decade, so I do believe that by now I know what I'm
>     doing and how I want to do things. I've said a million times by now
>     that I don't want contributors to have to deal with copyright
>     agreements.
> 
> In:
> 
>   https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01127.html
> 
> So excuse me for not issuing a special scented invitation to His
> Highness, but I did believe he was above Being Bothered with GNU
> trivialities.
> 
> > One day perhaps you'll learn that things 
> 
> "good manners"?? "one day perhaps you'll learn"??? You can't make this
> stuff up.  Send me your youtube video on good manners, too?

Guys, please cool down.  There's no reason to discuss each other's
manners, once the misunderstandings have been cleared.  Let's move on
to cooperate in making a better Emacs, okay?

Re: Brand new clojure support in Emacs ;-)

[Danny Freeman]

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

>> In no particular order:
>> - Clojure-mode has built in refactoring tools, not all of which exist in
>>   clojure-lsp (to the best of my knowledge).
>
> An example or two would be nice.  

I don't use the clojure-lsp refactoring tools, so can't speak much to
them. The clojure mode ones are numerous, and include a lot of helpers
for winding and unwinding threading macros, extracting things out into
definitions and let bindings, namespace sorting (I'm pretty sure
clojure-lsp does that), changing collection literals, and more.

I'm sure the clojure-lsp refactoring tools are very capable.

> It seems you are saying that it is tightly coupled with CIDER.  Is this
> API described anywhere?

I don't think so. CIDER and clojure-mode are developed in lock-step,
along side a couple other projects written in clojure to support CIDER
from within the clojure repl process. The API is just the functions that
CIDER calls from clojure-mode. If you want more information you will be
best off reading the CIDER source.

>> There is nothing very special about clojure-ts-mode that I develop right
>> now. It is a work in progress and far from finished. It's not even quite
>> to the point where I can dogfood it at work yet. A long term goal is to
>> provide everything clojure-mode provides for CIDER with
>> clojure-ts-mode.
>
> I might have missed some important from yourself, but if clojure-ts-mode
> is in such stages of infancy and you are its author, why don't you
> consider placing clojure-ts-mode in a GNU repository?  If CIDER is such
> a fundamental tool (like SLIME and SLY are for Common Lisp) your
> long-term goals would decidely also apply to any future GNU Clojure
> mode for Emacs.

I see your other message where you discovered some of my reasoning, and 
I feel I've already explained my position. You will also see a later
message where I said once clojure-ts-mode is in a more "done" state I
will revisit the question of inclusion here with other clojure-mode
devs. Until then I will continue to develop clojure-ts-mode in the
clojure-emacs github organization with the intention of integrating it
with the rest of the clojure-emacs tooling. I appreciate the numerous
offers I have had to pull clojure-ts-mode into Emacs, but for now I am
saying no.

-- 
Danny Freeman

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

Danny Freeman <danny@dfreeman.email> writes:

> You will also see a later
> message where I said once clojure-ts-mode is in a more "done" state I
> will revisit the question of inclusion here with other clojure-mode
> devs. Until then I will continue to develop clojure-ts-mode in the
> clojure-emacs github organization with the intention of integrating it
> with the rest of the clojure-emacs tooling.

Thanks again for being willing to revisit this decision.  Emacs 30 is
still at least a year away, so I think late spring or early summer
2024 could be a good time to do it.

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 1 Sep 2023 21:25:06 +0200
> Cc: João Távora <joaotavora@gmail.com>, 
> 	Eli Zaretskii <eliz@gnu.org>, Dmitry Gutov <dmitry@gutov.dev>, rms@gnu.org, emacs-devel@gnu.org
> 
> Danny Freeman <danny@dfreeman.email> writes:
> 
> > You will also see a later
> > message where I said once clojure-ts-mode is in a more "done" state I
> > will revisit the question of inclusion here with other clojure-mode
> > devs. Until then I will continue to develop clojure-ts-mode in the
> > clojure-emacs github organization with the intention of integrating it
> > with the rest of the clojure-emacs tooling.
> 
> Thanks again for being willing to revisit this decision.  Emacs 30 is
> still at least a year away, so I think late spring or early summer
> 2024 could be a good time to do it.

If this will be a package that's not bundled with Emacs, its
development and release schedule doesn't have to be synchronized with
Emacs, unless the package needs some features not currently available
in Emacs 29 or earlier.  But if there's intent to perhaps include this
package with Emacs, then for that to happen in Emacs 30.1, the
decision should be earlier, perhaps within the next 4-5 months.
Because, though the _release_ of Emacs 30 is probably a year or so
away, we might decide to cut the emacs-30 release branch before the
end of 2023, and any additional new features after that would be
harder to get into the release branch.

Re: Brand new clojure support in Emacs ;-)

[Danny Freeman]

Eli Zaretskii <eliz@gnu.org> writes:

>> Thanks again for being willing to revisit this decision.  Emacs 30 is
>> still at least a year away, so I think late spring or early summer
>> 2024 could be a good time to do it.
>
> If this will be a package that's not bundled with Emacs, its
> development and release schedule doesn't have to be synchronized with
> Emacs, unless the package needs some features not currently available
> in Emacs 29 or earlier.  But if there's intent to perhaps include this
> package with Emacs, then for that to happen in Emacs 30.1, the
> decision should be earlier, perhaps within the next 4-5 months.
> Because, though the _release_ of Emacs 30 is probably a year or so
> away, we might decide to cut the emacs-30 release branch before the
> end of 2023, and any additional new features after that would be
> harder to get into the release branch.

Just wanted to respond here to let you know I didn't let this message
get lost in the sea of emails over the last week.
I will be sure to keep this time frame in mind during the decision
making process.

All the best,
-- 
Danny Freeman

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

Danny Freeman <danny@dfreeman.email> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> Thanks again for being willing to revisit this decision.  Emacs 30 is
>>> still at least a year away, so I think late spring or early summer
>>> 2024 could be a good time to do it.
>>
>> If this will be a package that's not bundled with Emacs, its
>> development and release schedule doesn't have to be synchronized with
>> Emacs, unless the package needs some features not currently available
>> in Emacs 29 or earlier.  But if there's intent to perhaps include this
>> package with Emacs, then for that to happen in Emacs 30.1, the
>> decision should be earlier, perhaps within the next 4-5 months.
>> Because, though the _release_ of Emacs 30 is probably a year or so
>> away, we might decide to cut the emacs-30 release branch before the
>> end of 2023, and any additional new features after that would be
>> harder to get into the release branch.
>
> Just wanted to respond here to let you know I didn't let this message
> get lost in the sea of emails over the last week.
> I will be sure to keep this time frame in mind during the decision
> making process.

Thanks for the update, appreciated.

As I've said elsewhere, feel free to reach out if any questions come up
during your discussions, either here on the list or directly to me and
Eli.

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Danny Freeman <danny@dfreeman.email> writes:

> I don't think so. CIDER and clojure-mode are developed in lock-step,
> along side a couple other projects written in clojure to support CIDER
> from within the clojure repl process. The API is just the functions that
> CIDER calls from clojure-mode. If you want more information you will be
> best off reading the CIDER source.

OK.  So at some point, if you want your new clojure-ts-mode to be
integrated with CIDER, a more formalized API will have to emerge for
your new mode to adhere to.  It would be a good service to everybody to
take opportunity to document it and formalize it.

> I see your other message where you discovered some of my reasoning, and 
> I feel I've already explained my position. You will also see a later
> message where I said once clojure-ts-mode is in a more "done" state I
> will revisit the question of inclusion here with other clojure-mode
> devs. Until then I will continue to develop clojure-ts-mode in the
> clojure-emacs github organization with the intention of integrating it
> with the rest of the clojure-emacs tooling.

AFAIK, putting your clojure-ts-mode in GNU Elpa core GNU Emacs does
_not_ collide with the practice of developing in a GitHub organization
nor with your intention of integration with some specific tooling...

I've had a look at clojure-ts-mode and is seems very young indeed.  Is
there any reason you didn't derive from lisp-data-mode? I think you
should at least reuse lisp-data-mode-syntax-table instead of listing a
very large entry that essentially repeats it.

I am curious about the performance and capabilities of tree sitter in
Lisp modes.  Lisp modes are perhaps the easiest modes things to parse
and the ones Emacs has better support for.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Hi everyone!

I had decided at first to ignore this thread, given I'm on vacation this week, but its overall tone and directly really forced me to write something here. (I have to admit I'm extremely upset while writing this email)

1. I was accused of being "hostile" at some point, but if this thread is "friendly" and "constructive" I've been living in some fantasy world. Repeatedly it has been claimed that:

- The maintainers of the Clojure tooling for Emacs don't know what it's best for it (even if the end users have been happy with their work for a very long time and there's big structure already in place to support the existing tooling)
- The Emacs core team developers are the only people who know what's best for the Clojure tooling - everyone else is "short-sighted", "unreasonable", "aggressive", etc.
- It doesn't matter what name they chose for an alternative package, as the pains of the end users are probably not important. Yeah, if you install a mode named "clojure-mode" that doesn't happen to work with some other packages depending on "clojure-mode" that's perfectly fine in terms of user experience, right? 

2. Suddenly people who have not touched Clojure have realized that Clojure is a very important language and it needs to be supported by Emacs OOTB. Where were you in the past 15 years? Would you have thought of Clojure at all if we haven't bothered to submit the Clojure packages to NonGNU ELPA? (which started all those conversations) Don't bother to answer here - I think that's quite obvious. 

I'm still waiting to see a single actual Clojure user making the case that something will be gained by going in the direction that the Emacs developers have been pushing for for the past few weeks. 

3. Why do you accuse me of having "my way or the highway" attitude when you repeated ignore me and Danny and just power on with whatever you believe to be right? Don't you think that dismissing other people's opinions in such a hostile way might be a bit counter-productive? 

4. I also learned that 15 years of work don't amount to much (according to you) and we can easily get more or less the same experience with 20 lines of code and LSP.  From people who are not actually using Clojure in any capacity (at least to my knowledge)

I've been nothing but a champion of Emacs for 20 years now, yet I feel I'm being treated as an ignorant buffoon here, who wants to do (or not do) things out of sheer spite and stupidity. If that your idea of building a community - fine by me, but I don't want to be a part of this. Afterwards don't argue that people like me are "uncollaborative", "short-sighted", "combative" or whatever else you believe to be the case.  

Instead of having a civilized conversation here, I've felt that it's only "we know better" and to hell with how things used to happen. Sure, you can do whatever you want, but I think that no one will be better off if things in the community happen in this forceful manner. 

I know all of you believe you're trying to solve a problem here, but from my perspective you're creating a problem when there was none. The road to hell is paved with good intentions indeed...

In Emacs We Trust! M-x forever!

On Sat, Sep 2, 2023, at 11:14 AM, João Távora wrote:
> Danny Freeman <danny@dfreeman.email> writes:
> 
> > I don't think so. CIDER and clojure-mode are developed in lock-step,
> > along side a couple other projects written in clojure to support CIDER
> > from within the clojure repl process. The API is just the functions that
> > CIDER calls from clojure-mode. If you want more information you will be
> > best off reading the CIDER source.
> 
> OK.  So at some point, if you want your new clojure-ts-mode to be
> integrated with CIDER, a more formalized API will have to emerge for
> your new mode to adhere to.  It would be a good service to everybody to
> take opportunity to document it and formalize it.
> 
> > I see your other message where you discovered some of my reasoning, and 
> > I feel I've already explained my position. You will also see a later
> > message where I said once clojure-ts-mode is in a more "done" state I
> > will revisit the question of inclusion here with other clojure-mode
> > devs. Until then I will continue to develop clojure-ts-mode in the
> > clojure-emacs github organization with the intention of integrating it
> > with the rest of the clojure-emacs tooling.
> 
> AFAIK, putting your clojure-ts-mode in GNU Elpa core GNU Emacs does
> _not_ collide with the practice of developing in a GitHub organization
> nor with your intention of integration with some specific tooling...
> 
> I've had a look at clojure-ts-mode and is seems very young indeed.  Is
> there any reason you didn't derive from lisp-data-mode? I think you
> should at least reuse lisp-data-mode-syntax-table instead of listing a
> very large entry that essentially repeats it.
> 
> I am curious about the performance and capabilities of tree sitter in
> Lisp modes.  Lisp modes are perhaps the easiest modes things to parse
> and the ones Emacs has better support for.
> 
> João
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Please, excuse my many typos above. I was so affected when I wrote this message that I didn't bother to proofread it before hitting "Send". 

On Sun, Sep 3, 2023, at 10:33 AM, Bozhidar Batsov wrote:
> Hi everyone!
> 
> I had decided at first to ignore this thread, given I'm on vacation this week, but its overall tone and directly really forced me to write something here. (I have to admit I'm extremely upset while writing this email)
> 
> 1. I was accused of being "hostile" at some point, but if this thread is "friendly" and "constructive" I've been living in some fantasy world. Repeatedly it has been claimed that:
> 
> - The maintainers of the Clojure tooling for Emacs don't know what it's best for it (even if the end users have been happy with their work for a very long time and there's big structure already in place to support the existing tooling)
> - The Emacs core team developers are the only people who know what's best for the Clojure tooling - everyone else is "short-sighted", "unreasonable", "aggressive", etc.
> - It doesn't matter what name they chose for an alternative package, as the pains of the end users are probably not important. Yeah, if you install a mode named "clojure-mode" that doesn't happen to work with some other packages depending on "clojure-mode" that's perfectly fine in terms of user experience, right?
> 
> 2. Suddenly people who have not touched Clojure have realized that Clojure is a very important language and it needs to be supported by Emacs OOTB. Where were you in the past 15 years? Would you have thought of Clojure at all if we haven't bothered to submit the Clojure packages to NonGNU ELPA? (which started all those conversations) Don't bother to answer here - I think that's quite obvious.
> 
> I'm still waiting to see a single actual Clojure user making the case that something will be gained by going in the direction that the Emacs developers have been pushing for for the past few weeks.
> 
> 3. Why do you accuse me of having "my way or the highway" attitude when you repeated ignore me and Danny and just power on with whatever you believe to be right? Don't you think that dismissing other people's opinions in such a hostile way might be a bit counter-productive?
> 
> 4. I also learned that 15 years of work don't amount to much (according to you) and we can easily get more or less the same experience with 20 lines of code and LSP.  From people who are not actually using Clojure in any capacity (at least to my knowledge)
> 
> I've been nothing but a champion of Emacs for 20 years now, yet I feel I'm being treated as an ignorant buffoon here, who wants to do (or not do) things out of sheer spite and stupidity. If that your idea of building a community - fine by me, but I don't want to be a part of this. Afterwards don't argue that people like me are "uncollaborative", "short-sighted", "combative" or whatever else you believe to be the case. 
> 
> Instead of having a civilized conversation here, I've felt that it's only "we know better" and to hell with how things used to happen. Sure, you can do whatever you want, but I think that no one will be better off if things in the community happen in this forceful manner.
> 
> I know all of you believe you're trying to solve a problem here, but from my perspective you're creating a problem when there was none. The road to hell is paved with good intentions indeed...
> 
> In Emacs We Trust! M-x forever!
> 
> On Sat, Sep 2, 2023, at 11:14 AM, João Távora wrote:
>> Danny Freeman <danny@dfreeman.email> writes:
>> 
>> > I don't think so. CIDER and clojure-mode are developed in lock-step,
>> > along side a couple other projects written in clojure to support CIDER
>> > from within the clojure repl process. The API is just the functions that
>> > CIDER calls from clojure-mode. If you want more information you will be
>> > best off reading the CIDER source.
>> 
>> OK.  So at some point, if you want your new clojure-ts-mode to be
>> integrated with CIDER, a more formalized API will have to emerge for
>> your new mode to adhere to.  It would be a good service to everybody to
>> take opportunity to document it and formalize it.
>> 
>> > I see your other message where you discovered some of my reasoning, and 
>> > I feel I've already explained my position. You will also see a later
>> > message where I said once clojure-ts-mode is in a more "done" state I
>> > will revisit the question of inclusion here with other clojure-mode
>> > devs. Until then I will continue to develop clojure-ts-mode in the
>> > clojure-emacs github organization with the intention of integrating it
>> > with the rest of the clojure-emacs tooling.
>> 
>> AFAIK, putting your clojure-ts-mode in GNU Elpa core GNU Emacs does
>> _not_ collide with the practice of developing in a GitHub organization
>> nor with your intention of integration with some specific tooling...
>> 
>> I've had a look at clojure-ts-mode and is seems very young indeed.  Is
>> there any reason you didn't derive from lisp-data-mode? I think you
>> should at least reuse lisp-data-mode-syntax-table instead of listing a
>> very large entry that essentially repeats it.
>> 
>> I am curious about the performance and capabilities of tree sitter in
>> Lisp modes.  Lisp modes are perhaps the easiest modes things to parse
>> and the ones Emacs has better support for.
>> 
>> João
>> 
>> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> 4. I also learned that 15 years of work don't amount to much
> (according to you) and we can easily get more or less the same
> experience with 20 lines of code and LSP.

That was 2 lines of code, not 20.  Who knows, with 20 we could probably
do 10 times more :-)

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

My bad! Seems that sky is the limit for the new Clojure mode then! ;-) 

On Sun, Sep 3, 2023, at 11:09 AM, João Távora wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > 4. I also learned that 15 years of work don't amount to much
> > (according to you) and we can easily get more or less the same
> > experience with 20 lines of code and LSP.
> 
> That was 2 lines of code, not 20.  Who knows, with 20 we could probably
> do 10 times more :-)
> 
> João
> 

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

Re: Brand new clojure support in Emacs ;-)

[Po Lu]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> 4. I also learned that 15 years of work don't amount to much
> (according to you) and we can easily get more or less the same
> experience with 20 lines of code and LSP.  From people who are not
> actually using Clojure in any capacity (at least to my knowledge)

I shall be very surprised if Joao has actually made such an assertion.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Not directly, but the gist of it was more or less the same. 

On Sun, Sep 3, 2023, at 11:10 AM, Po Lu wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > 4. I also learned that 15 years of work don't amount to much
> > (according to you) and we can easily get more or less the same
> > experience with 20 lines of code and LSP.  From people who are not
> > actually using Clojure in any capacity (at least to my knowledge)
> 
> I shall be very surprised if Joao has actually made such an assertion.
> 

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

Re: Brand new clojure support in Emacs ;-)

[Po Lu]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Not directly, but the gist of it was more or less the same.

In that case, let's please leave everyone the benefit of the doubt,
instead of unconditionally relying on our flawed capacity for
interpretation.

Re: Brand new clojure support in Emacs ;-)

[Alan Mackenzie]

Hello, Bozhidar.

On Sun, Sep 03, 2023 at 10:33:57 +0200, Bozhidar Batsov wrote:
>    Hi everyone!

>    I had decided at first to ignore this thread, given I'm on vacation
>    this week, but its overall tone and directly really forced me to write
>    something here. (I have to admit I'm extremely upset while writing this
>    email)

I, personally, can understand that.  I have been dismayed by some of the
posts posted by my colleagues on Emacs in the last week or two.  Although
I'm replying to you, the sentiments in this post are really intended for
my fellow hackers on emacs-devel.

Over the last years your team has produced a well liked and well used
Clojure mode for Emacs.  This has involved setting up and maintaining a
development system, which is no small job in itself.  You don't want to
disturb this system by integrating clojure-mode into the Emacs core or
even GNU ELPA.  I don't fully understand the reasons in detail, but I do
see it's not up to me, as it's not me who's put in all the work over the
years.

I don't understand why we need to have a Clojure mode in the Emacs core,
particularly one which would be intended to compete with the existing
clojure-mode.  It seems to me to be entirely within the spirit of free
software for independent projects such as clojure-mode to spring up and
flourish outside the control and direction of the central project.

And even if Emacs were to develop its own competing Clojure mode (which I
say it should not), it MUST have a name of its own and not create
confusion by re-using name of the existing mode.  Such reuse would also
not be displaying respect for the achievements of your team.  We have a
precedent here, with two perl modes in Emacs.  One is called perl-mode,
the other cperl-mode.  As far as I'm aware, they don't get confused.

I hope all these matters can get settled satisfactorally in the coming
days.  But, whatever, please enjoy the rest of your holiday!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Thanks for your response! I totally agree with all the points you've made. 

I'm looking forward to better & friendlier conversations on emacs-devel in the future. 

On Sun, Sep 3, 2023, at 12:13 PM, Alan Mackenzie wrote:
> Hello, Bozhidar.
> 
> On Sun, Sep 03, 2023 at 10:33:57 +0200, Bozhidar Batsov wrote:
> >    Hi everyone!
> 
> >    I had decided at first to ignore this thread, given I'm on vacation
> >    this week, but its overall tone and directly really forced me to write
> >    something here. (I have to admit I'm extremely upset while writing this
> >    email)
> 
> I, personally, can understand that.  I have been dismayed by some of the
> posts posted by my colleagues on Emacs in the last week or two.  Although
> I'm replying to you, the sentiments in this post are really intended for
> my fellow hackers on emacs-devel.
> 
> Over the last years your team has produced a well liked and well used
> Clojure mode for Emacs.  This has involved setting up and maintaining a
> development system, which is no small job in itself.  You don't want to
> disturb this system by integrating clojure-mode into the Emacs core or
> even GNU ELPA.  I don't fully understand the reasons in detail, but I do
> see it's not up to me, as it's not me who's put in all the work over the
> years.
> 
> I don't understand why we need to have a Clojure mode in the Emacs core,
> particularly one which would be intended to compete with the existing
> clojure-mode.  It seems to me to be entirely within the spirit of free
> software for independent projects such as clojure-mode to spring up and
> flourish outside the control and direction of the central project.
> 
> And even if Emacs were to develop its own competing Clojure mode (which I
> say it should not), it MUST have a name of its own and not create
> confusion by re-using name of the existing mode.  Such reuse would also
> not be displaying respect for the achievements of your team.  We have a
> precedent here, with two perl modes in Emacs.  One is called perl-mode,
> the other cperl-mode.  As far as I'm aware, they don't get confused.
> 
> I hope all these matters can get settled satisfactorally in the coming
> days.  But, whatever, please enjoy the rest of your holiday!
> 
> -- 
> Alan Mackenzie (Nuremberg, Germany).
> 

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

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Alan Mackenzie <acm@muc.de> writes:

> And even if Emacs were to develop its own competing Clojure mode (which I
> say it should not), it MUST have a name of its own and not create

Eli has already stated very clearly this is a non-issue, stating --
quite accurately -- that noone who speaks for the Emacs project has
suggested it.  Earlier I had said clearly I don't care and it's not up
to me.  If it _were_ up to me -- which again it's not -- up I would
pursue a technical solution.

So no need to freak out really.

All I did was to follow up on a suggested path and study technical ways
to getting Clojure editing support in Emacs, better than what we have
now, which is 0.  I think is a pretty reasonable thing to do on
emacs-devel.  It's not an immoral thing to do and I'm not coming for His
Highness The Great Clojure Authority Life's Work.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> All I did was to follow up on a suggested path and study technical ways
> to getting Clojure editing support in Emacs, better than what we have
> now, which is 0.  I think is a pretty reasonable thing to do on
> emacs-devel.  It's not an immoral thing to do and I'm not coming for His
> Highness The Great Clojure Authority Life's Work.

Joao, I've tried to be polite, but you behave like a total jerk right now. That's really disappointing as you used to be one of my Emacs heroes for a very long time. That makes me very sad. Such attitude alienates a lot of people from emacs-devel IMO. 

Eli, I hope you'll agree that such attitude is really counter-productive. 

On Sun, Sep 3, 2023, at 5:46 PM, João Távora wrote:
> Alan Mackenzie <acm@muc.de> writes:
> 
> > And even if Emacs were to develop its own competing Clojure mode (which I
> > say it should not), it MUST have a name of its own and not create
> 
> Eli has already stated very clearly this is a non-issue, stating --
> quite accurately -- that noone who speaks for the Emacs project has
> suggested it.  Earlier I had said clearly I don't care and it's not up
> to me.  If it _were_ up to me -- which again it's not -- up I would
> pursue a technical solution.
> 
> So no need to freak out really.
> 
> All I did was to follow up on a suggested path and study technical ways
> to getting Clojure editing support in Emacs, better than what we have
> now, which is 0.  I think is a pretty reasonable thing to do on
> emacs-devel.  It's not an immoral thing to do and I'm not coming for His
> Highness The Great Clojure Authority Life's Work.
> 
> João
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 17:55:13 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Danny Freeman" <danny@dfreeman.email>, "Eli Zaretskii" <eliz@gnu.org>,
>  "Dmitry Gutov" <dmitry@gutov.dev>, "Richard Stallman" <rms@gnu.org>,
>  "Emacs Devel" <emacs-devel@gnu.org>
> 
>  All I did was to follow up on a suggested path and study technical ways
>  to getting Clojure editing support in Emacs, better than what we have
>  now, which is 0.  I think is a pretty reasonable thing to do on
>  emacs-devel.  It's not an immoral thing to do and I'm not coming for His
>  Highness The Great Clojure Authority Life's Work.
> 
> Joao, I've tried to be polite, but you behave like a total jerk right now. That's really disappointing as
> you used to be one of my Emacs heroes for a very long time. That makes me very sad. Such attitude
> alienates a lot of people from emacs-devel IMO. 
> 
> Eli, I hope you'll agree that such attitude is really counter-productive. 

The sarcasm was uncalled for, but other than that, I don't see João's
conduct in this thread as a problem, no.  He proposed a lightweight
alternative to a full-blown clojure-mode, which is a legitimate
proposal.  If nothing else, people could take his code into their init
files and use it locally, if they want.

And even if his behavior were problematic, calling your opponent a
"jerk" is far from being kind.  Discussions are a two-way street, and
if you are opposed to unkind words, you should try very hard not to
use them yourself.

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> And even if his behavior were problematic, calling your opponent a
> "jerk" is far from being kind.  Discussions are a two-way street, and
> if you are opposed to unkind words, you should try very hard not to
> use them yourself.

I take matters of comm etiquette quite seriously, but when someone starts to take personal swipes at me that's where I draw the line. Hostile behavior should not go unnoticed and I think you, as one of the leaders of the project should try to ensure we have a non-hostile environment. emacs-devel is kind of infamous for the harsh language that's tolerated here and if we want to have a bit more inclusive community some efforts should be invested in curbing hostilities. 

It's really hard to have a meaningful conversation when someone is making weird (and wrong) claims about me, my motives and so on. That's something which I really dislike and I'd like us to avoid. In general there shouldn't be "opponents" here, given that supposedly we're on fighting for the same cause. 

On Sun, Sep 3, 2023, at 6:16 PM, Eli Zaretskii wrote:
> > Date: Sun, 03 Sep 2023 17:55:13 +0200
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: "Danny Freeman" <danny@dfreeman.email>, "Eli Zaretskii" <eliz@gnu.org>,
> >  "Dmitry Gutov" <dmitry@gutov.dev>, "Richard Stallman" <rms@gnu.org>,
> >  "Emacs Devel" <emacs-devel@gnu.org>
> > 
> >  All I did was to follow up on a suggested path and study technical ways
> >  to getting Clojure editing support in Emacs, better than what we have
> >  now, which is 0.  I think is a pretty reasonable thing to do on
> >  emacs-devel.  It's not an immoral thing to do and I'm not coming for His
> >  Highness The Great Clojure Authority Life's Work.
> > 
> > Joao, I've tried to be polite, but you behave like a total jerk right now. That's really disappointing as
> > you used to be one of my Emacs heroes for a very long time. That makes me very sad. Such attitude
> > alienates a lot of people from emacs-devel IMO. 
> > 
> > Eli, I hope you'll agree that such attitude is really counter-productive. 
> 
> The sarcasm was uncalled for, but other than that, I don't see João's
> conduct in this thread as a problem, no.  He proposed a lightweight
> alternative to a full-blown clojure-mode, which is a legitimate
> proposal.  If nothing else, people could take his code into their init
> files and use it locally, if they want.
> 
> And even if his behavior were problematic, calling your opponent a
> "jerk" is far from being kind.  Discussions are a two-way street, and
> if you are opposed to unkind words, you should try very hard not to
> use them yourself.
> 
> 

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

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Sun, 03 Sep 2023 22:45:36 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: João Távora <joaotavora@gmail.com>,
>  "Alan Mackenzie" <acm@muc.de>, "Danny Freeman" <danny@dfreeman.email>,
>  "Dmitry Gutov" <dmitry@gutov.dev>, "Richard Stallman" <rms@gnu.org>,
>  "Emacs Devel" <emacs-devel@gnu.org>
> 
>  And even if his behavior were problematic, calling your opponent a
>  "jerk" is far from being kind.  Discussions are a two-way street, and
>  if you are opposed to unkind words, you should try very hard not to
>  use them yourself.
> 
> I take matters of comm etiquette quite seriously, but when someone starts to take personal swipes
> at me that's where I draw the line. Hostile behavior should not go unnoticed and I think you, as one of
> the leaders of the project should try to ensure we have a non-hostile environment.

Hostile behavior should not go unnoticed, but the response should not
be hostile, otherwise we lose the moral argument of calling the others
not to be hostile.

> emacs-devel is
> kind of infamous for the harsh language that's tolerated here and if we want to have a bit more
> inclusive community some efforts should be invested in curbing hostilities. 

Harsh language is not tolerated here, it's a myth.

> It's really hard to have a meaningful conversation when someone is making weird (and wrong) claims
> about me, my motives and so on.

Yes, it could be hard at times.  But still, the responses should not
be hostile, even when you protest the perceived hostility of the other parties.

Re: Brand new clojure support in Emacs ;-)

[João Távora]

On Sun, Sep 3, 2023 at 4:55 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
>
> All I did was to follow up on a suggested path and study technical ways
> to getting Clojure editing support in Emacs, better than what we have
> now, which is 0.  I think is a pretty reasonable thing to do on
> emacs-devel.  It's not an immoral thing to do and I'm not coming for His
> Highness The Great Clojure Authority Life's Work.
>
>
> Joao, I've tried to be polite, but you behave like a total jerk right now. That's really disappointing as you used to be one of my Emacs heroes for a very long time. That makes me very sad. Such attitude alienates a lot of people from emacs-devel IMO.

Sorry Bozhidar, and I apologize if this hurt you or disappointed
you.  I'm fine with not being your hero anymore and frankly I don't
deserve it: there are no "heroes" or "total jerks" here, just someone
who -- contrary to you -- thinks some Clojure support in core Emacs
is good.

It's just you're just coming across as very defensive.  Maybe I
misunderstood "the gist" of your position just as you previously
misinterpreted a position of mine.

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

Totally missed this message given the high traffic on the thread. 

> Sorry Bozhidar, and I apologize if this hurt you or disappointed
> you.  I'm fine with not being your hero anymore and frankly I don't
> deserve it: there are no "heroes" or "total jerks" here, just someone
> who -- contrary to you -- thinks some Clojure support in core Emacs
> is good.

Fair enough. I just really believe that the outcomes are better when we try harder to explain ourselves and understand the concerns of others. Perhaps I failed myself given how the message exchange between the two of us unfolded. 

> It's just you're just coming across as very defensive.  Maybe I
> misunderstood "the gist" of your position just as you previously
> misinterpreted a position of mine.

I was definitely on the defence, given that some of the messages implied things with which I strongly disagree - especially the part that I have something personal to gain from Emacs not having built-in Clojure support. The gist of it for me was simply "I'm ware of the impact that the inclusion would have to the current development process and to the number of outside contributions we'd be getting". I was also unsure of the reasoning for this sudden interest in Clojure from the Emacs team.

Like most people I don't want to do something unless I'm sure it will be valuable in some way (e.g. for the health of the project, for the end users, for Emacs itself, etc). Eli's words that he believes that'd be good for Emacs and I perhaps am not thinking about this got me to pause and think a bit longer. After all, Clojure was probably the biggest reason for new people to try out Emacs around the time it was introduced. 

Anyways, despite everything and my own personal frustration, I think I have a reasonably good idea of where we stand right now and what to do next. 

P.S. I'm a very emotional person and yesterday I was royally pissed. Normally I think a bit longer about what I write, but that wasn't one of those days. 

On Sun, Sep 3, 2023, at 6:20 PM, João Távora wrote:
> On Sun, Sep 3, 2023 at 4:55 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> >
> > All I did was to follow up on a suggested path and study technical ways
> > to getting Clojure editing support in Emacs, better than what we have
> > now, which is 0.  I think is a pretty reasonable thing to do on
> > emacs-devel.  It's not an immoral thing to do and I'm not coming for His
> > Highness The Great Clojure Authority Life's Work.
> >
> >
> > Joao, I've tried to be polite, but you behave like a total jerk right now. That's really disappointing as you used to be one of my Emacs heroes for a very long time. That makes me very sad. Such attitude alienates a lot of people from emacs-devel IMO.
> 
> Sorry Bozhidar, and I apologize if this hurt you or disappointed
> you.  I'm fine with not being your hero anymore and frankly I don't
> deserve it: there are no "heroes" or "total jerks" here, just someone
> who -- contrary to you -- thinks some Clojure support in core Emacs
> is good.
> 
> It's just you're just coming across as very defensive.  Maybe I
> misunderstood "the gist" of your position just as you previously
> misinterpreted a position of mine.
> 
> João
> 

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

Re: Brand new clojure support in Emacs ;-)

[Emanuel Berg]

Bozhidar Batsov wrote:

> I'm a very emotional person and yesterday I was royally
> pissed. Normally I think a bit longer about what I write,
> but that wasn't one of those days.

Don't worry about it, besides adrenaline is good for
your health.

BTW people are writing games in Clojure, maybe one should try
that from Emacs with the new support?

  http://ideolalia.com/creating-a-simple-game-in-clojure

-- 
underground experts united
https://dataswamp.org/~incal

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

I am glad to see that you two have made peace.

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

Re: Brand new clojure support in Emacs ;-)

[Stefan Kangas]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Instead of having a civilized conversation here, I've felt that it's
> only "we know better" and to hell with how things used to
> happen. Sure, you can do whatever you want, but I think that no one
> will be better off if things in the community happen in this forceful
> manner.

I see that you're frustrated here.  I already thanked Danny for his work
on clojure-ts-mode, so let me thank you too.  Your work on clojure-mode
over the years is both valuable and appreciated.

Emacs would not be where it is today without its many excellent
third-party packages, many of which are firmly *not* under the GNU
umbrella.  That's a self-evident fact.

The official position of the project has been stated several times in
this thread, but to re-iterate:

- We disagree with not putting Clojure support on GNU ELPA, but we
  accept that you don't want to do that.

- We will not use the same name for a bundled bare-bones `clojure-mode'.
  It would have to use a different name.  The basic technical reason is
  that Emacs Lisp doesn't have packages/namespaces, as we all know.

- We do not want to impose any particular workflow on packages in GNU
  ELPA, or even those that are bundled together with Emacs.  We only ask
  that they merge occasionally (see Bug#65464 for an example of how
  that's typically handled), and of course that they follow our basic
  policies (e.g. regarding non-free software).

Personally, I agree that the tone in this thread could have been better
at times.  I can only ask everyone to make an extra effort in being
kind, especially so when things are getting tense and feelings are
running high.  It's okay to sometimes remind each other to count to ten,
but let's try to find ways to be kind about that too.

I hope that is of some use, and I wish you a great rest of your
vacation.

> In Emacs We Trust! M-x forever!

Re: Brand new clojure support in Emacs ;-)

[Dmitry Gutov]

On 01/09/2023 13:52, Eli Zaretskii wrote:
>>>>> They don't
>>>>> think in terms of what is best for Emacs
>>>> What if they do?
>>> If they did, they would have agreed with us, or at least said they'd
>>> like to.
>> But we don't always agree between ourselves. Not on this subject anyway.
> Those disagreements are not relevant when the issue is the inclusion
> of a package in core.

So... are you also going to claim that any author of a package who 
doesn't want the inclusion of it (or some other package, or sets of 
packages) in the core Emacs, necessarily "doesn't think in terms of what 
is best for Emacs"?

And that any disagreements are "irrelevant"?

Re: Brand new clojure support in Emacs ;-)

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 16:53:38 +0300
> Cc: rms@gnu.org, joaotavora@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 13:52, Eli Zaretskii wrote:
> >>>>> They don't
> >>>>> think in terms of what is best for Emacs
> >>>> What if they do?
> >>> If they did, they would have agreed with us, or at least said they'd
> >>> like to.
> >> But we don't always agree between ourselves. Not on this subject anyway.
> > Those disagreements are not relevant when the issue is the inclusion
> > of a package in core.
> 
> So... are you also going to claim that any author of a package who 
> doesn't want the inclusion of it (or some other package, or sets of 
> packages) in the core Emacs, necessarily "doesn't think in terms of what 
> is best for Emacs"?

I agree with Richard: authors of packages don't necessarily think
about what's best for Emacs as a whole, and that we shouldn't expect
them to do so.  They are responsible for the packages they develop,
not for the development of Emacs as a whole.  I don't understand why
this is seen as some kind of negative or derogatory remark.  It is
just the consequence of the person's interests and responsibilities.

Re: Brand new clojure support in Emacs ;-)

[Dmitry Gutov]

On 01/09/2023 17:21, Eli Zaretskii wrote:
> I agree with Richard: authors of packages don't necessarily think
> about what's best for Emacs as a whole, and that we shouldn't expect
> them to do so.  They are responsible for the packages they develop,
> not for the development of Emacs as a whole.

The issue at hand is not the development of Emacs as a whole, though. 
But a very specific area.

> I don't understand why
> this is seen as some kind of negative or derogatory remark.  It is
> just the consequence of the person's interests and responsibilities.

I don't understand how you don't see it as negative and divisive, 
especially given the context and where this discussion is going.

Re: Brand new clojure support in Emacs ;-)

[Richard Stallman]

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

  > I don't understand how you don't see it as negative and divisive, 
  > especially given the context and where this discussion is going.

That is not our problem.

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

RE: [External] : Re: Brand new clojure support in Emacs ;-)

[Drew Adams]

> I agree with Richard: authors of packages don't necessarily think
> about what's best for Emacs as a whole, and that we shouldn't expect
> them to do so.  They are responsible for the packages they develop,
> not for the development of Emacs as a whole.  I don't understand why
> this is seen as some kind of negative or derogatory remark.  It is
> just the consequence of the person's interests and responsibilities.

+1.

Authors of 3rd-party packages may or may not
think about what's best for GNU Emacs as a
whole, and it's not derogatory to point this
out.  Hopefully they do; sometimes they don't.

Re: Brand new clojure support in Emacs ;-)

[João Távora]

Richard Stallman <rms@gnu.org> writes:

> packages you used, so I don't know what they do.  More crucially, for
> most of them I can't tell whether they are part of Emacs or not.
> (They might be in NonGNU ELPA, or not connected with Emacs at all.)
> Could you please describe that status?

OK.  Here are the ingredients:

1. Emacs (you know this one)

2. lisp-data-mode (a part of core Emacs)
  
3. Eglot (already a part of core Emacs).  Eglot is an LSP client.  Read
   Emacs's manual on Eglot for what LSP is and what it does

4. clojure-lsp (not a part of Emacs) an MIT-licensed Language server.
   An external program, which most likely requires a Java runtime
   environment (JRE).  This external program is meant to run as an
   inferior process to Emacs.  Again, read Emacs's manual on Eglot to
   learn what a language server provides and how it communicates with
   Emacs.

You've read the full code to the proposed Clojure mode already.  Here it
is again:

  (define-derived-mode clojure-mode lisp-data-mode "Clojure" "Barebones Clojure")
  (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))

Now, if you only use ingredients 1 and 2 this brand new Clojure mode is
reasonably poor in functionality, but it's still useful.  Sexp-based
navigation and editing works as always, as does parenthesis matching and
highlighting.  There is very basic syntax highlighting.  Not much more,
because you are looking at Clojure code as Lisp-style forms (as happens
with all Lisps).

When you add ingredients 3 and 4 (Eglot and the clojure-lsp server), the
major mode is enhanced by them and becomes vastly more powerful.  You
get

a. at-point documentation in the style of Eldoc
b. cross-referencing capabilities (find definitions/references)
   in the style of 80's Lisp machines
c. in-buffer annotations of syntactic errors and other problems
d. context-sensitive completion
e. refactoring actions
f. probably a lot more stuff

I don't know how this compares to the NonGNU Clojure mode because I've
never really used it.  That NonGNU Clojure mode can certainly also be
enhanced with LSP

João

Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

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

> No idea if this works with the CIDER or SLIME backends for clojure.
> Don't ask me to test any more cause I've just uninstalled it all
> but any clojurians rading can have a go.

SLIME + swank-clojure has been dead for about 10 years now. Part of the reason we abandoned it and moved to nREPL + CIDER (or alternatively inf-clojure) is that Clojure is a Lisp, but it's not Common Lisp (e.g. CL packages are definitely not the same thing as Clojure namespaces). Trying to change Common Lisp tooling to fit Clojure was an exercise in frustration. Not to mention that many Clojure devs didn't really want to learn Common Lisp as well, just to contribute to something like SLIME/swank-clojure. 

It's funny that what you propose is more or less how things started 15 years ago. Originally clojure-mode was just a very thin layer on top of lisp-mode and we had tweaked slightly inferior-lisp-mode to be used with Clojure. Similarly with SLIME + swank-clojure. Gradually clojure-mode became its own thing and CIDER and inf-clojure were created from scratch to provide tooling that was tailored specifically to Clojure. I even have a very old talk on the topic, in case someone's interested in learning more https://www.youtube.com/watch?v=4X-1fJm25Ww

On Tue, Aug 29, 2023, at 11:09 PM, João Távora wrote:
> On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> wrote:
> >
> > 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
> 
> I don't know if this counts as "work on that" but here's two interesting lines
> Elisp:
> 
>   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
> "Barebones Clojure")
>   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
> 
> Since it is a lisp dialect many things works here, like indentation,
> symbol recognition, parenthesis balancing, C-M navigation, and thing-at-point.
> 
> And then there's LSP, right?
> 
> So I installed clojure-lsp from here:
> https://aur.archlinux.org/packages/clojure-lsp-bin
> 
> I created a hello world project with the "lein" tool, git init, found the
> src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
> at-point-documentation, diagnostics, lots of refactorings, completion, etc.
> 
> The thing that's a bit minimal is the syntax highlighting, but it's
> not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
> highlighting.  I have no idea what it takes to add TreeSitter support
> to such a bare-bones mode (but shouldn't it be really easy like mapping
> syntactic symbols to faces?)
> 
> No idea if this works with the CIDER or SLIME backends for clojure.
> Don't ask me to test any more cause I've just uninstalled it all
> but any clojurians rading can have a go.
> 
> João
> 
> 
> *Attachments:*
>  • clojure-mode-and-eglot.png

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 07:38, Eli Zaretskii wrote:

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

I'm not sure where I'm looking optimistic in the whole text.

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

If the cost is taking over entirely and dedicating 7+ hours every day to 
Emacs (as you said you do), this is obviously a prohibitive barrier. I 
don't think it's a reasonable ask when I'm just talking about using a 
real bug tracker, for example.

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

The existing tools "lack important features" to such a degree that it's 
not even funny. And the cost is not zero, the cost is the people that 
never set foot in our community.

> And none
> of the alternatives withstood the test of time and/or the magnitude of
> the project.

Should we mention other big projects? GNOME? Firefox? Emacs is complex 
but not that unique.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 14:07:29 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > 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.
> 
> If the cost is taking over entirely and dedicating 7+ hours every day to 
> Emacs (as you said you do), this is obviously a prohibitive barrier.

The real costs will not be known until you actually do it.  I hope
it's not more, but it could well be less, especially if enough people
come on board.

> I don't think it's a reasonable ask when I'm just talking about
> using a real bug tracker, for example.

It is definitely _un_reasonable to suggest/demand such changes when
you are doing nothing in practice towards that goal.

> > 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.
> 
> The existing tools "lack important features" to such a degree that it's 
> not even funny.

"Important" for whom?  We are doing a reasonable job with them, given
the available human resources, don't we?  Bugs are triaged,
investigated, and most of them fixed; patches are reviewed, commented,
and installed.  We'd love better tools -- who won't? -- but every tool
we examined until now had important gaps.

> And the cost is not zero, the cost is the people that never set foot
> in our community.

That cost is largely imaginary, and "never set foot" is an
exaggeration.  The same was said about the switch to Git, for example,
but the situation hasn't changed much, if the number of active
maintainers/developers is concerned.  It is better, but only slightly
so.

> > And none of the alternatives withstood the test of time and/or the
> > magnitude of the project.
> 
> Should we mention other big projects? GNOME? Firefox? Emacs is complex 
> but not that unique.

If someone has intimate knowledge about those, then yes, I'd be
interested to hear an objective comparison.  Until then, here are the
facts I could gather:

  . GNOME:
    - started in 1997
    - 2 million lines of C
    - release schedule: every 6 months
  . Firefox
    - started in 2002
    - 2.4 million lines of C, C++, and Javascript
    - release schedule: every 4 weeks
  . Emacs:
    - started in 1986
    - 3 million lines of C and Lisp
    - release schedule: roughly every 9 months

What is missing is the number of active developers in each project
(which requires a definition of "active developer"), the means and
tools they use for issue tracking, and whatever else is relevant.

So yes, Emacs _is_ larger and older.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

>   . Emacs:
>     - started in 1986
>     - 3 million lines of C and Lisp
>     - release schedule: roughly every 9 months

According to etc/HISTORY:

    GNU Emacs 13 (1985-03-20)
    Initial release announced on Usenet.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 27 Aug 2023 14:13:10 +0200
> Cc: Dmitry Gutov <dmitry@gutov.dev>, philipk@posteo.net, danny@dfreeman.email, 
> 	emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   . Emacs:
> >     - started in 1986
> >     - 3 million lines of C and Lisp
> >     - release schedule: roughly every 9 months
> 
> According to etc/HISTORY:
> 
>     GNU Emacs 13 (1985-03-20)
>     Initial release announced on Usenet.

Oops.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>   . Firefox
>     - started in 2002
>     - 2.4 million lines of C, C++, and Javascript
>     - release schedule: every 4 weeks

And before someone asserts that Firefox's rapid release schedule
is a testament to the efficiency of their development processes, I
submit that new issues arise with each new release of Firefox.

Each new release resolves old problems at the cost of new ones.  For
example, Firefox 116.0.3 appears to have overcome the sporadic input
lock-ups that abounded in Firefox 114.0, but now wedges when a window is
closed...

This phenomenon cannot be witnessed in Emacs releases.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  philipk@posteo.net,
>  danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> Date: Sun, 27 Aug 2023 20:22:31 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >   . Firefox
> >     - started in 2002
> >     - 2.4 million lines of C, C++, and Javascript
> >     - release schedule: every 4 weeks
> 
> And before someone asserts that Firefox's rapid release schedule
> is a testament to the efficiency of their development processes, I
> submit that new issues arise with each new release of Firefox.
> 
> Each new release resolves old problems at the cost of new ones.  For
> example, Firefox 116.0.3 appears to have overcome the sporadic input
> lock-ups that abounded in Firefox 114.0, but now wedges when a window is
> closed...

Producing a release tarball, with all the procedures around that,
takes about 2 hours on a relatively slow machine (a VM that advertises
just 4 execution units).  So theoretically, we could release Emacs
every day...

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 15:22, Po Lu wrote:
> Eli Zaretskii<eliz@gnu.org>  writes:
> 
>>    . Firefox
>>      - started in 2002
>>      - 2.4 million lines of C, C++, and Javascript
>>      - release schedule: every 4 weeks
> And before someone asserts that Firefox's rapid release schedule
> is a testament to the efficiency of their development processes, I
> submit that new issues arise with each new release of Firefox.

We could easily have more frequent releases, it's all in the hands of 
the maintainers, actually. Stability/velocity tradeoffs.

> Each new release resolves old problems at the cost of new ones.  For
> example, Firefox 116.0.3 appears to have overcome the sporadic input
> lock-ups that abounded in Firefox 114.0, but now wedges when a window is
> closed...
> 
> This phenomenon cannot be witnessed in Emacs releases.

Oh sure, we never have bugs or regressions in Emacs.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> We could easily have more frequent releases, it's all in the hands of
> the maintainers, actually. Stability/velocity tradeoffs.

Producing another atrocity following the footsteps of Mozilla?  No
thanks!

> Oh sure, we never have bugs or regressions in Emacs.

As a rule of thumb, we don't release Emacs with readily encountered bugs
that subject the user to irrecoverable hangs.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 15:57, Po Lu wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> We could easily have more frequent releases, it's all in the hands of
>> the maintainers, actually. Stability/velocity tradeoffs.
> Producing another atrocity following the footsteps of Mozilla?  No
> thanks!

Releasing a new Emacs, say, even 6 month won't suddenly turn it into a 
crashing mess. But we would get more and faster feedback for new 
features and changes.

That's the main issue why we have to drag on the release schedule: we 
don't get reports of regressions soon enough after introducing them. So 
we have to wait months for the users to try and report back.

How to change that? Either make releases more often, or make snapshot 
releases more prominent and easier to try, or improve the bug reporting 
experience so that more people do that. Or all of that together, of course.

In this thread specifically I'm talking about number 3.

>> Oh sure, we never have bugs or regressions in Emacs.
> As a rule of thumb, we don't release Emacs with readily encountered bugs
> that subject the user to irrecoverable hangs.

I wonder what wonderful curious bug reports we would also get if we had 
the number of users that Firefox has.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 27/08/2023 15:57, Po Lu wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> 
>>> We could easily have more frequent releases, it's all in the hands of
>>> the maintainers, actually. Stability/velocity tradeoffs.
>> Producing another atrocity following the footsteps of Mozilla?  No
>> thanks!
>
> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
> crashing mess. But we would get more and faster feedback for new
> features and changes.

BTW. what is the current system by which releases are cut?  I don't know
if the maintainers have a schedule or some general plan for internal
usage.  If not, it really wouldn't make much of a difference if releases
are made every six months or two years.

What might be nice would be if the release-dates could take the
release-dates of popular distributions such as Debian into account,
avoiding as was now the case, that Emacs 28.2 gets added to stable.  Of
course, this is not an easy thing to do, but I guess if the release
procedure would be more transparent, akin to [0], it might help.

[0] https://release.debian.org/bookworm/freeze_policy.html

> That's the main issue why we have to drag on the release schedule: we
> don't get reports of regressions soon enough after introducing
> them. So we have to wait months for the users to try and report back.
>
> How to change that? Either make releases more often, or make snapshot
> releases more prominent and easier to try, or improve the bug
> reporting experience so that more people do that. Or all of that
> together, of course.
>
> In this thread specifically I'm talking about number 3.
>
>>> Oh sure, we never have bugs or regressions in Emacs.
>> As a rule of thumb, we don't release Emacs with readily encountered bugs
>> that subject the user to irrecoverable hangs.
>
> I wonder what wonderful curious bug reports we would also get if we
> had the number of users that Firefox has.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
>   danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>   manuel.uberti@inventati.org
> Date: Sun, 27 Aug 2023 13:25:49 +0000
> 
> BTW. what is the current system by which releases are cut?  I don't know
> if the maintainers have a schedule or some general plan for internal
> usage.

I don't know how to answer this.

> What might be nice would be if the release-dates could take the
> release-dates of popular distributions such as Debian into account,

Why Debian?  And why should we take them into account, and not the
other way around?  I have never seen a Debian (or any other distro)
approach us asking when the next release is expected.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Philip Kaludercic <philipk@posteo.net>
>> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
>>   danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>>   manuel.uberti@inventati.org
>> Date: Sun, 27 Aug 2023 13:25:49 +0000
>> 
>> BTW. what is the current system by which releases are cut?  I don't know
>> if the maintainers have a schedule or some general plan for internal
>> usage.
>
> I don't know how to answer this.

How did you decide when to draw the line between Emacs 29 and Emacs 30?

>> What might be nice would be if the release-dates could take the
>> release-dates of popular distributions such as Debian into account,
>
> Why Debian?  

Because it is a fairly popular distribution on which a lot of other
distributions are based.  Also you'll frequently find it "in the wild",
and is a prominent "stable" distribution (CentOS or whatever the current
fork is) would be an alternative example.

>              And why should we take them into account, and not the
> other way around?  I have never seen a Debian (or any other distro)
> approach us asking when the next release is expected.

That is true, but I don't see any reason why there shouldn't be any
cooperation.  All the necessary information should be available here
https://tracker.debian.org/pkg/emacs.  One of the most active people
behind the package appears to be Sean Whitton, who does frequent the
mailing list.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: dmitry@gutov.dev,  luangruo@yahoo.com,  danny@dfreeman.email,
>   stefankangas@gmail.com,  emacs-devel@gnu.org,
>   manuel.uberti@inventati.org
> Date: Sun, 27 Aug 2023 14:13:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Philip Kaludercic <philipk@posteo.net>
> >> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
> >>   danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
> >>   manuel.uberti@inventati.org
> >> Date: Sun, 27 Aug 2023 13:25:49 +0000
> >> 
> >> BTW. what is the current system by which releases are cut?  I don't know
> >> if the maintainers have a schedule or some general plan for internal
> >> usage.
> >
> > I don't know how to answer this.
> 
> How did you decide when to draw the line between Emacs 29 and Emacs 30?

That's when the release branch is cut.  But doing so doesn't determine
the future release date, except very roughly.

When to cut the release branch is up to the maintainers, and IME the
reasons are not fixed.  The mount of new features and the time since
the last major release are important factors, though.

> >              And why should we take them into account, and not the
> > other way around?  I have never seen a Debian (or any other distro)
> > approach us asking when the next release is expected.
> 
> That is true, but I don't see any reason why there shouldn't be any
> cooperation.

Neither do I, but cooperation is a two-way street.

There's also a problem that we rarely can promise a certain release
date, because there are factors out of our control, such as the bugs
and regressions reported during pretest, the resources that can
dwindle due to "Real Life", etc.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.

All the other Clojure modes are on NonGNU ELPA already (clojure-mode, CIDER, inf-clojure, etc), so let's avoid philosophical discussions about the merits of X, Y and Z and just get this done, please. 

On Sun, Aug 27, 2023, at 7:04 PM, Eli Zaretskii wrote:
> > From: Philip Kaludercic <philipk@posteo.net>
> > Cc: dmitry@gutov.dev,  luangruo@yahoo.com,  danny@dfreeman.email,
> >   stefankangas@gmail.com,  emacs-devel@gnu.org,
> >   manuel.uberti@inventati.org
> > Date: Sun, 27 Aug 2023 14:13:56 +0000
> > 
> > Eli Zaretskii <eliz@gnu.org> writes:
> > 
> > >> From: Philip Kaludercic <philipk@posteo.net>
> > >> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
> > >>   danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
> > >>   manuel.uberti@inventati.org
> > >> Date: Sun, 27 Aug 2023 13:25:49 +0000
> > >> 
> > >> BTW. what is the current system by which releases are cut?  I don't know
> > >> if the maintainers have a schedule or some general plan for internal
> > >> usage.
> > >
> > > I don't know how to answer this.
> > 
> > How did you decide when to draw the line between Emacs 29 and Emacs 30?
> 
> That's when the release branch is cut.  But doing so doesn't determine
> the future release date, except very roughly.
> 
> When to cut the release branch is up to the maintainers, and IME the
> reasons are not fixed.  The mount of new features and the time since
> the last major release are important factors, though.
> 
> > >              And why should we take them into account, and not the
> > > other way around?  I have never seen a Debian (or any other distro)
> > > approach us asking when the next release is expected.
> > 
> > That is true, but I don't see any reason why there shouldn't be any
> > cooperation.
> 
> Neither do I, but cooperation is a two-way street.
> 
> There's also a problem that we rarely can promise a certain release
> date, because there are factors out of our control, such as the bugs
> and regressions reported during pretest, the resources that can
> dwindle due to "Real Life", etc.
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

With all the off-topic messages I missed the one saying that the package is now live on NonGNU ELPA, so you can ignore the last paragraph of my previous message. 

On Sun, Aug 27, 2023, at 8:38 PM, Bozhidar Batsov wrote:
> I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.
> 
> 
> All the other Clojure modes are on NonGNU ELPA already (clojure-mode, CIDER, inf-clojure, etc), so let's avoid philosophical discussions about the merits of X, Y and Z and just get this done, please.
> 
> On Sun, Aug 27, 2023, at 7:04 PM, Eli Zaretskii wrote:
>> > From: Philip Kaludercic <philipk@posteo.net>
>> > Cc: dmitry@gutov.dev,  luangruo@yahoo.com,  danny@dfreeman.email,
>> >   stefankangas@gmail.com,  emacs-devel@gnu.org,
>> >   manuel.uberti@inventati.org
>> > Date: Sun, 27 Aug 2023 14:13:56 +0000
>> > 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> > 
>> > >> From: Philip Kaludercic <philipk@posteo.net>
>> > >> Cc: Po Lu <luangruo@yahoo.com>,  Eli Zaretskii <eliz@gnu.org>,
>> > >>   danny@dfreeman.email,  stefankangas@gmail.com,  emacs-devel@gnu.org,
>> > >>   manuel.uberti@inventati.org
>> > >> Date: Sun, 27 Aug 2023 13:25:49 +0000
>> > >> 
>> > >> BTW. what is the current system by which releases are cut?  I don't know
>> > >> if the maintainers have a schedule or some general plan for internal
>> > >> usage.
>> > >
>> > > I don't know how to answer this.
>> > 
>> > How did you decide when to draw the line between Emacs 29 and Emacs 30?
>> 
>> That's when the release branch is cut.  But doing so doesn't determine
>> the future release date, except very roughly.
>> 
>> When to cut the release branch is up to the maintainers, and IME the
>> reasons are not fixed.  The mount of new features and the time since
>> the last major release are important factors, though.
>> 
>> > >              And why should we take them into account, and not the
>> > > other way around?  I have never seen a Debian (or any other distro)
>> > > approach us asking when the next release is expected.
>> > 
>> > That is true, but I don't see any reason why there shouldn't be any
>> > cooperation.
>> 
>> Neither do I, but cooperation is a two-way street.
>> 
>> There's also a problem that we rarely can promise a certain release
>> date, because there are factors out of our control, such as the bugs
>> and regressions reported during pretest, the resources that can
>> dwindle due to "Real Life", etc.
>> 
>> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 20:38:18 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email,
>  "Stefan Kangas" <stefankangas@gmail.com>,
>  "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a
> bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some
> push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure
> dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I
> want to do things. I've said a million times by now that I don't want contributors to have to deal with
> copyright agreements and with quirks/oddities in the Emacs development process. I believe that the
> maintainers who actually work on something should be allowed to decide how their projects get
> developed.

With such a hostile attitude, why do you expect us to be friendly?
"My way or the highway".

And I believe the Emacs maintainers also know what they are doing,
after so many years.  Please at least allow for that, if you want us
to do the same.

> All the other Clojure modes are on NonGNU ELPA already (clojure-mode, CIDER, inf-clojure, etc), so
> let's avoid philosophical discussions about the merits of X, Y and Z and just get this done, please. 

I guess "philosophical discussions" ("I've said a million times by now
that I don't want contributors to have to deal with copyright
agreements and with quirks/oddities in the Emacs development process")
are only allowed for you?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

What's hostile about my attitude exactly? Am I frustrated - yeah, for sure. If you feel my remark was hostile - my bad. But the whole process around the inclusion of clojure-ts-mode and before this adoc-mode (in limbo) and logview (also in limbo) got me quite upset and it's hard for me to be exactly excited about how things are happening with package submissions. You come with a simple request (let's include package X) and it turns into some time consuming conversation that's leading nowhere (as someone jumps to question your choice of repo, the purpose of the package, etc). I don't mind some degree of discussion on package inclusions, but I think almost always the discussions take some weird turns. We're all busy people and we have other work to do as well.

I'm pretty sure the single reason why MELPA has so much more packages than the official repos is that it's much easier to submit something there (not in terms of technical work needed, obviously creating the patch for ELPA is trivial). I find it weird that the people who try to submit something to the official Emacs repos are not supported more.  

> "My way or the highway".

At the risk of sounding hostile - that's the attitude of the Emacs team half the time, btw. (based on some 20 years of observations) And I'm obviously willing to play ball with Emacs's team's rules, as I'm trying to submit packages and I promote the submission of packages to the official repos (see https://emacsredux.com/blog/2021/08/11/submitting-a-package-to-nongnu-elpa/) 

> I guess "philosophical discussions" ("I've said a million times by now
> that I don't want contributors to have to deal with copyright
> agreements and with quirks/oddities in the Emacs development process")
> are only allowed for you?

What's this supposed to mean? I thought the conversation was off track and I had missed the message saying the patch was applied. I noted this in my next message.

Anyways, I don't want to drag this any longer. If someone's offended by anything I said - you have my apologies. But your responses certainly didn't feel friendly either. :-)

On Sun, Aug 27, 2023, at 8:58 PM, Eli Zaretskii wrote:
> > Date: Sun, 27 Aug 2023 20:38:18 +0300
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: dmitry@gutov.dev, luangruo@yahoo.com, danny@dfreeman.email,
> >  "Stefan Kangas" <stefankangas@gmail.com>,
> >  "Emacs Devel" <emacs-devel@gnu.org>,
> >  "Manuel Uberti" <manuel.uberti@inventati.org>
> > 
> > I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a
> > bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some
> > push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure
> > dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I
> > want to do things. I've said a million times by now that I don't want contributors to have to deal with
> > copyright agreements and with quirks/oddities in the Emacs development process. I believe that the
> > maintainers who actually work on something should be allowed to decide how their projects get
> > developed.
> 
> With such a hostile attitude, why do you expect us to be friendly?
> "My way or the highway".
> 
> And I believe the Emacs maintainers also know what they are doing,
> after so many years.  Please at least allow for that, if you want us
> to do the same.
> 
> > All the other Clojure modes are on NonGNU ELPA already (clojure-mode, CIDER, inf-clojure, etc), so
> > let's avoid philosophical discussions about the merits of X, Y and Z and just get this done, please. 
> 
> I guess "philosophical discussions" ("I've said a million times by now
> that I don't want contributors to have to deal with copyright
> agreements and with quirks/oddities in the Emacs development process")
> are only allowed for you?
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

Bozhidar Batsov <bozhidar@batsov.dev writes>:

> I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead.

Some of us believe that assigned packages are often better for the
overall health of the project, so we continue to argue for it.  It
would be irresponsible not to.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

Fair enough. Although experience shows that some packages with assigned copyright are barely maintained (even in Emacs's core), so obviously that's no silver bullet. 

My perspective is simple - don't mess with something that's working well. (e.g. you're getting many occasional contributors on GitHub and you want to keep it simple for them)

On Sun, Aug 27, 2023, at 9:32 PM, Stefan Kangas wrote:
> Bozhidar Batsov <bozhidar@batsov.dev writes>:
> 
> > I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead.
> 
> Some of us believe that assigned packages are often better for the
> overall health of the project, so we continue to argue for it.  It
> would be irresponsible not to.
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 21:43:44 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Philip Kaludercic" <philipk@posteo.net>,
>  "Dmitry Gutov" <dmitry@gutov.dev>, luangruo@yahoo.com, danny@dfreeman.email,
>  "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> My perspective is simple - don't mess with something that's working well. (e.g. you're getting many
> occasional contributors on GitHub and you want to keep it simple for them)

It will work better once it's part of Emacs, and we have numerous
examples to prove that.  The quality of the code becomes better, the
quality of documentation becomes better, the integration with other
Emacs facilities becomes better, and as a bonus you get some of our
loving care for your package even when you for some reasons of Real
Life become temporarily unavailable.

It's a net win for everyone.  And yes, it requires to invest some
effort on discussions, something not very efficient ones, such as this
one.  Do you really think we enjoy them? or participate without
investing time and efforts from our side?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Fair enough. Although experience shows that some packages with
> assigned copyright are barely maintained (even in Emacs's core), so
> obviously that's no silver bullet.

How did you come to this perspective?  For both core packages and ELPA
packages there is a lot of activity.  Of course there are stable and
complete packages, where there are only an infrequent need for bug
fixes, but that is a different issue.

> My perspective is simple - don't mess with something that's working
> well. 

Is this still related to the point of suggesting adding packages to
GNU ELPA or the core?  I am a bit disappointed to hear that being seen
as "messing with a workflow", that certainly isn't the intention, just
an offer that would ideally benefit everyone.

>       (e.g. you're getting many occasional contributors on GitHub and
> you want to keep it simple for them)

It is hard to judge, but it seems that there might be some truth to
this.  But this is an unfortunate circumstance, that should be changed,
if you ask me.  At the same time, one should keep in mind that
contributing via GitHub requires an account and a number of
complications, while mailing-lists (either here or via SourceHut) are
open to anyone with an email address -- something I consider to be a
major advantage.

My hope is that this is not an inherent issue of GitHub vs. something
else, and that commands like package-vc-prepare-patch could help make
contributing upstream changes easier for everyone.

> On Sun, Aug 27, 2023, at 9:32 PM, Stefan Kangas wrote:
>> Bozhidar Batsov <bozhidar@batsov.dev writes>:
>> 
>> > I have to say I'm a bit frustrated that every time someone wants
>> > to submit something to NonGNU ELPA there's some push to either
>> > submit to GNU ELPA or core instead.
>> 
>> Some of us believe that assigned packages are often better for the
>> overall health of the project, so we continue to argue for it.  It
>> would be irresponsible not to.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

Bozhidar Batsov <bozhidar@batsov.dev> writes:

> My perspective is simple - don't mess with something that's working well. (e.g. you're getting many occasional contributors on GitHub and you want to keep it simple for them)

I see where you're coming from with this, but you can absolutely
continue development on GitHub (or wherever), while merging
periodically back to Emacs core.  Org-mode follows this model, for
example.  As does transient, leueven-theme, modus-themes, and others.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> I believe this conversation has drifted a lot from the original topic
> (clojure-ts-mode). I have to say I'm a bit frustrated that every time
> someone wants to submit something to NonGNU ELPA there's some push to
> either submit to GNU ELPA or core instead. I've been maintaining
> almost all of the Clojure dev tooling for Emacs for over a decade, so
> I do believe that by now I know what I'm doing and how I want to do
> things. I've said a million times by now that I don't want
> contributors to have to deal with copyright agreements and with
> quirks/oddities in the Emacs development process. I believe that the
> maintainers who actually work on something should be allowed to decide
> how their projects get developed.

And we Emacs developers should have a say in how we plan to protect our
right to distribute copies or develop our project, no?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

> And we Emacs developers should have a say in how we plan to protect our
> right to distribute copies or develop our project, no?

Sure, but I fail to see to see how is this related to the inclusion of any third-party package in NonGNU ELPA. 

On Mon, Aug 28, 2023, at 3:31 AM, Po Lu wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > I believe this conversation has drifted a lot from the original topic
> > (clojure-ts-mode). I have to say I'm a bit frustrated that every time
> > someone wants to submit something to NonGNU ELPA there's some push to
> > either submit to GNU ELPA or core instead. I've been maintaining
> > almost all of the Clojure dev tooling for Emacs for over a decade, so
> > I do believe that by now I know what I'm doing and how I want to do
> > things. I've said a million times by now that I don't want
> > contributors to have to deal with copyright agreements and with
> > quirks/oddities in the Emacs development process. I believe that the
> > maintainers who actually work on something should be allowed to decide
> > how their projects get developed.
> 
> And we Emacs developers should have a say in how we plan to protect our
> right to distribute copies or develop our project, no?
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

> Sure, but I fail to see to see how is this related to the inclusion of
> any third-party package in NonGNU ELPA.

Because we have a right to advocate for options that we feel are to
Emacs's benefit, of which including new packages in GNU ELPA is one.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

If the Emacs team has so much misgivings about NonGNU ELPA perhaps they shouldn't have launched it to begin with. For me it's really weird that we have the option to use something (which supposedly exists to reduce friction) but someone constantly discourages us from doing so (which increases friction). Not a pleasant experience IMO. 

Anyways, I doubt anyone here will change their mind, so it's probably not worth discussing this any further. 

On Mon, Aug 28, 2023, at 7:51 AM, Po Lu wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > Sure, but I fail to see to see how is this related to the inclusion of
> > any third-party package in NonGNU ELPA.
> 
> Because we have a right to advocate for options that we feel are to
> Emacs's benefit, of which including new packages in GNU ELPA is one.
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 10:03:08 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Eli Zaretskii" <eliz@gnu.org>, "Philip Kaludercic" <philipk@posteo.net>,
>  "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>
> 
> If the Emacs team has so much misgivings about NonGNU ELPA perhaps they shouldn't have
> launched it to begin with.

We don't have any misgivings about NonGNU ELPA.  None whatsoever.  We
just think that having packages that provide features that Emacs
should have built in on NonGNU ELPA is sub-optimal.  So we try in
those cases to arrange for those packages to be part of the core.
Recent examples include Eglot and use-package.

> For me it's really weird that we have the option to use something (which
> supposedly exists to reduce friction) but someone constantly discourages us from doing so (which
> increases friction). Not a pleasant experience IMO. 

We tried to convince you and your colleagues to have these modes
included in Emacs.  You didn't agree.  We get that, although the
disagreement sounded strange to us.  That's all.  No need to represent
this as an unpleasant experience.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Sun, Aug 27, 2023 at 1:39 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.
>

If it wasn't for the copyright assignment requirement, there wouldn't
be a real issue blocking the incorporation of clojure-mode into core
emacs.  A core emacs developer could just maintain a (minor) fork of
the packages in emacs without any further discussion under the GPL.
No one involved in the primary development effort necessarily has to
be involved with the Emacs development process.

How much of your concern with obtaining copyright assignments is the
developer's willingness to give their own signature, and how much is
around the hassle of needing to involve their employer, even when
their contributions are not at all part of their employment?  I'd like
to get a sense of how much overreaching employment agreements are
impacting people's willingness or ability to contribute directly to
GNU software projects.   Otherwise, given rms is pushing for a
clojure-mode in core emacs, there would probably be volunteers who
could pursue getting the required copyright assignment paperwork from
the individual contributors.

Thanks,
Lynn

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Mon, 28 Aug 2023 11:22:21 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, Philip Kaludercic <philipk@posteo.net>, dmitry@gutov.dev, 
> 	luangruo@yahoo.com, danny@dfreeman.email, 
> 	Stefan Kangas <stefankangas@gmail.com>, Emacs Devel <emacs-devel@gnu.org>, 
> 	Manuel Uberti <manuel.uberti@inventati.org>
> 
> On Sun, Aug 27, 2023 at 1:39 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> > I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.
> >
> If it wasn't for the copyright assignment requirement, there wouldn't
> be a real issue blocking the incorporation of clojure-mode into core
> emacs.

That's a far cry from what the above actually says.  They also don't
want to deal with the "quirks/oddities" of the Emacs development
process.  They quite simply do NOT want clojure-mode to be part of
Emacs.  The CA part is just one part of that, and I'm guessing not the
main one.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Mon, Aug 28, 2023 at 12:22 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Mon, 28 Aug 2023 11:22:21 -0400
> > Cc: Eli Zaretskii <eliz@gnu.org>, Philip Kaludercic <philipk@posteo.net>, dmitry@gutov.dev,
> >       luangruo@yahoo.com, danny@dfreeman.email,
> >       Stefan Kangas <stefankangas@gmail.com>, Emacs Devel <emacs-devel@gnu.org>,
> >       Manuel Uberti <manuel.uberti@inventati.org>
> >
> > On Sun, Aug 27, 2023 at 1:39 PM Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> > > I believe this conversation has drifted a lot from the original topic (clojure-ts-mode). I have to say I'm a bit frustrated that every time someone wants to submit something to NonGNU ELPA there's some push to either submit to GNU ELPA or core instead. I've been maintaining almost all of the Clojure dev tooling for Emacs for over a decade, so I do believe that by now I know what I'm doing and how I want to do things. I've said a million times by now that I don't want contributors to have to deal with copyright agreements and with quirks/oddities in the Emacs development process. I believe that the maintainers who actually work on something should be allowed to decide how their projects get developed.
> > >
> > If it wasn't for the copyright assignment requirement, there wouldn't
> > be a real issue blocking the incorporation of clojure-mode into core
> > emacs.
>
> That's a far cry from what the above actually says.  They also don't
> want to deal with the "quirks/oddities" of the Emacs development
> process.  They quite simply do NOT want clojure-mode to be part of
> Emacs.  The CA part is just one part of that, and I'm guessing not the
> main one.

Whether or not a derivative of clojure-mode is incorporated into core
emacs is not the same question as whether the external clojure-mode
project is subsumed into core emacs development.  Given RMS's request
to include a clojure mode as a core emacs feature, the required
development effort could be spent either maintaining a derivative of
the existing software/manuals/etc that complies with the emacs
development process or developing the tooling from scratch.   Assuming
such development resources can be identified, then, as I wrote, the
only real issue blocking the incorporation of (some derivative of)
that software is the copyright assignment question, assuming any
trademark-type issues on the names of the packages are resolved.

Whatever authority Bozhidar has is over the project he's a maintainer
of, not over emacs or clojure features incorporated in it, or even,
frankly, the software produced by his project.  It is licensed as free
software, after all. The only meaningful constraint on the creation of
a fork, major or minor, of free software is the pain involved in
maintaining such forks.

I'm not sure why you would assume the project that
created/maintains/develops an external package would necessarily want
to contribute the additional labor required to participate in the
emacs development process.  If the emacs project wants to incorporate
such a package in core, it's not unreasonable to expect it to provide
the resources required rather than expecting the additional labor be
done by the external project.

Lynn

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

Lynn Winebarger <owinebar@gmail.com> writes:

>
> Whether or not a derivative of clojure-mode is incorporated into core
> emacs is not the same question as whether the external clojure-mode
> project is subsumed into core emacs development.  Given RMS's request
> to include a clojure mode as a core emacs feature, the required
> development effort could be spent either maintaining a derivative of
> the existing software/manuals/etc that complies with the emacs
> development process or developing the tooling from scratch.   Assuming
> such development resources can be identified, then, as I wrote, the
> only real issue blocking the incorporation of (some derivative of)
> that software is the copyright assignment question, assuming any
> trademark-type issues on the names of the packages are resolved.
>
> Whatever authority Bozhidar has is over the project he's a maintainer
> of, not over emacs or clojure features incorporated in it, or even,
> frankly, the software produced by his project.  It is licensed as free
> software, after all. The only meaningful constraint on the creation of
> a fork, major or minor, of free software is the pain involved in
> maintaining such forks.
>
> I'm not sure why you would assume the project that
> created/maintains/develops an external package would necessarily want
> to contribute the additional labor required to participate in the
> emacs development process.  If the emacs project wants to incorporate
> such a package in core, it's not unreasonable to expect it to provide
> the resources required rather than expecting the additional labor be
> done by the external project.
>
> Lynn

I would once again like to ask, who is asking for this? RMS isn't a
clojure developer, and is hardly in a position to speak on behalf of
clojure developers. Why would we go through through the trouble
maintaining a fork of clojure mode when the maintainers are perfectly
content to do all the work outside of Emacs with their own release
schedule, their own development process, and with the clojure
development community fully in support of the current state of the
clojure ecosystem within Emacs? Having a clojure-mode in the core of
emacs without the buy in of the current maintainers is going to fracture
the community and confuse people. Philip made a pretty convincing
argument about this earlier in the thread in how this would disrupt
packages that use clojure-mode like cider and inf-clojure (among
others).

Sure you can theoretically gather up signatures, find someone to
maintain in the core, and push it out in the next release. It will still
be confusing to users, and a slap in the face to the current maintainers
who have asked that this NOT be done. If clojure-mode ever gets into the
core it should be done with everyone's buy in, and you don't have that.

-- 
Danny Freeman

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Mon, Aug 28, 2023 at 10:15 PM Danny Freeman <danny@dfreeman.email> wrote:

> I would once again like to ask, who is asking for this?

Noone.  Noone asked that clojure stuff be forked or anything like that.
Just the core maintainers and the leader of the FSF project thought
it would be good if the flagship FSF project Emacs had some clojure
support under its umbrella, and invited your project to come on board.
Many third-party projects that benefit from the incalculable amount
of work put in by FSF's developers and volunteers who have signed CAs
throughout almost 4 decades would find this invitation a privilege,
maybe in recognition that united we stand, divided we fall.  But noone,
absolutely noone, can force you or coerce you to accept the invitation
or even stand in the way if you or Bozidhar want to pursue other
paths.  And noone has done that.  So no need for persecutory delusions
that the FSF secret police is going to extort CAs from your developers
to fork and undermine your project.  Remember that NonGNU Elpa was
created by Emacs devs just to service projects like yours.  And your
original request has been serviced already, free of charge.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Danny Freeman]

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

> On Mon, Aug 28, 2023 at 10:15 PM Danny Freeman <danny@dfreeman.email> wrote:
>
>> I would once again like to ask, who is asking for this?
>
> Noone.  Noone asked that clojure stuff be forked or anything like that.

People are literally suggesting exactly this in the comments above.

> Just the core maintainers and the leader of the FSF project thought
> it would be good if the flagship FSF project Emacs had some clojure
> support under its umbrella, and invited your project to come on board.

I'm not taking any issue with this. I was more than happy to answer
questions about it at the start of this thread. If I were developing
this on my own I would probably accept that invitation, but I'm not.

> Many third-party projects that benefit from the incalculable amount
> of work put in by FSF's developers and volunteers who have signed CAs
> throughout almost 4 decades would find this invitation a privilege,
> maybe in recognition that united we stand, divided we fall.  But noone,
> absolutely noone, can force you or coerce you to accept the invitation
> or even stand in the way if you or Bozidhar want to pursue other
> paths.  And noone has done that.  So no need for persecutory delusions
> that the FSF secret police is going to extort CAs from your developers
> to fork and undermine your project.

The reason I wrote that is because in the message directly before mine
from Lynn:

>> Whether or not a derivative of clojure-mode is incorporated into core
>> emacs is not the same question as whether the external clojure-mode
>> project is subsumed into core emacs development.  Given RMS's request
>> to include a clojure mode as a core emacs feature, the required
>> development effort could be spent either maintaining a derivative of
>> the existing software/manuals/etc that complies with the emacs
>> development process or developing the tooling from scratch.   Assuming
>> such development resources can be identified, then, as I wrote, the
>> only real issue blocking the incorporation of (some derivative of)
>> that software is the copyright assignment question, assuming any
>> trademark-type issues on the names of the packages are resolved.

is suggesting that someone could take on the task of obtaining CAs and
forking. All I am asking is that NOT be done, not having "delusions".

> Remember that NonGNU Elpa was
> created by Emacs devs just to service projects like yours.  And your
> original request has been serviced already, free of charge.
>
> João

And I am very grateful my project was accepted into NonGNU Elpa. But now
I am trying to act in what I believe are the best interests of
clojure-mode by avoiding a fork.

-- 
Danny Freeman

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

Danny Freeman <danny@dfreeman.email> writes:

> João Távora <joaotavora@gmail.com> writes:
>
>> On Mon, Aug 28, 2023 at 10:15 PM Danny Freeman <danny@dfreeman.email> wrote:
>>
>>> I would once again like to ask, who is asking for this?
>>
>> Noone.  Noone asked that clojure stuff be forked or anything like that.
>
> People are literally suggesting exactly this in the comments above.

Lynn indeed suggested something like this, pulled that imaginary and
incendiary scenario from thin air, which was unfortunate.  But added
fuel to a fire and confouded him with RMS, writing

   who is asking for this? RMS isn't a
   clojure developer, and is hardly in a position to speak on behalf of
   clojure developers.

RMS didn't do that.  Noone did that.  Not to mention one doesn't have to
be a XYZ deveoper to desire XYZ support in Emacs.  So let's just stop
this escalation of imaginary threats.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Mon, Aug 28, 2023 at 6:14 PM Danny Freeman <danny@dfreeman.email> wrote:
> João Távora <joaotavora@gmail.com> writes:
> > On Mon, Aug 28, 2023 at 10:15 PM Danny Freeman <danny@dfreeman.email> wrote:
> >
> >> I would once again like to ask, who is asking for this?
> >
> > Noone.  Noone asked that clojure stuff be forked or anything like that.

You both are reading far more into the term "fork" than there is.
"Fork" does not imply "schism", at least in modern usage.  A fork is
just a downstream repo that independently maintains a set of changes
relative to an upstream project.  AFAIK, every linux distribution
maintains its own fork of GNU emacs in the form of a patchset, and
maintains those forks of older versions with bug and security fixes
long after GNU emacs has stopped supporting them.  Go to any git-based
forge and there's probably a "fork" button for any given repo.
Personally, I would prefer "fork" not be considered to refer to
projects that have diverged to the point of being unmanageable.

> People are literally suggesting exactly this in the comments above.

In the sense that core emacs could distribute a downstream version of
clojure-mode (or whatever) in the same way linux distributions provide
forks of major software packages modified to suit their preferred
tooling, processes, principles, etc, yes.  I don't see a GNU emacs
developer integrating an upstream package into the Emacs project as
particularly different from a linux distribution customizing the free
software it bundles, as long as there is no misrepresentation as to
its provenance or trademark-type concerns.  I really do not get how
people publish software under a free license while retaining a
proprietary view of people publishing variations of their work.

But don't take my views as representative in any way of the emacs
project.  I just wrote what I thought were the implications of RMS's
email, versus Eli's conclusion.  If the issue is only the effort
involved in obtaining CA's and dealing with the emacs development
process, that does not intrinsically rule out the emacs project as a
downstream publisher of clojure-mode.  I only wrote that I think it's
fair for clojure-mode developers to expect the emacs project to
provide that labor, where Eli's position seemed to me to be that the
upstream project would be required to be swallowed into the emacs
project.

> it would be good if the flagship FSF project Emacs had some clojure
> > support under its umbrella, and invited your project to come on board.
>
> I'm not taking any issue with this. I was more than happy to answer
> questions about it at the start of this thread. If I were developing
> this on my own I would probably accept that invitation, but I'm not.
>
> > Many third-party projects that benefit from the incalculable amount
> > of work put in by FSF's developers and volunteers who have signed CAs
> > throughout almost 4 decades would find this invitation a privilege,
> > maybe in recognition that united we stand, divided we fall.  But noone,
> > absolutely noone, can force you or coerce you to accept the invitation
> > or even stand in the way if you or Bozidhar want to pursue other
> > paths.  And noone has done that.  So no need for persecutory delusions
> > that the FSF secret police is going to extort CAs from your developers
> > to fork and undermine your project.

Unless you read something different than I did, RMS's emails
explicitly requested a built-in clojure mode, whether that was derived
from the existing external package or not.  I agree there is no
attempt to "extort" CAs from the developers of the existing external
package.

>
> The reason I wrote that is because in the message directly before mine
> from Lynn:
>
> >> Whether or not a derivative of clojure-mode is incorporated into core
> >> emacs is not the same question as whether the external clojure-mode
> >> project is subsumed into core emacs development.  Given RMS's request
> >> to include a clojure mode as a core emacs feature, the required
> >> development effort could be spent either maintaining a derivative of
> >> the existing software/manuals/etc that complies with the emacs
> >> development process or developing the tooling from scratch.   Assuming
> >> such development resources can be identified, then, as I wrote, the
> >> only real issue blocking the incorporation of (some derivative of)
> >> that software is the copyright assignment question, assuming any
> >> trademark-type issues on the names of the packages are resolved.
>
> is suggesting that someone could take on the task of obtaining CAs and
> forking. All I am asking is that NOT be done, not having "delusions".

I just said "derivative of", which might only mean an older version
with minor modifications required to conform to GNU coding standards,
like not referencing non-free software, etc.  If that would entail a
schism-level "fork" (in your terms), then it would probably not be
worth the effort.  Also, presumably if Bozidhar and other major
contributors were not willing to sign a CA, it (the incorporation of
the existing clojure-mode package in core emacs) would probably be a
moot issue anyway.

That being said, any contributor who has retained their copyright
doesn't need permission from anyone to sign a CA with the FSF or
anyone else for that matter.  I'm not sure why anyone would have an
objection to that.

>
> > Remember that NonGNU Elpa was
> > created by Emacs devs just to service projects like yours.  And your
> > original request has been serviced already, free of charge.
> >
> > João
>
> And I am very grateful my project was accepted into NonGNU Elpa. But now
> I am trying to act in what I believe are the best interests of
> clojure-mode by avoiding a fork.

Back to the original point, then, RMS requested emacs incorporate a
built-in clojure mode.  The members of the emacs project have every
bit as much right to provide a built-in clojure mode as the
contributors to the clojure-emacs project have to develop that project
as they see fit.  If anything, Bozhidar's standing to object to the
course of development of the GNU Emacs project has been severely
diminished by his explicit rejection of the invitation to participate
in it.  There is neither conflict nor coercion in either of these
positions.  I think the emacs developers have been pretty gracious
about it, really.

Lynn

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Mon, 28 Aug 2023 16:03:27 -0400
> Cc: bozhidar@batsov.dev, philipk@posteo.net, dmitry@gutov.dev, 
>  luangruo@yahoo.com, danny@dfreeman.email, stefankangas@gmail.com, 
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> Whatever authority Bozhidar has is over the project he's a maintainer
> of, not over emacs or clojure features incorporated in it, or even,
> frankly, the software produced by his project.  It is licensed as free
> software, after all. The only meaningful constraint on the creation of
> a fork, major or minor, of free software is the pain involved in
> maintaining such forks.

That's formally true, but doing this over the objections of the
original authors would be IMO rude, and I would not agree to that
lightly.

> I'm not sure why you would assume the project that
> created/maintains/develops an external package would necessarily want
> to contribute the additional labor required to participate in the
> emacs development process.  If the emacs project wants to incorporate
> such a package in core, it's not unreasonable to expect it to provide
> the resources required rather than expecting the additional labor be
> done by the external project.

The Emacs project can and does provide additional labor, but not when
the authors object to including their package.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

> That's formally true, but doing this over the objections of the
> original authors would be IMO rude, and I would not agree to that
> lightly.

I agree that'd be rude. I also think that'd be quite confusing for the end users and will make some of the operations (e.g. submission of bugs) a total mess. Neither the Clojure, nor the Emacs communities are big enough to engage lightly in time-wasting activities. 

And, I'll say it once more - in case this was missed in the conversations. Personal misgivings about the mechanics of Emacs's development aside, I think it's not prudent to keep growing its core, which is already huge. Obviously it's up to the Emacs developers to decide what to do, but I'd be moving more things into packages and bundling less things with Emacs. You might have seen this trend in some programming languages - e.g. Ruby has slimmed down its core a lot and this helped channel the efforts of the core team. 

I think by now pretty much every user of an editor or a programming language is used to installing packages to augment the core functionality, so I'm not buying the argument that we need to have more things OOTB. IMO the core of Emacs should consist of fewer, but truly essential packages. 

Someone mentioned it'd be nice if Emacs suggested packages to install for certain (unsupported OOTB) file types and I think that'd be a nice way to help with package discovery. Perhaps packages can just mention this in their metadata? 

On Tue, Aug 29, 2023, at 5:27 AM, Eli Zaretskii wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Mon, 28 Aug 2023 16:03:27 -0400
> > Cc: bozhidar@batsov.dev, philipk@posteo.net, dmitry@gutov.dev, 
> >  luangruo@yahoo.com, danny@dfreeman.email, stefankangas@gmail.com, 
> >  emacs-devel@gnu.org, manuel.uberti@inventati.org
> > 
> > Whatever authority Bozhidar has is over the project he's a maintainer
> > of, not over emacs or clojure features incorporated in it, or even,
> > frankly, the software produced by his project.  It is licensed as free
> > software, after all. The only meaningful constraint on the creation of
> > a fork, major or minor, of free software is the pain involved in
> > maintaining such forks.
> 
> That's formally true, but doing this over the objections of the
> original authors would be IMO rude, and I would not agree to that
> lightly.
> 
> > I'm not sure why you would assume the project that
> > created/maintains/develops an external package would necessarily want
> > to contribute the additional labor required to participate in the
> > emacs development process.  If the emacs project wants to incorporate
> > such a package in core, it's not unreasonable to expect it to provide
> > the resources required rather than expecting the additional labor be
> > done by the external project.
> 
> The Emacs project can and does provide additional labor, but not when
> the authors object to including their package.
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> That's formally true, but doing this over the objections of the
>> original authors would be IMO rude, and I would not agree to that
>> lightly.
>
> I agree that'd be rude. I also think that'd be quite confusing for the
> end users and will make some of the operations (e.g. submission of
> bugs) a total mess. Neither the Clojure, nor the Emacs communities are
> big enough to engage lightly in time-wasting activities.
>
> And, I'll say it once more - in case this was missed in the
> conversations. Personal misgivings about the mechanics of Emacs's
> development aside, I think it's not prudent to keep growing its core,
> which is already huge. Obviously it's up to the Emacs developers to
> decide what to do, but I'd be moving more things into packages and
> bundling less things with Emacs. You might have seen this trend in
> some programming languages - e.g. Ruby has slimmed down its core a lot
> and this helped channel the efforts of the core team.
>
> I think by now pretty much every user of an editor or a programming
> language is used to installing packages to augment the core
> functionality, so I'm not buying the argument that we need to have
> more things OOTB. IMO the core of Emacs should consist of fewer, but
> truly essential packages.
>
> Someone mentioned it'd be nice if Emacs suggested packages to install
> for certain (unsupported OOTB) file types and I think that'd be a nice
> way to help with package discovery. Perhaps packages can just mention
> this in their metadata?

Most of the time this would be duplicating information, since most
packages already have a

  ;;;###autoload
  (add-to-list 'auto-mode-alist '("\\.foo\\'" . foo-mode))

in their body somewhere, that can be scraped.  I proposed doing this in
the context of updating the archive-contents file format to address a
few issues that people have been raising for a couple of years now.

Of course this doesn't work when users work in environments without any
internet access or their access to {GNU,NonGNU} ELPA is restricted by a
firewall.  I don't know if it is points like these that motivate adding
functionality directly to the core?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Tue, 29 Aug 2023 10:33:59 +0300
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Philip Kaludercic" <philipk@posteo.net>,
>  "Dmitry Gutov" <dmitry@gutov.dev>, "Po Lu" <luangruo@yahoo.com>,
>  "Danny Freeman" <danny@dfreeman.email>,
>  "Stefan Kangas" <stefankangas@gmail.com>,
>  "Emacs Devel" <emacs-devel@gnu.org>,
>  "Manuel Uberti" <manuel.uberti@inventati.org>
> 
> And, I'll say it once more - in case this was missed in the conversations. Personal misgivings about
> the mechanics of Emacs's development aside, I think it's not prudent to keep growing its core, which
> is already huge. Obviously it's up to the Emacs developers to decide what to do, but I'd be moving
> more things into packages and bundling less things with Emacs. You might have seen this trend in
> some programming languages - e.g. Ruby has slimmed down its core a lot and this helped channel
> the efforts of the core team. 

Please don't go that way, and please don't bring that into this
(already troubles enough) thread.  As you say, it is the prerogative
of the Emacs project to decide how lean-and-mean or how bloated it
wants to be.  You are entitled to your differing opinions, but as you
ask us to leave the package management to you, please be fair and
leave the management of the Emacs project to us.  It is unlikely that
we will change our minds just to accommodate your philosophy.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Bozhidar Batsov]

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

Fair enough. 

On Tue, Aug 29, 2023, at 3:04 PM, Eli Zaretskii wrote:
> > Date: Tue, 29 Aug 2023 10:33:59 +0300
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: "Philip Kaludercic" <philipk@posteo.net>,
> >  "Dmitry Gutov" <dmitry@gutov.dev>, "Po Lu" <luangruo@yahoo.com>,
> >  "Danny Freeman" <danny@dfreeman.email>,
> >  "Stefan Kangas" <stefankangas@gmail.com>,
> >  "Emacs Devel" <emacs-devel@gnu.org>,
> >  "Manuel Uberti" <manuel.uberti@inventati.org>
> > 
> > And, I'll say it once more - in case this was missed in the conversations. Personal misgivings about
> > the mechanics of Emacs's development aside, I think it's not prudent to keep growing its core, which
> > is already huge. Obviously it's up to the Emacs developers to decide what to do, but I'd be moving
> > more things into packages and bundling less things with Emacs. You might have seen this trend in
> > some programming languages - e.g. Ruby has slimmed down its core a lot and this helped channel
> > the efforts of the core team. 
> 
> Please don't go that way, and please don't bring that into this
> (already troubles enough) thread.  As you say, it is the prerogative
> of the Emacs project to decide how lean-and-mean or how bloated it
> wants to be.  You are entitled to your differing opinions, but as you
> ask us to leave the package management to you, please be fair and
> leave the management of the Emacs project to us.  It is unlikely that
> we will change our minds just to accommodate your philosophy.
> 
> 

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Richard Stallman]

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

  > How much of your concern with obtaining copyright assignments is the
  > developer's willingness to give their own signature, and how much is
  > around the hassle of needing to involve their employer, even when
  > their contributions are not at all part of their employment?

First, I have to point out that they are both necessary.  The human
authors cannot assign the copyright if an employer can legally claim
it.  By signing the employer disclaimer, the employer waives the
possibility of claiming the copyright, clearing the way for the
authors to assign it.

In practice, cases where the employer won't sign are a tiny fraction.
Some employers object to parts of the text, but we discuss it with them
and can usually reach agreement.

That doesn't seem to be relevant to the clojure-mode situation,
we now know.  The developers objections are others.

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Wed, Aug 30, 2023 at 10:08 PM Richard Stallman <rms@gnu.org> wrote:
>   > How much of your concern with obtaining copyright assignments is the
>   > developer's willingness to give their own signature, and how much is
>   > around the hassle of needing to involve their employer, even when
>   > their contributions are not at all part of their employment?
>
> First, I have to point out that they are both necessary.  The human
> authors cannot assign the copyright if an employer can legally claim
> it.  By signing the employer disclaimer, the employer waives the
> possibility of claiming the copyright, clearing the way for the
> authors to assign it.

I don't dispute the prudence of the FSF's approach.  I don't believe
the enforceability of employment agreements for at-will employees
claiming assignment of legal rights to the product of work outside of
those produced "in the course of employment" has been established
conclusively.  Unfortunately, the prevalence of arbitration agreements
makes it difficult to see the issue being litigated in a forum that
establishes precedent any time soon.  To me, such agreements should
fall afoul of prohibitions against conditioning employment on
"kickbacks" - which is simply the requirement that the employee give
the employer (or any other person) any "thing of value" (e.g. property
of the employee).

> In practice, cases where the employer won't sign are a tiny fraction.
> Some employers object to parts of the text, but we discuss it with them
> and can usually reach agreement.

I suspect there is a substantial selection bias in the first
statement.  That is, the authors who ask for a copyright assignment
are primarily those who already have reason to believe their employers
will be amenable to it.  It's difficult to measure the number of
developers who publish free software who *might* contribute directly
but believe their employers will not agree, or simply do not want to
involve their employers in their private hobbies, much less the number
of people who are wholly deterred from even writing software that
might be published under a free license because their employer might
simply dislike their doing so, whether the employer has an enforceable
right to .that copyright or simply intends to demand it regardless of
the enforceability of the claim.  In practice, the purpose of such
expansive claims to work produced outside the course of employment is
primarily to discourage any productive effort outside of that done for
the employer.

> That doesn't seem to be relevant to the clojure-mode situation,
> we now know.  The developers objections are others.

I'm still not clear to me what the objections really are, if the labor
of obtaining the CAs and adapting a version to the emacs development
process were provided.  This is assuming that the GNU emacs project
won't privilege an external project for claiming a standard naming
pattern such as "<language>-mode" with no intention of contributing it
to the project, and will simply use the name "clojure-mode" as it
deems appropriate.  It doesn't seem the current situation was
anticipated.

Lynn

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 19:04, Eli Zaretskii wrote:

>> How did you decide when to draw the line between Emacs 29 and Emacs 30?
> 
> That's when the release branch is cut.  But doing so doesn't determine
> the future release date, except very roughly.
> 
> When to cut the release branch is up to the maintainers, and IME the
> reasons are not fixed.  The mount of new features and the time since
> the last major release are important factors, though.

There is a fair amount of leeway and personal judgment in when to 
consider a release to be "ready", so it's possible that we could try.

>>>               And why should we take them into account, and not the
>>> other way around?  I have never seen a Debian (or any other distro)
>>> approach us asking when the next release is expected.
>>
>> That is true, but I don't see any reason why there shouldn't be any
>> cooperation.
> 
> Neither do I, but cooperation is a two-way street.
> 
> There's also a problem that we rarely can promise a certain release
> date, because there are factors out of our control, such as the bugs
> and regressions reported during pretest, the resources that can
> dwindle due to "Real Life", etc.

If we do manage to release Emacs versions (most or all) before Debian's 
cutoff dates, that would mean larger user base and more testing to be 
done on the release right away. Perhaps if we fall into cadence, some 
people would then come regularly from Debian's side and test the 
pretests in advance, to check that everything is in order.

That's a possible "two way street", but it's not something that can be 
agreed to beforehand, I guess, not in the least because we won't want to 
give any guarantees at the start.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 00:22:43 +0300
> Cc: luangruo@yahoo.com, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 19:04, Eli Zaretskii wrote:
> 
> >> How did you decide when to draw the line between Emacs 29 and Emacs 30?
> > 
> > That's when the release branch is cut.  But doing so doesn't determine
> > the future release date, except very roughly.
> > 
> > When to cut the release branch is up to the maintainers, and IME the
> > reasons are not fixed.  The mount of new features and the time since
> > the last major release are important factors, though.
> 
> There is a fair amount of leeway and personal judgment in when to 
> consider a release to be "ready", so it's possible that we could try.

We could try what?

> > There's also a problem that we rarely can promise a certain release
> > date, because there are factors out of our control, such as the bugs
> > and regressions reported during pretest, the resources that can
> > dwindle due to "Real Life", etc.
> 
> If we do manage to release Emacs versions (most or all) before Debian's 
> cutoff dates, that would mean larger user base and more testing to be 
> done on the release right away. Perhaps if we fall into cadence, some 
> people would then come regularly from Debian's side and test the 
> pretests in advance, to check that everything is in order.
> 
> That's a possible "two way street", but it's not something that can be 
> agreed to beforehand, I guess, not in the least because we won't want to 
> give any guarantees at the start.

I don't think anyone will argue with the advantages.  The problems are
much more practical.  We are all volunteers here, so promises of a
release date are notoriously unreliable.  I intended to have the first
pretest of Emacs 29 in February, but only succeeded to get it out in
April, for reasons that were completely out of my control.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 16:12:00 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 15:57, Po Lu wrote:
> > Dmitry Gutov<dmitry@gutov.dev>  writes:
> > 
> >> We could easily have more frequent releases, it's all in the hands of
> >> the maintainers, actually. Stability/velocity tradeoffs.
> > Producing another atrocity following the footsteps of Mozilla?  No
> > thanks!
> 
> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a 
> crashing mess.

We already do it, or thereabouts.  Check out the last part of
etc/HISTORY.

> But we would get more and faster feedback for new features and
> changes.

Maybe, maybe not.  See below.

> That's the main issue why we have to drag on the release schedule: we 
> don't get reports of regressions soon enough after introducing them. So 
> we have to wait months for the users to try and report back.
> 
> How to change that? Either make releases more often, or make snapshot 
> releases more prominent and easier to try, or improve the bug reporting 
> experience so that more people do that. Or all of that together, of course.

Are you sure this will help?  Here's a typical case:

  https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html

This guy just recently upgraded to Emacs 29, and is reporting a
significant issue only now, a month after Emacs 29.1 was released.

I've seen similar things many times: people upgrade to a new Emacs
version months, and sometimes years, after that version was released.
Try to collect feedback for a release quickly given this upgrade
schedule.

> I wonder what wonderful curious bug reports we would also get if we had 
> the number of users that Firefox has.

If we never do anything, we will keep wondering, and it will remain
forever in the "he said, she said" department.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> This guy just recently upgraded to Emacs 29, and is reporting a
> significant issue only now, a month after Emacs 29.1 was released.

This seems to speak in favor of more frequent minor releases.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Sun, 27 Aug 2023 16:03:13 +0200
> Cc: Dmitry Gutov <dmitry@gutov.dev>, luangruo@yahoo.com, philipk@posteo.net, 
> 	danny@dfreeman.email, emacs-devel@gnu.org, manuel.uberti@inventati.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > This guy just recently upgraded to Emacs 29, and is reporting a
> > significant issue only now, a month after Emacs 29.1 was released.
> 
> This seems to speak in favor of more frequent minor releases.

I don't see how.  We need to look for the reports about regressions in
the previous release, and when we think we have seen enough, make a
minor release.  If feedback takes months to get to us, we either
release blind with the same regressions (about which we haven't heard
yet), or wait longer.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> This seems to speak in favor of more frequent minor releases.
>
> I don't see how.  We need to look for the reports about regressions in
> the previous release, and when we think we have seen enough, make a
> minor release.  If feedback takes months to get to us, we either
> release blind with the same regressions (about which we haven't heard
> yet), or wait longer.

Is there any downside holding on a minor release if _some_ bugs are
already fixed, even if others are not yet?

What I recently did for Org's bugfix releases was:
1. Every two weeks I see if some bug fixes landed on bugfix branch
2. If there are, I just tag a bugfix release

Nothing major is ever landed on Org's bugfix (AFAIU, it is similar for
Emacs' release branch), so it generally seems safe to do minor releases
frequently.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Stefan Kangas <stefankangas@gmail.com>, dmitry@gutov.dev,
>  luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> Date: Thu, 31 Aug 2023 10:11:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> This seems to speak in favor of more frequent minor releases.
> >
> > I don't see how.  We need to look for the reports about regressions in
> > the previous release, and when we think we have seen enough, make a
> > minor release.  If feedback takes months to get to us, we either
> > release blind with the same regressions (about which we haven't heard
> > yet), or wait longer.
> 
> Is there any downside holding on a minor release if _some_ bugs are
> already fixed, even if others are not yet?

What would be the point?  People who want something like that can
simply build the Git release branch, where we fix bugs every few days.
A minor release is more than just code with some bugs fixed: it (a)
has no known bugs except those whose fix is too risky, and (b) was
tested in the wild during a pretest.

> What I recently did for Org's bugfix releases was:
> 1. Every two weeks I see if some bug fixes landed on bugfix branch
> 2. If there are, I just tag a bugfix release

If all you do is tag a commit, then that's not what constitutes a
minor release in Emacs.  We do much more than just tagging.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is there any downside holding on a minor release if _some_ bugs are
>> already fixed, even if others are not yet?
>
> What would be the point?  People who want something like that can
> simply build the Git release branch, where we fix bugs every few days.

For Org, a number of people just update from ELPA. Releasing benefits
these users. 

> A minor release is more than just code with some bugs fixed: it (a)
> has no known bugs except those whose fix is too risky, and (b) was
> tested in the wild during a pretest.

You are right. To clarify: I am talking about _bugfix_ releases. Like
Org 9.6.7 -> 9.6.8. Emacs does not have those, currently.

>> What I recently did for Org's bugfix releases was:
>> 1. Every two weeks I see if some bug fixes landed on bugfix branch
>> 2. If there are, I just tag a bugfix release
>
> If all you do is tag a commit, then that's not what constitutes a
> minor release in Emacs.  We do much more than just tagging.

So, what about "bugfix" releases? AFAIU, it is mostly producing a
release tarball + waiting for Emacs to be packaged on major GNU/Linux
distributions. The timing would be anything acceptable for the latter
task, which appears to be a bottleneck in such scenario.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 10:32:07 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Is there any downside holding on a minor release if _some_ bugs are
> >> already fixed, even if others are not yet?
> >
> > What would be the point?  People who want something like that can
> > simply build the Git release branch, where we fix bugs every few days.
> 
> For Org, a number of people just update from ELPA. Releasing benefits
> these users. 

I don't see how is that different from updating from Git.

> > A minor release is more than just code with some bugs fixed: it (a)
> > has no known bugs except those whose fix is too risky, and (b) was
> > tested in the wild during a pretest.
> 
> You are right. To clarify: I am talking about _bugfix_ releases. Like
> Org 9.6.7 -> 9.6.8. Emacs does not have those, currently.

If bugfix releases just fix bugs, then basically every commit on the
release branch is such a "release", because we only fix bugs there.

And don't forget that minor releases affect downstream distros: they
need to package a new release, patch it, announce it, manage it, etc.
It's very different from a single package, even a package that is as
large as Org.

> >> What I recently did for Org's bugfix releases was:
> >> 1. Every two weeks I see if some bug fixes landed on bugfix branch
> >> 2. If there are, I just tag a bugfix release
> >
> > If all you do is tag a commit, then that's not what constitutes a
> > minor release in Emacs.  We do much more than just tagging.
> 
> So, what about "bugfix" releases? AFAIU, it is mostly producing a
> release tarball + waiting for Emacs to be packaged on major GNU/Linux
> distributions. The timing would be anything acceptable for the latter
> task, which appears to be a bottleneck in such scenario.

That has only disadvantages from my POV: 2 hours of work to produce
and test a tarball with no benefits at all.  If someone wants to
volunteer to do that, fine.  (But then making a tarball by following
the instructions in make-tarball.txt is easy, and anyone can do that
for themselves if they want to.)

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> For Org, a number of people just update from ELPA. Releasing benefits
>> these users. 
>
> I don't see how is that different from updating from Git.

Not all the users are even familiar with Git. But every Emacs user is
expected to know how to M-x package-upgrade.

Getting Org (or Emacs) from Git would require non-trivial knowledge.
Even I fail to compile Emacs from sources when using non-familiar
distros like Debian.

>> > A minor release is more than just code with some bugs fixed: it (a)
>> > has no known bugs except those whose fix is too risky, and (b) was
>> > tested in the wild during a pretest.
>> 
>> You are right. To clarify: I am talking about _bugfix_ releases. Like
>> Org 9.6.7 -> 9.6.8. Emacs does not have those, currently.
>
> If bugfix releases just fix bugs, then basically every commit on the
> release branch is such a "release", because we only fix bugs there.

That's my point - get at least some bug fixes available to casual users
faster. Not on every commit, but with somewhat higher frequency compared
to "proper" minor releases.

> And don't forget that minor releases affect downstream distros: they
> need to package a new release, patch it, announce it, manage it, etc.
> It's very different from a single package, even a package that is as
> large as Org.

Sure. That's why I said that downstream packaging is the bottleneck that
should decide the acceptable bugfix release interval.

>> So, what about "bugfix" releases? AFAIU, it is mostly producing a
>> release tarball + waiting for Emacs to be packaged on major GNU/Linux
>> distributions. The timing would be anything acceptable for the latter
>> task, which appears to be a bottleneck in such scenario.
>
> That has only disadvantages from my POV: 2 hours of work to produce
> and test a tarball with no benefits at all.  If someone wants to
> volunteer to do that, fine.  (But then making a tarball by following
> the instructions in make-tarball.txt is easy, and anyone can do that
> for themselves if they want to.)

Can it be simply automated?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Can it be simply automated?

I think so, but that tarball won't be subject to the same thorough
testing that a proper tarball will.

I generate a release tarball automatically, prior to building Android
port binaries, on the off chance someone elects to obtain the
corresponding source code from me and not the FSF.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Can it be simply automated?
>
> I think so, but that tarball won't be subject to the same thorough
> testing that a proper tarball will.

May you elaborate about thorough testing?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> May you elaborate about thorough testing?

If tarballs are released too frequently, users will never test a single
tarball to the degree necessary for confidence to be vested in their
reliability.  Our (already desultory) testing effort will quickly fall
into disarray, where everyone will be testing not one tarball, but one
of many dozens.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> May you elaborate about thorough testing?
>
> If tarballs are released too frequently, users will never test a single
> tarball to the degree necessary for confidence to be vested in their
> reliability.  Our (already desultory) testing effort will quickly fall
> into disarray, where everyone will be testing not one tarball, but one
> of many dozens.

These tarballs will be mostly the same, as they will only differ by
bugfixes. So, testing different "bugfix" tarball versions will only risk differing via some bugs being already fixed in newer versions. The
worst-case scenario is when some bugfix introduces another bug, but
AFAIK it is already ensured that such things almost never happen.

So, I do not think that having multiple bugfix versions around will pose
a significant problem.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> These tarballs will be mostly the same, as they will only differ by
> bugfixes. So, testing different "bugfix" tarball versions will only
> risk differing via some bugs being already fixed in newer
> versions. The
> worst-case scenario is when some bugfix introduces another bug, but
> AFAIK it is already ensured that such things almost never happen.
>
> So, I do not think that having multiple bugfix versions around will pose
> a significant problem.

I would wait until the reports for already fixed bugs start rolling in
before making such a brazen assertion.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> These tarballs will be mostly the same, as they will only differ by
>> bugfixes. So, testing different "bugfix" tarball versions will only
>> risk differing via some bugs being already fixed in newer
>> versions. The
>> worst-case scenario is when some bugfix introduces another bug, but
>> AFAIK it is already ensured that such things almost never happen.
>>
>> So, I do not think that having multiple bugfix versions around will pose
>> a significant problem.
>
> I would wait until the reports for already fixed bugs start rolling in
> before making such a brazen assertion.

May you elaborate how bug duplicates (if I understand you correctly)
may be a larger problem for the proposed bugfix releases compared to the
current minor-release-only model?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, dmitry@gutov.dev,
>  emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 12:52:54 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Ihor Radchenko <yantar92@posteo.net> writes:
> >
> >> May you elaborate about thorough testing?
> >
> > If tarballs are released too frequently, users will never test a single
> > tarball to the degree necessary for confidence to be vested in their
> > reliability.  Our (already desultory) testing effort will quickly fall
> > into disarray, where everyone will be testing not one tarball, but one
> > of many dozens.
> 
> These tarballs will be mostly the same, as they will only differ by
> bugfixes. So, testing different "bugfix" tarball versions will only risk differing via some bugs being already fixed in newer versions. The
> worst-case scenario is when some bugfix introduces another bug, but
> AFAIK it is already ensured that such things almost never happen.
> 
> So, I do not think that having multiple bugfix versions around will pose
> a significant problem.

I think you have a very naïve view of the effect of bugfixes in Emacs.
What you think doesn't happen actually happens all the time.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> These tarballs will be mostly the same, as they will only differ by
>> bugfixes. So, testing different "bugfix" tarball versions will only risk differing via some bugs being already fixed in newer versions. The
>> worst-case scenario is when some bugfix introduces another bug, but
>> AFAIK it is already ensured that such things almost never happen.
>> 
>> So, I do not think that having multiple bugfix versions around will pose
>> a significant problem.
>
> I think you have a very naïve view of the effect of bugfixes in Emacs.
> What you think doesn't happen actually happens all the time.

Do you mean that one fix introducing new bugs is rather common? If so, I
agree that bugfix releases will not be a good idea.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: luangruo@yahoo.com, stefankangas@gmail.com, dmitry@gutov.dev,
>  emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 13:20:03 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> These tarballs will be mostly the same, as they will only differ by
> >> bugfixes. So, testing different "bugfix" tarball versions will only risk differing via some bugs being already fixed in newer versions. The
> >> worst-case scenario is when some bugfix introduces another bug, but
> >> AFAIK it is already ensured that such things almost never happen.
> >> 
> >> So, I do not think that having multiple bugfix versions around will pose
> >> a significant problem.
> >
> > I think you have a very naïve view of the effect of bugfixes in Emacs.
> > What you think doesn't happen actually happens all the time.
> 
> Do you mean that one fix introducing new bugs is rather common?

Too common to my liking.  Didn't you read all those threads where I
constantly say that Emacs doesn't get more stable with the years
because we constantly fix minor issues and by that introduce subtle
regressions elsewhere?

Which is why we have pretests, where we are supposed to detect at
least the more obvious of those regressions.  The question that really
bothers me is how to make more frequent releases without losing that
QA element, because we really need it.  So any suggestion to lower the
bar is in my eyes a non-starter.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Do you mean that one fix introducing new bugs is rather common?
>
> Too common to my liking.  Didn't you read all those threads where I
> constantly say that Emacs doesn't get more stable with the years
> because we constantly fix minor issues and by that introduce subtle
> regressions elsewhere?

Nope. I stay away from such threads most of the time. They take a lot of
mental effort.

> Which is why we have pretests, where we are supposed to detect at
> least the more obvious of those regressions.  The question that really
> bothers me is how to make more frequent releases without losing that
> QA element, because we really need it.  So any suggestion to lower the
> bar is in my eyes a non-starter.

Point taken. In my eyes, it was not lowering the bar, but you indeed
have much more experience.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, stefankangas@gmail.com, dmitry@gutov.dev,
>  emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 12:00:50 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> >> Can it be simply automated?
> >
> > I think so, but that tarball won't be subject to the same thorough
> > testing that a proper tarball will.
> 
> May you elaborate about thorough testing?

Just read admin/make-tarball.txt, and you will see.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  stefankangas@gmail.com,
>   dmitry@gutov.dev,  emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 19:41:31 +0800
> 
> Ihor Radchenko <yantar92@posteo.net> writes:
> 
> > Can it be simply automated?
> 
> I think so, but that tarball won't be subject to the same thorough
> testing that a proper tarball will.

Which for me makes the release pointless.  When I'm talking about more
frequent releases, I mean make them more frequent, but without giving
up too much of the quality.  If our release tarballs become of low
enough quality, they lose their raison d'être.  If people just want a
tarball from a particular commit, Savannah can service such requests,
similar to any other repository: they all know how to produce an
archive from a given branch/commit.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 11:01:38 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> For Org, a number of people just update from ELPA. Releasing benefits
> >> these users. 
> >
> > I don't see how is that different from updating from Git.
> 
> Not all the users are even familiar with Git.

Are you sure?  I'm not.

And we aren't talking about "all the users", only those who want all
the latest fixes ASAP.  Emacs is a large and very stable package, so
the probability that the latest bugfix affects a particular user is
very low.  Thus, I believe that people who really need frequent
bugfixes are quite a few.

> >> So, what about "bugfix" releases? AFAIU, it is mostly producing a
> >> release tarball + waiting for Emacs to be packaged on major GNU/Linux
> >> distributions. The timing would be anything acceptable for the latter
> >> task, which appears to be a bottleneck in such scenario.
> >
> > That has only disadvantages from my POV: 2 hours of work to produce
> > and test a tarball with no benefits at all.  If someone wants to
> > volunteer to do that, fine.  (But then making a tarball by following
> > the instructions in make-tarball.txt is easy, and anyone can do that
> > for themselves if they want to.)
> 
> Can it be simply automated?

Not easily, no.  There's always stuff that needs manual intervention.
Maybe someone could write and maintain a smart enough program to do
that, but it's not trivial, and there are always new issues to add to
that.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Not all the users are even familiar with Git.
>
> Are you sure?  I'm not.
>
> And we aren't talking about "all the users", only those who want all
> the latest fixes ASAP.  Emacs is a large and very stable package, so
> the probability that the latest bugfix affects a particular user is
> very low.  Thus, I believe that people who really need frequent
> bugfixes are quite a few.

I have a particular category of users in mind - the bug reporters
themselves. It would be nice if they had an opportunity to get _their_
bug fixed simply after soon-ish bugfix update. People who report bugs
are quite often just ordinary users, who do not know anything about
patches or git.

>> > That has only disadvantages from my POV: 2 hours of work to produce
>> > and test a tarball with no benefits at all.  If someone wants to
>> > volunteer to do that, fine.  (But then making a tarball by following
>> > the instructions in make-tarball.txt is easy, and anyone can do that
>> > for themselves if they want to.)
>> 
>> Can it be simply automated?
>
> Not easily, no.  There's always stuff that needs manual intervention.
> Maybe someone could write and maintain a smart enough program to do
> that, but it's not trivial, and there are always new issues to add to
> that.

I have looked through admin/make-tarball.txt, and I can mostly see hassle
with updating NEWS file. But, AFAIU, NEWS file should not change in
breaking ways when fixing bugs.

Or do you have some other problems in mind?

(Also, note that Po Lu seems to have some working code to generate tarballs)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> I have a particular category of users in mind - the bug reporters
> themselves. It would be nice if they had an opportunity to get _their_
> bug fixed simply after soon-ish bugfix update. People who report bugs
> are quite often just ordinary users, who do not know anything about
> patches or git.

I fail to see the purported distinction between such ``releases'' and
generating a snapshot from

  https://git.savannah.gnu.org/gitweb/?p=emacs.git;a=snapshot;h=emacs-29;sf=tgz

After all, downloading a tarball from a web URL scarcely requires any
intimate knowledge of Git, a skill even Emacs developers have in short
supply.

> (Also, note that Po Lu seems to have some working code to generate tarballs)

No more than running:

  ./make-dist --snapshot --no-check

from the root of the Emacs repository, after running the autogen stuff.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 12:59:43 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Not all the users are even familiar with Git.
> >
> > Are you sure?  I'm not.
> >
> > And we aren't talking about "all the users", only those who want all
> > the latest fixes ASAP.  Emacs is a large and very stable package, so
> > the probability that the latest bugfix affects a particular user is
> > very low.  Thus, I believe that people who really need frequent
> > bugfixes are quite a few.
> 
> I have a particular category of users in mind - the bug reporters
> themselves. It would be nice if they had an opportunity to get _their_
> bug fixed simply after soon-ish bugfix update. People who report bugs
> are quite often just ordinary users, who do not know anything about
> patches or git.

That already happens -- we almost always either post the patches or
point to the commits (or both).

So these users are not the main target audience for the minor
releases.

> >> > That has only disadvantages from my POV: 2 hours of work to produce
> >> > and test a tarball with no benefits at all.  If someone wants to
> >> > volunteer to do that, fine.  (But then making a tarball by following
> >> > the instructions in make-tarball.txt is easy, and anyone can do that
> >> > for themselves if they want to.)
> >> 
> >> Can it be simply automated?
> >
> > Not easily, no.  There's always stuff that needs manual intervention.
> > Maybe someone could write and maintain a smart enough program to do
> > that, but it's not trivial, and there are always new issues to add to
> > that.
> 
> I have looked through admin/make-tarball.txt, and I can mostly see hassle
> with updating NEWS file.

Look closer.  NEWS actually don't present a problem that needs to be
fixed manually.

> Or do you have some other problems in mind?

Yes.

> (Also, note that Po Lu seems to have some working code to generate tarballs)

So do we: see the make-dist script.  This is not what takes me two
hours each time I need to produce a release tarball.

(I actually don't understand where this discussion is going.  Do you
really believe I'm so ... unwise, after all these years, that I spend
two full hours of my time on something that can be easily automated?
really??)

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> (I actually don't understand where this discussion is going.  Do you
> really believe I'm so ... unwise, after all these years, that I spend
> two full hours of my time on something that can be easily automated?
> really??)

No. But I was hoping that this very specific case with only bug fixes
might be easier to automate. If no, alas.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: stefankangas@gmail.com, dmitry@gutov.dev, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 13:31:01 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > (I actually don't understand where this discussion is going.  Do you
> > really believe I'm so ... unwise, after all these years, that I spend
> > two full hours of my time on something that can be easily automated?
> > really??)
> 
> No. But I was hoping that this very specific case with only bug fixes
> might be easier to automate. If no, alas.

The routine tasks is not what takes the time and determines the
frequency of releases.

What I think we need is some kind of analysis or insights into the way
we receive feedback about releases and decide when we have "enough" to
make another release.  For example, it would be useful, I think, to
know how the rate of reports about bugs and regressions depends on
time since the release.  This could also benefit from tracking
specific categories of bugs (e.g., regressions) separately.  If
someone could run such analyses on our bug DB, it might be useful for
setting or changing our criteria for a release, which currently are
based on gut feelings, more or less.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> What I think we need is some kind of analysis or insights into the way
> we receive feedback about releases and decide when we have "enough" to
> make another release.  For example, it would be useful, I think, to
> know how the rate of reports about bugs and regressions depends on
> time since the release.  This could also benefit from tracking
> specific categories of bugs (e.g., regressions) separately.  If
> someone could run such analyses on our bug DB, it might be useful for
> setting or changing our criteria for a release, which currently are
> based on gut feelings, more or less.

AFAIK, Lars (in CC) did a similar kind of analysis in
https://lars.ingebrigtsen.no/2021/08/14/10x10/
Maybe he can share the code he used to built those graphs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

RE: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Drew Adams]

> Not all the users are even familiar with Git.
> But every Emacs user is expected to know how
> to M-x package-upgrade.

Really?  Who's expecting whom to expect
that?  What's being based on such imposed
expectations?

I don't think every Emacs user should be
expected to be familiar with Git OR to
know how to `M-x package-upgrade'.

I don't even think that every Emacs user
should be expected to use packages or to
know about using packages.

Expectations about "every Emacs user"
should be _very_ limited, perhaps even
zero.

RE: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

>> Not all the users are even familiar with Git.
>> But every Emacs user is expected to know how
>> to M-x package-upgrade.
>
> Really?  Who's expecting whom to expect
> that?  What's being based on such imposed
> expectations?
> ...
> Expectations about "every Emacs user"
> should be _very_ limited, perhaps even
> zero.

Maybe. But it is a reasonable ask to Emacs users to at least skim
through Emacs manual and be familiar with basic terminology. Otherwise,
we simply cannot communicate things efficiently. IMHO, "Emacs packages"
is a part of basic terminology. But certainly not Git, which has no
relation to Emacs, except to the Emacs packages that work with Git -
specialized packages not aiming for all Emacs users.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Thu, Aug 31, 2023 at 11:06 AM Drew Adams <drew.adams@oracle.com> wrote:
> > Not all the users are even familiar with Git.
> > But every Emacs user is expected to know how
> > to M-x package-upgrade.
>
> Really?  Who's expecting whom to expect
> that?  What's being based on such imposed
> expectations?
>
> I don't think every Emacs user should be
> expected to be familiar with Git OR to
> know how to `M-x package-upgrade'.
>
> I don't even think that every Emacs user
> should be expected to use packages or to
> know about using packages.

Even if an emacs user is knowledgeable about packages, they may be
working in an environment with controls that inhibit the use of any
software not installed by the root user and/or approved by a controls
team.  Including a library in the GNU emacs distribution is the
easiest way to ensure its availability to these users as well.

Lynn

Re: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Richard Stallman]

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

  > I don't think every Emacs user should be
  > expected to be familiar with Git OR to
  > know how to `M-x package-upgrade'.

I agree.  (I have only the most basic knowledge of how to use git, and
I have no idea how to use package-upgrade.  And I can't afford to
spend time learning more.  In the abstract, I'd be glad to know -- but
I am overloaded already!)

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

Re: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > I don't think every Emacs user should be
>   > expected to be familiar with Git OR to
>   > know how to `M-x package-upgrade'.
>
> I agree.  (I have only the most basic knowledge of how to use git, and
> I have no idea how to use package-upgrade.  And I can't afford to
> spend time learning more.  In the abstract, I'd be glad to know -- but
> I am overloaded already!)

I think that this discussion got completely disconnected from the
starting point. In the above replies, I was advocating that updating
from ELPA is __easier__ compared to updating from Git and Emacs users
are more likely to know how to update from ELPA and less likely to known
how to update from Git:

    >> >> Is there any downside holding on a minor release if _some_ bugs are
    >> >> already fixed, even if others are not yet?
    >> >
    >> > What would be the point?  People who want something like that can
    >> > simply build the Git release branch, where we fix bugs every few days.
    >> 
    >> For Org, a number of people just update from ELPA. Releasing benefits
    >> these users. 
    
    > I don't see how is that different from updating from Git.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 04:52, 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. ]]]
> 
>    > I don't think every Emacs user should be
>    > expected to be familiar with Git OR to
>    > know how to `M-x package-upgrade'.
> 
> I agree.  (I have only the most basic knowledge of how to use git, and
> I have no idea how to use package-upgrade.  And I can't afford to
> spend time learning more.  In the abstract, I'd be glad to know -- but
> I am overloaded already!)

You just call 'M-x package-upgrade' and then input the package name 
(assisted by TAB completion).

Emacs release cadence

[Dmitry Gutov]

On 27/08/2023 16:28, Eli Zaretskii wrote:
>> Date: Sun, 27 Aug 2023 16:12:00 +0300
>> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, danny@dfreeman.email,
>>   stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 27/08/2023 15:57, Po Lu wrote:
>>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>>>
>>>> We could easily have more frequent releases, it's all in the hands of
>>>> the maintainers, actually. Stability/velocity tradeoffs.
>>> Producing another atrocity following the footsteps of Mozilla?  No
>>> thanks!
>>
>> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
>> crashing mess.
> 
> We already do it, or thereabouts.  Check out the last part of
> etc/HISTORY.

What I meant are more frequent major releases, and some more patch 
releases between them. And it looks like we're taking ~2 years between 
major releases now.

Anyway, specific intervals are not that important, it was just an 
example: we could increase frequency, and nothing major would break.

>> But we would get more and faster feedback for new features and
>> changes.
> 
> Maybe, maybe not.  See below.

I'm pretty sure what I said is self-obvious: when instead of waiting for 
somebody to check out our test builds we cut a release, a lot of people 
will get it fairly soon, some later, but on the whole we'll get a lot 
more feedback, much faster.

>> That's the main issue why we have to drag on the release schedule: we
>> don't get reports of regressions soon enough after introducing them. So
>> we have to wait months for the users to try and report back.
>>
>> How to change that? Either make releases more often, or make snapshot
>> releases more prominent and easier to try, or improve the bug reporting
>> experience so that more people do that. Or all of that together, of course.
> 
> Are you sure this will help?  Here's a typical case:
> 
>    https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html
> 
> This guy just recently upgraded to Emacs 29, and is reporting a
> significant issue only now, a month after Emacs 29.1 was released.

As our (and others') experience shows, indeed, there is no way to ensure 
that all bugs are fixed, all regressions are ironed out, and nobody is 
ever unhappy.

Some people will wait longer before upgrading and ignore all pretests. I 
only know, again, two things we could possibly do:

- Get releases out earlier (so the "one month since release" day comes 
faster).
- Get a lot more users and/or a lot more feedback from the same users.

The latter is a bet that even if, maybe, user C only uses Emacs 
releases, there will be users D and E with similar enough workflows that 
do test our snapshot builds and would report the same problems sooner.

Some problems will remain unreported anyway. Some stay that way for decades.

> I've seen similar things many times: people upgrade to a new Emacs
> version months, and sometimes years, after that version was released.
> Try to collect feedback for a release quickly given this upgrade
> schedule.

People who stay silent about their problems will get what their pay for.

But another upside of a shorter release cycle: even when encountering 
late, embarrassing regressions, we would be able to say "it'll be fixed 
in the next point-release" and people will know that they won't have to 
wait long.

>> I wonder what wonderful curious bug reports we would also get if we had
>> the number of users that Firefox has.
> 
> If we never do anything, we will keep wondering, and it will remain
> forever in the "he said, she said" department.

Indeed.

Re: Emacs release cadence

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 00:43:36 +0300
> Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
> >> crashing mess.
> > 
> > We already do it, or thereabouts.  Check out the last part of
> > etc/HISTORY.
> 
> What I meant are more frequent major releases, and some more patch 
> releases between them. And it looks like we're taking ~2 years between 
> major releases now.

Yes, but this started as a comparison with others, in which case the
difference between major and minor is not very relevant, since
Firefox, for example, doesn't have that distinction.

As for the frequency of major releases of Emacs, my experience so far
is that we cannot do much better without some drastic changes in the
procedures, which would probably require correspondingly drastic
changes in the core team and how it works.

> Anyway, specific intervals are not that important, it was just an 
> example: we could increase frequency, and nothing major would break.

IME, nope, we cannot, not by a lot, anyway.

> >> But we would get more and faster feedback for new features and
> >> changes.
> > 
> > Maybe, maybe not.  See below.
> 
> I'm pretty sure what I said is self-obvious: when instead of waiting for 
> somebody to check out our test builds we cut a release, a lot of people 
> will get it fairly soon, some later, but on the whole we'll get a lot 
> more feedback, much faster.

If we get feedback, but do not verify that the fixes indeed fixed the
problems, and didn't cause unintended problems elsewhere (something
that happens with alarming frequency around here), these frequent
releases become pointless.

> > Are you sure this will help?  Here's a typical case:
> > 
> >    https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html
> > 
> > This guy just recently upgraded to Emacs 29, and is reporting a
> > significant issue only now, a month after Emacs 29.1 was released.
> 
> As our (and others') experience shows, indeed, there is no way to ensure 
> that all bugs are fixed, all regressions are ironed out, and nobody is 
> ever unhappy.

Is this what you seriously think we are doing -- waiting for all the
bugs to be fixed?  It is not useful to discuss serious subjects such
as this one with such a non-serious attitude.

> Some people will wait longer before upgrading and ignore all pretests. I 
> only know, again, two things we could possibly do:
> 
> - Get releases out earlier (so the "one month since release" day comes 
> faster).
> - Get a lot more users and/or a lot more feedback from the same users.
> 
> The latter is a bet that even if, maybe, user C only uses Emacs 
> releases, there will be users D and E with similar enough workflows that 
> do test our snapshot builds and would report the same problems sooner.
> 
> Some problems will remain unreported anyway. Some stay that way for decades.

Are you talking from experience with releasing Emacs and collecting
the feedback?  Because I am, and I can tell that (a) we have no
control on how many users will return feedback, and (b) it takes
several weeks(!) to get useful feedback with real problems flowing
after a release.  This basically invalidates the simplistic model you
describe above.

> > I've seen similar things many times: people upgrade to a new Emacs
> > version months, and sometimes years, after that version was released.
> > Try to collect feedback for a release quickly given this upgrade
> > schedule.
> 
> People who stay silent about their problems will get what their pay for.

Problem is: most of them do.  People who want the latest ASAP simply
track the development branches, and we have their feedback more or
less in real time; more frequent releases will not improve the
feedback we get from them.

> But another upside of a shorter release cycle: even when encountering 
> late, embarrassing regressions, we would be able to say "it'll be fixed 
> in the next point-release" and people will know that they won't have to 
> wait long.

Not useful if people upgrade slowly and lazily.  Once again, those who
upgrade eagerly simply build from Git.

Re: Emacs release cadence

[Dmitry Gutov]

On 28/08/2023 15:02, Eli Zaretskii wrote:

>> What I meant are more frequent major releases, and some more patch
>> releases between them. And it looks like we're taking ~2 years between
>> major releases now.
> 
> Yes, but this started as a comparison with others, in which case the
> difference between major and minor is not very relevant, since
> Firefox, for example, doesn't have that distinction.

Firefox has been releasing patch versions for majorly breaking bugs or 
0-day security issues from time to time.

Our minor versions carry more changes, but the idea is that we would be 
releasing more frequently from the main branch (meaning, pushing out new 
developments). Because of course we could release a hundred minor 
versions in a month from an already-closed release branch, if we didn't 
change anything serious inside.

>> Anyway, specific intervals are not that important, it was just an
>> example: we could increase frequency, and nothing major would break.
> 
> IME, nope, we cannot, not by a lot, anyway.

Looking at the current release history, it took 9 months between the 
release branch was initially cut and the release. The development time 
on master preceding that was, depending on how to measure, either ~1 
year or 1 year plus however the previous pre-release also took.

Anyway, suppose next time we start the release branch only after 6 
months. Would you say it will still take 9 months to stabilize?

>>>> But we would get more and faster feedback for new features and
>>>> changes.
>>>
>>> Maybe, maybe not.  See below.
>>
>> I'm pretty sure what I said is self-obvious: when instead of waiting for
>> somebody to check out our test builds we cut a release, a lot of people
>> will get it fairly soon, some later, but on the whole we'll get a lot
>> more feedback, much faster.
> 
> If we get feedback, but do not verify that the fixes indeed fixed the
> problems, and didn't cause unintended problems elsewhere (something
> that happens with alarming frequency around here), these frequent
> releases become pointless.

We cannot really "verify" a fix, just get reasonably confident that it's 
good. Any time interval we use will increase the confidence, but also at 
the expense of velocity. And we won't reach 100% confidence still.

And velocity is not just about the next shiny thing, it's also about 
getting fixes to a certain large category of users sooner.

>>> Are you sure this will help?  Here's a typical case:
>>>
>>>     https://lists.gnu.org/archive/html/help-gnu-emacs/2023-08/msg00454.html
>>>
>>> This guy just recently upgraded to Emacs 29, and is reporting a
>>> significant issue only now, a month after Emacs 29.1 was released.
>>
>> As our (and others') experience shows, indeed, there is no way to ensure
>> that all bugs are fixed, all regressions are ironed out, and nobody is
>> ever unhappy.
> 
> Is this what you seriously think we are doing -- waiting for all the
> bugs to be fixed?  It is not useful to discuss serious subjects such
> as this one with such a non-serious attitude.

It's a simplification to make the explanation shorter.

>> Some people will wait longer before upgrading and ignore all pretests. I
>> only know, again, two things we could possibly do:
>>
>> - Get releases out earlier (so the "one month since release" day comes
>> faster).
>> - Get a lot more users and/or a lot more feedback from the same users.
>>
>> The latter is a bet that even if, maybe, user C only uses Emacs
>> releases, there will be users D and E with similar enough workflows that
>> do test our snapshot builds and would report the same problems sooner.
>>
>> Some problems will remain unreported anyway. Some stay that way for decades.
> 
> Are you talking from experience with releasing Emacs and collecting
> the feedback?

No exactly, but I've been around the bug tracker for a little while.

> Because I am, and I can tell that (a) we have no
> control on how many users will return feedback,

But there are factors we could improve (mentioned previously).

> and (b) it takes
> several weeks(!) to get useful feedback with real problems flowing
> after a release.  This basically invalidates the simplistic model you
> describe above.

Suppose we have a release loop of 6 months (again, a contrived example). 
Even then we'd have the first month to collect the initial feedback, and 
then 5 months to act on it (either release a minor version for simple 
fixes or important regressions, or put it into master and iterate).

Further, a shorter release cycle would mean fewer features and less 
changes in each release (which is both a pro and a con). But less 
changes also implies fewer potential new bugs to deal with. It's not a 
linear relation, but a reduction seems logical.

>>> I've seen similar things many times: people upgrade to a new Emacs
>>> version months, and sometimes years, after that version was released.
>>> Try to collect feedback for a release quickly given this upgrade
>>> schedule.
>>
>> People who stay silent about their problems will get what their pay for.
> 
> Problem is: most of them do.  People who want the latest ASAP simply
> track the development branches, and we have their feedback more or
> less in real time; more frequent releases will not improve the
> feedback we get from them.

If we release the next version of Emacs in 1 year, rather than in 2 
years, we'll get some faster feedback anyway from those slow users (even 
if they take 1-2 months after the release to upgrade and send reports).

With those who wait years, we won't get any improvement, of course, but 
they cannot be helped anyhow.

>> But another upside of a shorter release cycle: even when encountering
>> late, embarrassing regressions, we would be able to say "it'll be fixed
>> in the next point-release" and people will know that they won't have to
>> wait long.
> 
> Not useful if people upgrade slowly and lazily.  Once again, those who
> upgrade eagerly simply build from Git.

There is definitely a cutoff point somewhere when more frequent releases 
would hurt rather than help: perhaps if it got to a point where the vast 
majority of our users chose not to upgrade for 2-3 release cycles anyway.

But I figure we're not there yet, since the question of shorter 
development cycles gets brought up with some regularity.

Re: Emacs release cadence

[Eli Zaretskii]

> Date: Tue, 29 Aug 2023 02:52:56 +0300
> Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>

I will respond to some of your points below, but I must say that this
style of discussing the aspects and frequency of our releases is not
useful, and TBH quite frustrating.  You present some up- and
down-sides, with which everyone will agree.  You say some truisms that
again are accepted by everyone.  But there are no suggestions that are
practical and based on our actual experience and practices, just
theoretical considerations, hypothetical examples, and numbers taken
out of thin air.  I don't see how can anything useful and practical
come out of such a discussion, sorry.

> Looking at the current release history, it took 9 months between the 
> release branch was initially cut and the release. The development time 
> on master preceding that was, depending on how to measure, either ~1 
> year or 1 year plus however the previous pre-release also took.
> 
> Anyway, suppose next time we start the release branch only after 6 
> months. Would you say it will still take 9 months to stabilize?

It depends on the number of significant changes that got installed.
OTOH, if we cut the release branch when master doesn't have enough new
features, why make a new major release?

IOW, you seem to be arguing for a flat, one-level release system, with
no major and minor releases.  This is IMO appropriate only for very
stable programs, where there are no major changes, only minor ones.
Emacs is not there, and probably never will be, because there's no
limit to new features it can have, unlike, say, Binutils (which indeed
rolls out a new version every 6 months, and its NEWS files typically
have just several dozen lines about each new version).

> > If we get feedback, but do not verify that the fixes indeed fixed the
> > problems, and didn't cause unintended problems elsewhere (something
> > that happens with alarming frequency around here), these frequent
> > releases become pointless.
> 
> We cannot really "verify" a fix, just get reasonably confident that it's 
> good. Any time interval we use will increase the confidence, but also at 
> the expense of velocity. And we won't reach 100% confidence still.

This is just word semantics and truisms.  You can assume we both
understand that, and that when I say "verify" I mean something
practical and tangible, and am well aware that it is impossible to
produce a bug-free software of this magnitude.

But Emacs is an interactive editor, which users use to edit their
precious files, in sessions that are supposed to stay up and running
for weeks on end, so it must be reasonably stable and avoid crashing
and losing edits.  Unlike a Web browser, for example.

> And velocity is not just about the next shiny thing, it's also about 
> getting fixes to a certain large category of users sooner.

Another truism, with which no one will argue.  How does it help to
keep this discussion useful and focused?

> >>> This guy just recently upgraded to Emacs 29, and is reporting a
> >>> significant issue only now, a month after Emacs 29.1 was released.
> >>
> >> As our (and others') experience shows, indeed, there is no way to ensure
> >> that all bugs are fixed, all regressions are ironed out, and nobody is
> >> ever unhappy.
> > 
> > Is this what you seriously think we are doing -- waiting for all the
> > bugs to be fixed?  It is not useful to discuss serious subjects such
> > as this one with such a non-serious attitude.
> 
> It's a simplification to make the explanation shorter.

Which again doesn't help.  What it does do is duck the serious and
important question that I raised, one that is very pertinent to this
discussion, if we want to have some useful outcome out of it.  Namely:
how do you collect feedback efficiently under these circumstances,
whether it can be sped up, and how does the typical schedule of
collecting feedback affect the time frame for the next release?

> >> Some people will wait longer before upgrading and ignore all pretests. I
> >> only know, again, two things we could possibly do:
> >>
> >> - Get releases out earlier (so the "one month since release" day comes
> >> faster).
> >> - Get a lot more users and/or a lot more feedback from the same users.
> >>
> >> The latter is a bet that even if, maybe, user C only uses Emacs
> >> releases, there will be users D and E with similar enough workflows that
> >> do test our snapshot builds and would report the same problems sooner.
> >>
> >> Some problems will remain unreported anyway. Some stay that way for decades.
> > 
> > Are you talking from experience with releasing Emacs and collecting
> > the feedback?
> 
> No exactly, but I've been around the bug tracker for a little while.
> 
> > Because I am, and I can tell that (a) we have no
> > control on how many users will return feedback,
> 
> But there are factors we could improve (mentioned previously).

Which ones?  Name them, please!  Above you just say "we could", and
IME we cannot.  So let's discuss how to "get a lot more users and/or a
lot more feedback from the same users" in practice, if you have
practical ideas to that effect.

> > and (b) it takes
> > several weeks(!) to get useful feedback with real problems flowing
> > after a release.  This basically invalidates the simplistic model you
> > describe above.
> 
> Suppose we have a release loop of 6 months (again, a contrived example). 

"A contrived example".  Why do you think it's useful to discuss
theoretical examples which are not at all connected or even related to
the real situation we have?

> Even then we'd have the first month to collect the initial feedback, and 
> then 5 months to act on it (either release a minor version for simple 
> fixes or important regressions, or put it into master and iterate).

I said it takes several weeks to get useful feedback, I didn't say it
takes just one month.  IME, 1 month is barely enough to get some
feedback for a minor release; for major releases it's far from being
enough.  We are still getting regression reports about Emacs 28.1,
more than a year after it was released!

> Further, a shorter release cycle would mean fewer features and less 
> changes in each release (which is both a pro and a con). But less 
> changes also implies fewer potential new bugs to deal with. It's not a 
> linear relation, but a reduction seems logical.

This is again a more-or-less obvious tradeoff, but without any
practical conclusion or suggestion.  How do you know we aren't already
at the optimal point in this particular tradeoff?  That we all want
more frequent releases doesn't mean they aren't already "as frequent
as reasonable, but no more frequent"?  We need specific, practical
suggestions and ideas, based on our actual experience and users, to
seriously consider significant changes in what we currently do.

Please also keep in mind that no one counts weeks or months when
deciding whether to cut the release branch or make a release.  The
main considerations are not the time passed, but the perceived
stability of the package and the absence of serious known bugs.  The
schedule is the result, not the control variable.

> >> People who stay silent about their problems will get what their pay for.
> > 
> > Problem is: most of them do.  People who want the latest ASAP simply
> > track the development branches, and we have their feedback more or
> > less in real time; more frequent releases will not improve the
> > feedback we get from them.
> 
> If we release the next version of Emacs in 1 year, rather than in 2 
> years, we'll get some faster feedback anyway from those slow users (even 
> if they take 1-2 months after the release to upgrade and send reports).

Yes.  And we will have a less "interesting" release.  Look at the
state of the master branch a year ago and try to think whether what we
had back then would justify a major release.

Also, how do you propose to get to the 1 year mark?  A major release
needs at least 2 - 3 pretests, with each pretest taking a month or so.
And we need some time before the first pretest to stabilize the
branch, complete and fix the missing/incomplete documentation,
etc. etc.  And before that we need some time to develop and install
new features on master, after the previous release is out.  So please
try to present a reasonable schedule that would allow us to make a
major release once a year, and if you still think it's doable, let's
see the schedule and talk about some of your assumptions.

This is what I call practical suggestions based on our experience.
Without using real, not imaginary, figures, procedures, and time
frames we need, all this discussion becomes a futile academic exercise
with no practical importance whatsoever.

And, btw, the last 3 major releases took 1.25 to 1.5 years, so already
quite close to the 1-year mark.  Not 2 years, as you say.

> There is definitely a cutoff point somewhere when more frequent releases 
> would hurt rather than help: perhaps if it got to a point where the vast 
> majority of our users chose not to upgrade for 2-3 release cycles anyway.
> 
> But I figure we're not there yet, since the question of shorter 
> development cycles gets brought up with some regularity.

How do you figure that?  The fact that this is being brought up
doesn't mean we are not at the optimum already.  The only way to have
a useful discussion about this is to talk specifics and use numbers
from our long experience.

Re: Emacs release cadence

[Eli Zaretskii]

> Date: Tue, 29 Aug 2023 16:14:22 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> 
> And, btw, the last 3 major releases took 1.25 to 1.5 years, so already
> quite close to the 1-year mark.  Not 2 years, as you say.

Btw, if we want to make more frequent releases, we should start from
making sure each code change is accompanied by a suitable change to
our manuals.  The NEWS file on master is once again full of entries
with neither "---" nor "+++" markings, and going through all such
entries and documenting them (or deciding not to) is a job that takes
quite some time if delayed to before the first pretest.  I'd
appreciate if people who want to push for more frequent releases would
either work on documenting changes that their authors didn't, or at
least would remind those authors to maybe provide some documentation.

IOW, making our releases more frequent will take a serious effort from
everyone, otherwise it will simply not work for any number of good
reasons.

Re: Emacs release cadence

[brickviking]

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

I'm what I consider to be a user that doesn't "stress" the editor, so
therefore I'm unlikely to see the sorts of bugs I can usefully test and
report. I also don't install the kitchen sink, so there are far less
chances for bad interaction between things. The most chance I've had to
test something that might (vaguely) have affected me was with the recent
dired-killing-frame-on-start bug (#65277), and I don't normally start emacs
with a dired session anyhow.

In regard to release cadence, I'm not really bothered how long the product
(in this case, the new version of an editor with new functionality) takes
to produce. I just want it to be stable enough to work when I compile and
run it. I'm not honestly sure how you'll get useful aggregated information
out of my class of users, any hints here? (Aside from that of simply
getting more involved).

Regards, brickviking



On Wed, 30 Aug 2023 at 04:12, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Tue, 29 Aug 2023 16:14:22 +0300
> > From: Eli Zaretskii <eliz@gnu.org>
> > Cc: stefankangas@gmail.com, emacs-devel@gnu.org
> >
> > And, btw, the last 3 major releases took 1.25 to 1.5 years, so already
> > quite close to the 1-year mark.  Not 2 years, as you say.
>
> Btw, if we want to make more frequent releases, we should start from
> making sure each code change is accompanied by a suitable change to
> our manuals.  The NEWS file on master is once again full of entries
> with neither "---" nor "+++" markings, and going through all such
> entries and documenting them (or deciding not to) is a job that takes
> quite some time if delayed to before the first pretest.  I'd
> appreciate if people who want to push for more frequent releases would
> either work on documenting changes that their authors didn't, or at
> least would remind those authors to maybe provide some documentation.
>
> IOW, making our releases more frequent will take a serious effort from
> everyone, otherwise it will simply not work for any number of good
> reasons.
>
>

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Releasing a new Emacs, say, even 6 month won't suddenly turn it into a
> crashing mess. But we would get more and faster feedback for new
> features and changes.
>
> That's the main issue why we have to drag on the release schedule: we
> don't get reports of regressions soon enough after introducing
> them. So we have to wait months for the users to try and report back.
>
> How to change that? Either make releases more often, or make snapshot
> releases more prominent and easier to try, or improve the bug
> reporting experience so that more people do that. Or all of that
> together, of course.
>
> In this thread specifically I'm talking about number 3.

There's no problem with our bug reporting process: anyone can send an
e-mail, and we furnish an easy means of doing so by way of emacsbug.  As
for Mozilla,

> I wonder what wonderful curious bug reports we would also get if we
> had the number of users that Firefox has.

I've long since forfeited any aspirations of reporting Firefox bugs.
Their intractable bug tracker (no pun intended) won't permit me to sign
in to my account, which is required to report issues with their bug
tracker...

It would be a shame for Emacs to endure the same degradation.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 16:31, Po Lu wrote:
>> I wonder what wonderful curious bug reports we would also get if we
>> had the number of users that Firefox has.
> I've long since forfeited any aspirations of reporting Firefox bugs.
> Their intractable bug tracker (no pun intended) won't permit me to sign
> in to my account, which is required to report issues with their bug
> tracker...
> 
> It would be a shame for Emacs to endure the same degradation.

I suppose I also would've been bitter if I couldn't sign into my account.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 14:46, Eli Zaretskii wrote:
>> Date: Sun, 27 Aug 2023 14:07:29 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>   emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> 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.
>>
>> If the cost is taking over entirely and dedicating 7+ hours every day to
>> Emacs (as you said you do), this is obviously a prohibitive barrier.
> 
> The real costs will not be known until you actually do it.  I hope
> it's not more, but it could well be less, especially if enough people
> come on board.

Naturally. But I'm already "on board", aren't I? Just in the areas I 
know and for the number of hours that I can dedicate now.

>> I don't think it's a reasonable ask when I'm just talking about
>> using a real bug tracker, for example.
> 
> It is definitely _un_reasonable to suggest/demand such changes when
> you are doing nothing in practice towards that goal.

What do you want me to do? Set up a standalone Bugzilla installation for 
people to try out? There is an existing demo at 
https://bugzilla-dev.allizom.org/home.

Create a migration script from the Debbugs database to Bugzilla's 
format? I could probably do that too. But that would result in nothing 
without the leadership's buy-in, just like our Gitlab instance is 
stagnating for a couple of years now.

>>> 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.
>>
>> The existing tools "lack important features" to such a degree that it's
>> not even funny.
> 
> "Important" for whom?  We are doing a reasonable job with them, given
> the available human resources, don't we?  Bugs are triaged,
> investigated, and most of them fixed; patches are reviewed, commented,
> and installed.  We'd love better tools -- who won't? -- but every tool
> we examined until now had important gaps.

Important for allowing more people participate in the conversations.

>> And the cost is not zero, the cost is the people that never set foot
>> in our community.
> 
> That cost is largely imaginary, and "never set foot" is an
> exaggeration.  The same was said about the switch to Git, for example,
> but the situation hasn't changed much, if the number of active
> maintainers/developers is concerned.  It is better, but only slightly
> so.

I think you're failing to adjust for natural attrition.

And the effect will naturally be smaller when only one difficult part of 
the workflow is replaced, while other remain. It's just like with other 
performance optimizations.

>>> And none of the alternatives withstood the test of time and/or the
>>> magnitude of the project.
>>
>> Should we mention other big projects? GNOME? Firefox? Emacs is complex
>> but not that unique.
> 
> If someone has intimate knowledge about those, then yes, I'd be
> interested to hear an objective comparison.  Until then, here are the
> facts I could gather:
> 
>    . GNOME:
>      - started in 1997
>      - 2 million lines of C
>      - release schedule: every 6 months
>    . Firefox
>      - started in 2002
>      - 2.4 million lines of C, C++, and Javascript
>      - release schedule: every 4 weeks

I haven't had a chance to look at GNOME in detail (it has many 
components), but Firefox has 20 million lines of code as described in 
https://hacks.mozilla.org/2020/04/code-quality-tools-at-mozilla/.

And here's the top of the output from an old checkout of gecko-dev as 
some practical evidence (cloc . --not-match-f=".*_min.js" 
--exclude-dir=third_party):

   247735 text files.
   232537 unique files.
    23226 files ignored.

Language                files          blank        comment        code
----------------------------------------------------------------------------
JavaScript              72091        1147845        1682166      5270157
HTML                    89800         458806         104456      4062841
C++                     9635         704273         573546      3908919
Text                    3865          56888              0      3344737
C/C++ Header            13302         422961         797052      1987545
C                       2895         229775         288698      1461583
JSON                    1480            864              0      1003811
Python                  3491         100201         103750       425069
XML                     2673           4964           1833       332396
Rust                    841          36145          41359        273443

There are 2 million lines of Rust in the third_party dir that I skipped; 
it's hard to delineate attribution there. These are many bundled 
external repositories: some of them third-party libs indeed, but many 
are also either part of Servo (an old project of Mozilla), or utility 
libs developed for Mozilla externally. Not sure which total fraction, 
though.

>    . Emacs:
>      - started in 1986
>      - 3 million lines of C and Lisp
>      - release schedule: roughly every 9 months

And for Emacs:

     5332 text files.
     3720 unique files.
     3768 files ignored.

Lisp                  2281         199969         245681        1637882
C                     367          87344         102056          412372
Text                  56           9680              0           323232
C/C++ Header          292          15336          25859           76814
Bourne Shell          37          13036           6386            58332
TNSDL                 1              0              0             42864
m4                    147           2054           1261           22642
Objective-C           10           4291           2832            18917
TeX                   28           4021           6237            18263
make                  49           2463           2827             8731
C++                   23           1865            858             7700
Java                  41           2769           2568             7622

(If we substract cedet, org and gnus, for Lisp the number of code lines 
will be 1372496).

Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's 
hard to argue that Emacs is more complex, or even comparable, to 
Firefox. And if they reached this size in 20 years rather than 40, it's 
an evidence to better productivity rather than the opposite, right?

> What is missing is the number of active developers in each project
> (which requires a definition of "active developer"), the means and
> tools they use for issue tracking, and whatever else is relevant.

According to 
https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/ 
(article from 2017),

   > 700 authors contributed code to Firefox over ~1 year

   80 of them were volunteers, "contributors from all over the world".

and by those 700 authors:

   75,342 files changed
   4,888,199 lines were added
   6,886,199 lines were changed

The more recent article (link earlier in this email) says that they're 
using Phabricator for code reviews and an in-house CI system. I can't 
comment on either of these systems.

There is a whole lot of organization around this project, but since 
we're actually much smaller, I don't know how much of it will be 
relevant enough to get into researching.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 15:59:23 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 14:46, Eli Zaretskii wrote:
> >> If the cost is taking over entirely and dedicating 7+ hours every day to
> >> Emacs (as you said you do), this is obviously a prohibitive barrier.
> > 
> > The real costs will not be known until you actually do it.  I hope
> > it's not more, but it could well be less, especially if enough people
> > come on board.
> 
> Naturally. But I'm already "on board", aren't I? Just in the areas I 
> know and for the number of hours that I can dedicate now.

your contributions and efforts are greatly appreciated, but that's not
what I meant.  I meant leading the migration process to the
(allegedly) new and better tools, then assessing how well they fit us
and making whatever changes are needed, or concluding they failed the
tests.

> > It is definitely _un_reasonable to suggest/demand such changes when
> > you are doing nothing in practice towards that goal.
> 
> What do you want me to do? Set up a standalone Bugzilla installation for 
> people to try out? There is an existing demo at 
> https://bugzilla-dev.allizom.org/home.
> 
> Create a migration script from the Debbugs database to Bugzilla's 
> format?

Some of that, yes.

> I could probably do that too. But that would result in nothing
> without the leadership's buy-in, just like our Gitlab instance is
> stagnating for a couple of years now.

If you do a good job, and the tools are useful, they _will_ be used,
and then a buy-in might be a no-brainer.  We will see when we get
there.

> >> The existing tools "lack important features" to such a degree that it's
> >> not even funny.
> > 
> > "Important" for whom?  We are doing a reasonable job with them, given
> > the available human resources, don't we?  Bugs are triaged,
> > investigated, and most of them fixed; patches are reviewed, commented,
> > and installed.  We'd love better tools -- who won't? -- but every tool
> > we examined until now had important gaps.
> 
> Important for allowing more people participate in the conversations.

That's not the main goal of these tools, as far as the maintainers are
considered.

> >> And the cost is not zero, the cost is the people that never set foot
> >> in our community.
> > 
> > That cost is largely imaginary, and "never set foot" is an
> > exaggeration.  The same was said about the switch to Git, for example,
> > but the situation hasn't changed much, if the number of active
> > maintainers/developers is concerned.  It is better, but only slightly
> > so.
> 
> I think you're failing to adjust for natural attrition.

Maybe.  Who will tell?  I only know the facts.

> And the effect will naturally be smaller when only one difficult part of 
> the workflow is replaced, while other remain. It's just like with other 
> performance optimizations.

Maybe.  We won't know unless we try.

> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's 
> hard to argue that Emacs is more complex, or even comparable, to 
> Firefox.

No, it isn't hard.  Compare the number of domains whose expertise we
need, that's the important aspect.

> And if they reached this size in 20 years rather than 40, it's 
> an evidence to better productivity rather than the opposite, right?

They have a Web browser, that's all.

> > What is missing is the number of active developers in each project
> > (which requires a definition of "active developer"), the means and
> > tools they use for issue tracking, and whatever else is relevant.
> 
> According to 
> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/ 
> (article from 2017),
> 
>    > 700 authors contributed code to Firefox over ~1 year
> 
>    80 of them were volunteers, "contributors from all over the world".
> 
> and by those 700 authors:
> 
>    75,342 files changed
>    4,888,199 lines were added
>    6,886,199 lines were changed

Counting just "authors" and "contributors" doesn't tell enough, but at
least show the comparable numbers for Emacs, okay?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 16:09, Eli Zaretskii wrote:

> your contributions and efforts are greatly appreciated, but that's not
> what I meant.  I meant leading the migration process to the
> (allegedly) new and better tools, then assessing how well they fit us
> and making whatever changes are needed, or concluding they failed the
> tests.

Thank you, of course.

But I'm not sure I could lead anything in this process, given that we 
can't seem to agree on the basic goals.

>>> It is definitely _un_reasonable to suggest/demand such changes when
>>> you are doing nothing in practice towards that goal.
>>
>> What do you want me to do? Set up a standalone Bugzilla installation for
>> people to try out? There is an existing demo at
>> https://bugzilla-dev.allizom.org/home.
>>
>> Create a migration script from the Debbugs database to Bugzilla's
>> format?
> 
> Some of that, yes.
> 
>> I could probably do that too. But that would result in nothing
>> without the leadership's buy-in, just like our Gitlab instance is
>> stagnating for a couple of years now.
> 
> If you do a good job, and the tools are useful, they _will_ be used,
> and then a buy-in might be a no-brainer.  We will see when we get
> there.

There is no point in me doing either, if the catching issue is how other 
developers find it possible (or not) to work with specific tools. 
Migrating the database isn't going to change that.

Should we go through another round of listing bug trackers and voting, 
or something?

>>>> The existing tools "lack important features" to such a degree that it's
>>>> not even funny.
>>>
>>> "Important" for whom?  We are doing a reasonable job with them, given
>>> the available human resources, don't we?  Bugs are triaged,
>>> investigated, and most of them fixed; patches are reviewed, commented,
>>> and installed.  We'd love better tools -- who won't? -- but every tool
>>> we examined until now had important gaps.
>>
>> Important for allowing more people participate in the conversations.
> 
> That's not the main goal of these tools, as far as the maintainers are
> considered.

If collecting user feedback and communicating with users is not the main 
goal, and reducing maintainers' workload is the priority, I guess we 
should stop asking for more code to be contributed in Emacs. At least as 
far as anything that can possibly live in ELPA is concerned (meaning: 
clojure-ts-mode yes, project.el or xref no). Let the developers use the 
trackers they are comfortable with, with maximum flexibility. The 
proverbial "lean core".

BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue 
of Emacs 29.1 users having ts modes incompatible with the latest 
grammars (they'd just upgrade Elisp code over ELPA).

>> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's
>> hard to argue that Emacs is more complex, or even comparable, to
>> Firefox.
> 
> No, it isn't hard.  Compare the number of domains whose expertise we
> need, that's the important aspect.

They would obviously have more.

>> And if they reached this size in 20 years rather than 40, it's
>> an evidence to better productivity rather than the opposite, right?
> 
> They have a Web browser, that's all.

Yeah, a program written in C/C++/Rust which contains an interpreter (and 
multiple jit's) for a dynamic programming language and has most of its 
interface written in it, supports user extensions in the same language, 
support display of arbitrary files and has several related but different 
mechanisms for guiding the visuals and the layout of said display. It 
also supports bidi.

>>> What is missing is the number of active developers in each project
>>> (which requires a definition of "active developer"), the means and
>>> tools they use for issue tracking, and whatever else is relevant.
>>
>> According to
>> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/
>> (article from 2017),
>>
>>     > 700 authors contributed code to Firefox over ~1 year
>>
>>     80 of them were volunteers, "contributors from all over the world".
>>
>> and by those 700 authors:
>>
>>     75,342 files changed
>>     4,888,199 lines were added
>>     6,886,199 lines were changed
> 
> Counting just "authors" and "contributors" doesn't tell enough, but at
> least show the comparable numbers for Emacs, okay?

I figured you have said numbers at hand, more or less. But they must be 
lower.

If you like I can try producing them, but what point would you be trying 
to make?

The point I was trying to make that a big and complex project with many 
contributors (bigger than ours, more complex than ours, with more 
developers than here) can be well-served by a workflow that is rather 
different from ours.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 27 Aug 2023 21:13:24 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 16:09, Eli Zaretskii wrote:
> 
> > your contributions and efforts are greatly appreciated, but that's not
> > what I meant.  I meant leading the migration process to the
> > (allegedly) new and better tools, then assessing how well they fit us
> > and making whatever changes are needed, or concluding they failed the
> > tests.
> 
> Thank you, of course.
> 
> But I'm not sure I could lead anything in this process, given that we 
> can't seem to agree on the basic goals.

I don't know why you decided we don't agree on the goals.  I think we
do; the list of requirements for these tools was posted, and AFAIR was
agreed upon.

> > If you do a good job, and the tools are useful, they _will_ be used,
> > and then a buy-in might be a no-brainer.  We will see when we get
> > there.
> 
> There is no point in me doing either, if the catching issue is how other 
> developers find it possible (or not) to work with specific tools. 

Again, I don't understand how or why you arrived to that conclusion.
I don't think it is correct.

> Should we go through another round of listing bug trackers and voting, 
> or something?

What for?  We need tools that satisfy certain requirements, why does
it matter how they are called?  If we find a set of tools that can
support our requirements, at least most of the important ones, we
could try using them, and only then it will be known whether the
workflows are good enough and whether the features that are missing
are critical.

And voting is absolutely the worst method of getting anything
significant done around here.  If I used voting for decisions how to
implement bidi, I would still be discussing this on the (now defunct)
emacs-bidi list, instead of having a working implementation.

> >> Important for allowing more people participate in the conversations.
> > 
> > That's not the main goal of these tools, as far as the maintainers are
> > considered.
> 
> If collecting user feedback and communicating with users is not the main 
> goal, and reducing maintainers' workload is the priority, I guess we 
> should stop asking for more code to be contributed in Emacs.

Please don't exaggerate and don't consider this a zero-sum game.  We
want tools that facilitate feedback, but their primary goal is to
allow development and maintenance of Emacs.  That should be a
no-brainer, and I'm frankly astonished this is something that needs to
be argued about.  What would be the purpose of collecting user
feedback and communicating with users if we cannot efficiently apply
that to development and maintenance??

> At least as far as anything that can possibly live in ELPA is
> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let
> the developers use the trackers they are comfortable with, with
> maximum flexibility. The proverbial "lean core".

I'm not aware that ELPA packages are forced to use debbugs.  We accept
reports about them on debbugs, but don't enforce that, at least AFAIK.

> BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue 
> of Emacs 29.1 users having ts modes incompatible with the latest 
> grammars (they'd just upgrade Elisp code over ELPA).

Not true.  Moving a mode to ELPA doesn't solve that particular problem
(or any other one).  On the contrary: having those not bundled would
mean users don't have an OOTB solution, and would need to invent their
own wheels.  It also means the instructions about how to install the
relevant grammars would not have been in NEWS, so users would need to
discover that by themselves.  And the command we added to treesit.el
for installing the grammars would be missing as well.  Not to mention
the documentation in the user manual.

These are the immediate downsides of having a package outside of the
core.

> >> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's
> >> hard to argue that Emacs is more complex, or even comparable, to
> >> Firefox.
> > 
> > No, it isn't hard.  Compare the number of domains whose expertise we
> > need, that's the important aspect.
> 
> They would obviously have more.

Yeah, right.

The list of the kinds of domain expertise we need in Emacs was posted
in the past, most of it is not needed for those other projects.

> >> And if they reached this size in 20 years rather than 40, it's
> >> an evidence to better productivity rather than the opposite, right?
> > 
> > They have a Web browser, that's all.
> 
> Yeah, a program written in C/C++/Rust which contains an interpreter (and 
> multiple jit's) for a dynamic programming language and has most of its 
> interface written in it, supports user extensions in the same language, 
> support display of arbitrary files and has several related but different 
> mechanisms for guiding the visuals and the layout of said display. It 
> also supports bidi.

It's just a browser.  All the features you mention are used for Web
browsing.

> >> According to
> >> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/
> >> (article from 2017),
> >>
> >>     > 700 authors contributed code to Firefox over ~1 year
> >>
> >>     80 of them were volunteers, "contributors from all over the world".
> >>
> >> and by those 700 authors:
> >>
> >>     75,342 files changed
> >>     4,888,199 lines were added
> >>     6,886,199 lines were changed
> > 
> > Counting just "authors" and "contributors" doesn't tell enough, but at
> > least show the comparable numbers for Emacs, okay?
> 
> I figured you have said numbers at hand, more or less. But they must be 
> lower.

I'm not sure they will be lower.

> If you like I can try producing them, but what point would you be trying 
> to make?

My point is that Emacs maintenance is a much more complex and
difficult job than the job of those projects.

> The point I was trying to make that a big and complex project with many 
> contributors (bigger than ours, more complex than ours, with more 
> developers than here) can be well-served by a workflow that is rather 
> different from ours.

This remains to be shown, because the raw unanalyzed numbers you've
presented don't provide sufficient evidence.

Choice of bug tracker

[Dmitry Gutov]

On 27/08/2023 21:46, Eli Zaretskii wrote:

> I don't know why you decided we don't agree on the goals.  I think we
> do;
 > the list of requirements for these tools was posted, and AFAIR was
 > agreed upon.

"Agreed upon" maybe in the sense that the leadership sort-of-promised to 
seriously consider a bug tracker which would satisfy the whole list of 
them. Alas, there are none around.

I'm not sure how we could make progress without revisiting said 
requirements and our priorities.

>>> If you do a good job, and the tools are useful, they _will_ be used,
>>> and then a buy-in might be a no-brainer.  We will see when we get
>>> there.
>>
>> There is no point in me doing either, if the catching issue is how other
>> developers find it possible (or not) to work with specific tools.
> 
> Again, I don't understand how or why you arrived to that conclusion.
> I don't think it is correct.

I might very well be mistaken in my conclusion (happy to be), but it 
should be easy to see how I arrived at it.

>> Should we go through another round of listing bug trackers and voting,
>> or something?
> 
> What for?  We need tools that satisfy certain requirements, why does
> it matter how they are called?  If we find a set of tools that can
> support our requirements, at least most of the important ones, we
> could try using them, and only then it will be known whether the
> workflows are good enough and whether the features that are missing
> are critical.

The phrase "most of the important ones" gives me a bit of hope.

> And voting is absolutely the worst method of getting anything
> significant done around here.  If I used voting for decisions how to
> implement bidi, I would still be discussing this on the (now defunct)
> emacs-bidi list, instead of having a working implementation.

Voting would be one of the ways to arrive at those "only important 
requirements". It's not so bad because familiarity is helpful as well 
(as we're all aware here, all with existing habits and preferences).

Or someone in charge could revisit the list and separate the more 
important requirements from "less important" ones.

>>>> Important for allowing more people participate in the conversations.
>>>
>>> That's not the main goal of these tools, as far as the maintainers are
>>> considered.
>>
>> If collecting user feedback and communicating with users is not the main
>> goal, and reducing maintainers' workload is the priority, I guess we
>> should stop asking for more code to be contributed in Emacs.
> 
> Please don't exaggerate and don't consider this a zero-sum game.  We
> want tools that facilitate feedback, but their primary goal is to
> allow development and maintenance of Emacs.  That should be a
> no-brainer, and I'm frankly astonished this is something that needs to
> be argued about.  What would be the purpose of collecting user
> feedback and communicating with users if we cannot efficiently apply
> that to development and maintenance??

We could apply that information less efficiently, I guess? Though 
whether it's more or less would strongly depend on individual habits.

>> At least as far as anything that can possibly live in ELPA is
>> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let
>> the developers use the trackers they are comfortable with, with
>> maximum flexibility. The proverbial "lean core".
> 
> I'm not aware that ELPA packages are forced to use debbugs.  We accept
> reports about them on debbugs, but don't enforce that, at least AFAIK.

That's what I was saying: if we encouraged the use of ELPA more, the 
issue of our common bug tracker (and whether it's good or not) would be 
a little less important. Though probably not

>> BTW, if js-ts-mode and others lived in ELPA, there wouldn't be an issue
>> of Emacs 29.1 users having ts modes incompatible with the latest
>> grammars (they'd just upgrade Elisp code over ELPA).
> 
> Not true.  Moving a mode to ELPA doesn't solve that particular problem
> (or any other one).

But it does. Makes it better, at least. Makes the solution more obvious 
to the user (I installed it from there -> there is an update -> I'll 
update it from there now).

> On the contrary: having those not bundled would
> mean users don't have an OOTB solution, and would need to invent their
> own wheels.

You can't say "on the contrary" and then go on to state something 
orthogonal.

'M-x package-install' works, there is nothing to invent. But it would be 
good if the core leads paid more attention to it and ELPA in general.

>  It also means the instructions about how to install the
> relevant grammars would not have been in NEWS, so users would need to
> discover that by themselves.

We could have another NEWS file for ELPA, annotated with timestamps 
and/or Emacs versions as well. A common NEWS feed is easy enough to do 
for the whole ELPA as well.

> And the command we added to treesit.el
> for installing the grammars would be missing as well.  Not to mention
> the documentation in the user manual.

I think treesit.el (since it's inseparable from treesit.c) would still 
be in the core. Along with all its manual entries.

But ELPA packages can have their own manuals too, JFYI.

> These are the immediate downsides of having a package outside of the
> core.
> 
>>>> Perhaps Lisp is denser than JavaScript or C, and et cetera, but it's
>>>> hard to argue that Emacs is more complex, or even comparable, to
>>>> Firefox.
>>>
>>> No, it isn't hard.  Compare the number of domains whose expertise we
>>> need, that's the important aspect.
>>
>> They would obviously have more.
> 
> Yeah, right.
> 
> The list of the kinds of domain expertise we need in Emacs was posted
> in the past, most of it is not needed for those other projects.

For... web browsers? They are known to be some of the most complex 
pieces of software around, these days.

>>>> And if they reached this size in 20 years rather than 40, it's
>>>> an evidence to better productivity rather than the opposite, right?
>>>
>>> They have a Web browser, that's all.
>>
>> Yeah, a program written in C/C++/Rust which contains an interpreter (and
>> multiple jit's) for a dynamic programming language and has most of its
>> interface written in it, supports user extensions in the same language,
>> support display of arbitrary files and has several related but different
>> mechanisms for guiding the visuals and the layout of said display. It
>> also supports bidi.
> 
> It's just a browser.  All the features you mention are used for Web
> browsing.

And we're talking on the mailing list for "just a text editor".

>>>> According to
>>>> https://blog.mozilla.org/en/products/firefox/the-new-firefox-by-the-numbers/
>>>> (article from 2017),
>>>>
>>>>      > 700 authors contributed code to Firefox over ~1 year
>>>>
>>>>      80 of them were volunteers, "contributors from all over the world".
>>>>
>>>> and by those 700 authors:
>>>>
>>>>      75,342 files changed
>>>>      4,888,199 lines were added
>>>>      6,886,199 lines were changed
>>>
>>> Counting just "authors" and "contributors" doesn't tell enough, but at
>>> least show the comparable numbers for Emacs, okay?
>>
>> I figured you have said numbers at hand, more or less. But they must be
>> lower.
> 
> I'm not sure they will be lower.

Number of lines changed over a year?

The above numbers are 2x and 3x above our total number of lines. And the 
number of changed files is 15x our total.

>> If you like I can try producing them, but what point would you be trying
>> to make?
> 
> My point is that Emacs maintenance is a much more complex and
> difficult job than the job of those projects.
> 
>> The point I was trying to make that a big and complex project with many
>> contributors (bigger than ours, more complex than ours, with more
>> developers than here) can be well-served by a workflow that is rather
>> different from ours.
> 
> This remains to be shown, because the raw unanalyzed numbers you've
> presented don't provide sufficient evidence.

I'm not sure what other numbers I could provide, but if you ask 
specifically, I could try.

BTW, another project using gitlab I was thinking of is Mesa. Perhaps 
reading their moving announcement (from 5 years ago) would be of 
interest to some: 
https://lists.freedesktop.org/archives/mesa-dev/2018-May/195634.html 
There is a subsequent discussion thread as well.

There seems to be a fair amount of nostalgia there toward Bugzilla, in 
that thread (apparently from people who do like mailing list driven 
workflows for development).

Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 00:15:46 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 27/08/2023 21:46, Eli Zaretskii wrote:
> 
> > I don't know why you decided we don't agree on the goals.  I think we
> > do;
>  > the list of requirements for these tools was posted, and AFAIR was
>  > agreed upon.
> 
> "Agreed upon" maybe in the sense that the leadership sort-of-promised to 
> seriously consider a bug tracker which would satisfy the whole list of 
> them.

That's not my position, FWIW.  I'm ready to try some less-than-perfect
bug trackers, if the things they lack are relatively minor.

The problem from my POV was that alternatives were researched, the
results of the research were published and discussed, the downsides
identified, and then the process stalled, perhaps because people got
disappointed by the deficiencies.

> Voting would be one of the ways to arrive at those "only important 
> requirements". It's not so bad because familiarity is helpful as well 
> (as we're all aware here, all with existing habits and preferences).
> 
> Or someone in charge could revisit the list and separate the more 
> important requirements from "less important" ones.

I'd prefer that "someone in charge" took a leap of hope, produced some
site we could use, and let us try it and see how workable is it.  If
that/those person(s) did a good job, and would be ready to work on
fixing the issues reported during the initial use until we could make
the final decision, we could have some hope of finding a better tool.
the main challenge in this particular endeavor is that we'd need to
use two different trackers in parallel, at least for some time, so
some solution for syncing them would be in order.

I hope something like this would be possible.

> > Please don't exaggerate and don't consider this a zero-sum game.  We
> > want tools that facilitate feedback, but their primary goal is to
> > allow development and maintenance of Emacs.  That should be a
> > no-brainer, and I'm frankly astonished this is something that needs to
> > be argued about.  What would be the purpose of collecting user
> > feedback and communicating with users if we cannot efficiently apply
> > that to development and maintenance??
> 
> We could apply that information less efficiently, I guess? Though 
> whether it's more or less would strongly depend on individual habits.

The crucial (for me) question is: how much less efficiently?  With the
current mail-based flows, reviewing a patch is a snap, and applying a
patch takes mere seconds, even if I need to fix the commit message.
If seconds become minutes, it would be bad for productivity, and
eventually bad for our development rate.

> >> At least as far as anything that can possibly live in ELPA is
> >> concerned (meaning: clojure-ts-mode yes, project.el or xref no). Let
> >> the developers use the trackers they are comfortable with, with
> >> maximum flexibility. The proverbial "lean core".
> > 
> > I'm not aware that ELPA packages are forced to use debbugs.  We accept
> > reports about them on debbugs, but don't enforce that, at least AFAIK.
> 
> That's what I was saying: if we encouraged the use of ELPA more, the 
> issue of our common bug tracker (and whether it's good or not) would be 
> a little less important. Though probably not

There are known issues with moving more stuff to ELPA, and they have
been discussed.  IME, trying to solve too many non-trivial problems
together makes the problem much harder, sometimes insoluble.

> >  It also means the instructions about how to install the
> > relevant grammars would not have been in NEWS, so users would need to
> > discover that by themselves.
> 
> We could have another NEWS file for ELPA, annotated with timestamps 
> and/or Emacs versions as well. A common NEWS feed is easy enough to do 
> for the whole ELPA as well.

There would be no motivation for that.  Fact is we don't have such a
file now, and there are good reasons for that.

> > And the command we added to treesit.el
> > for installing the grammars would be missing as well.  Not to mention
> > the documentation in the user manual.
> 
> I think treesit.el (since it's inseparable from treesit.c) would still 
> be in the core. Along with all its manual entries.

But the motivation to support unbundled packages would be gone.  I'
for example, would not insist on having such a command if it supports
only 3rd-party packages.

> But ELPA packages can have their own manuals too, JFYI.

I know.  But who monitors their quality and works on improving them?

> >>> No, it isn't hard.  Compare the number of domains whose expertise we
> >>> need, that's the important aspect.
> >>
> >> They would obviously have more.
> > 
> > Yeah, right.
> > 
> > The list of the kinds of domain expertise we need in Emacs was posted
> > in the past, most of it is not needed for those other projects.
> 
> For... web browsers? They are known to be some of the most complex 
> pieces of software around, these days.

We are talking here about different expertise domains, not about
software complexity.  What browser needs to have experts in PL design
and implementation, in byte-compilation, in syntax analysis, in dozens
of text encodings and in Unicode standards and algorithms in general,
in half a dozen GUI toolkits and window-system events on several
platforms, in email, file I/O, sub-processes, search and replace
algorithms, in support of dozens of different programming and markup
languages?  How many of them support both GUI and TTY displays with
basically the same code?  Emacs has all of those and more, and the
day-to-day routine maintenance requires us to apply knowledge in most
of these domains.

> > I'm not sure they will be lower.
> 
> Number of lines changed over a year?
> 
> The above numbers are 2x and 3x above our total number of lines. And the 
> number of changed files is 15x our total.

They are also much higher than the LOC counts of the respective
packages, so why aren't you surprised in that case?

> There seems to be a fair amount of nostalgia there toward Bugzilla, in 
> that thread (apparently from people who do like mailing list driven 
> workflows for development).

I don't remember why we rejected Bugzilla (email support, maybe?).  I
use it (admittedly, not intensely enough) when I need to report bugs
or submit patches to GDB and Binutils, and find it quite convenient.

Re: Choice of bug tracker

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> writes:

> That's not my position, FWIW.  I'm ready to try some less-than-perfect
> bug trackers, if the things they lack are relatively minor.
>
> The problem from my POV was that alternatives were researched, the
> results of the research were published and discussed, the downsides
> identified, and then the process stalled, perhaps because people got
> disappointed by the deficiencies.
>
[...]
> I'd prefer that "someone in charge" took a leap of hope, produced some
> site we could use, and let us try it and see how workable is it.  If
> that/those person(s) did a good job, and would be ready to work on
> fixing the issues reported during the initial use until we could make
> the final decision, we could have some hope of finding a better tool.
> the main challenge in this particular endeavor is that we'd need to
> use two different trackers in parallel, at least for some time, so
> some solution for syncing them would be in order.
>
> I hope something like this would be possible.
>
[...]
> The crucial (for me) question is: how much less efficiently?  With the
> current mail-based flows, reviewing a patch is a snap, and applying a
> patch takes mere seconds, even if I need to fix the commit message.
> If seconds become minutes, it would be bad for productivity, and
> eventually bad for our development rate.

FWIW, I fully agree with everything that Eli is saying above.

So it seems to me that we're mostly looking for one or more volunteers
to do this important work.  Any takers?

Re: Choice of bug tracker

[Dmitry Gutov]

On 28/08/2023 14:45, Eli Zaretskii wrote:
>> Date: Mon, 28 Aug 2023 00:15:46 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>   emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>> On 27/08/2023 21:46, Eli Zaretskii wrote:
>>
>>> I don't know why you decided we don't agree on the goals.  I think we
>>> do;
>>   > the list of requirements for these tools was posted, and AFAIR was
>>   > agreed upon.
>>
>> "Agreed upon" maybe in the sense that the leadership sort-of-promised to
>> seriously consider a bug tracker which would satisfy the whole list of
>> them.
> 
> That's not my position, FWIW.  I'm ready to try some less-than-perfect
> bug trackers, if the things they lack are relatively minor.
> 
> The problem from my POV was that alternatives were researched, the
> results of the research were published and discussed, the downsides
> identified, and then the process stalled, perhaps because people got
> disappointed by the deficiencies.

Last time we produced this overblown list which mixed necessities with 
nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Some of the things there:

  - ReCaptcha replacement (actually seems fixed now: 
https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493)
  - LibreJS (we already know the JS files have satisfactory licenses; 
there was a fair amount of discussion around the assets pipeline, but no 
resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196)

There were also a few functional things like inability to include diffs 
in Merge Request notifications which seems like a genuine omission, that 
seems easy to sell to gitlabbers, and I wouldn't mind looking into.

>> Or someone in charge could revisit the list and separate the more
>> important requirements from "less important" ones.
> 
> I'd prefer that "someone in charge" took a leap of hope, produced some
> site we could use, and let us try it and see how workable is it.  If
> that/those person(s) did a good job, and would be ready to work on
> fixing the issues reported during the initial use until we could make
> the final decision, we could have some hope of finding a better tool.
> the main challenge in this particular endeavor is that we'd need to
> use two different trackers in parallel, at least for some time, so
> some solution for syncing them would be in order.

Regarding "workability", we have EMBA for people to try out. It's been 
there for several years. Unless Gitlab is crossed out from the list of 
contestants already.

There is an online demo for Bugzilla. I'm not sure if we need a 
dedicated one, but if yes, that could also be arranged.

>>> Please don't exaggerate and don't consider this a zero-sum game.  We
>>> want tools that facilitate feedback, but their primary goal is to
>>> allow development and maintenance of Emacs.  That should be a
>>> no-brainer, and I'm frankly astonished this is something that needs to
>>> be argued about.  What would be the purpose of collecting user
>>> feedback and communicating with users if we cannot efficiently apply
>>> that to development and maintenance??
>>
>> We could apply that information less efficiently, I guess? Though
>> whether it's more or less would strongly depend on individual habits.
> 
> The crucial (for me) question is: how much less efficiently?  With the
> current mail-based flows, reviewing a patch is a snap, and applying a
> patch takes mere seconds, even if I need to fix the commit message.
> If seconds become minutes, it would be bad for productivity, and
> eventually bad for our development rate.

I don't see how they become minutes (even browser web pages don't take 
this long to load), and it's a matter of habit. Anyway, both Gitlab and 
Bugzilla have means of interacting through email. Any serious omissions 
can be looked into as well (also see (*)).

>>>   It also means the instructions about how to install the
>>> relevant grammars would not have been in NEWS, so users would need to
>>> discover that by themselves.
>>
>> We could have another NEWS file for ELPA, annotated with timestamps
>> and/or Emacs versions as well. A common NEWS feed is easy enough to do
>> for the whole ELPA as well.
> 
> There would be no motivation for that.  Fact is we don't have such a
> file now, and there are good reasons for that.

We could also have an entry in Emacs 29's NEWS specifically about the 
new ts major modes that have just been added to ELPA. Since they 
wouldn't work with earlier versions of Emacs anyway, that seems appropriate.

>>> And the command we added to treesit.el
>>> for installing the grammars would be missing as well.  Not to mention
>>> the documentation in the user manual.
>>
>> I think treesit.el (since it's inseparable from treesit.c) would still
>> be in the core. Along with all its manual entries.
> 
> But the motivation to support unbundled packages would be gone.  I'
> for example, would not insist on having such a command if it supports
> only 3rd-party packages.
> 
>> But ELPA packages can have their own manuals too, JFYI.
> 
> I know.  But who monitors their quality and works on improving them?

That's the thing: GNU ELPA is supposedly "part of Emacs". So that 
responsibility is ours, I guess. At least to a certain extent.

Currently it's a matter of trusting existing maintainers, which isn't 
the worst thing to do, too.

>>> I'm not sure they will be lower.
>>
>> Number of lines changed over a year?
>>
>> The above numbers are 2x and 3x above our total number of lines. And the
>> number of changed files is 15x our total.
> 
> They are also much higher than the LOC counts of the respective
> packages, so why aren't you surprised in that case?

Mozilla's line count is said to be 20M lines, and the changes were 
counted in 6M changes, 3M deletions over a year. So that checks out.

It all depends on the exact counting method, of course (whether each 
individual diffs' numbers are added, or whether the total diff over a 
year is used; I'm assuming Mozilla's report is about the latter).

>> There seems to be a fair amount of nostalgia there toward Bugzilla, in
>> that thread (apparently from people who do like mailing list driven
>> workflows for development).
> 
> I don't remember why we rejected Bugzilla (email support, maybe?).  I
> use it (admittedly, not intensely enough) when I need to report bugs
> or submit patches to GDB and Binutils, and find it quite convenient.

I suppose it was not in the list of "forges" because it only provides 
bug tracking. If we don't manage to switch to Gitlab or SourceHut, we 
can try using Bugzilla, at least. I'm not loving its "new bug" and the 
nonexistent "most recent issues/activity" pages, but it would still be 
an improvement.

(*) It does support modifying bugs over email. I just yesterday sent a 
link to the documentation to its "Inbound Email Interface" to Po Lu, 
which is a Perl script that works on the postfix MTA (maybe other too, 
IDK) being invoked through .procmail.

That discovery actually tells me two things:
1) Many/most email workflows will probably work with Bugzilla,
2) Other bug trackers/forges which have any kind of web API can be 
adapted in a similar fashion: running a script when an email is received 
is easier than implementing a new feature in Gitlab, with 
UI/settings/permissions, so if we find that Gitlab is otherwise okay but 
its capability to modify issues over email is lacking, I can volunteer 
to look into this too.

The main limitation, however, is that this design requires people to 
create accounts in the system. Even just to file new reports. We could 
have a system/bot which would create issues for anonymous users as well, 
but it's not clear how we would resolve any follow-up questions which 
usually arise.

Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Tue, 29 Aug 2023 00:16:09 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> > The problem from my POV was that alternatives were researched, the
> > results of the research were published and discussed, the downsides
> > identified, and then the process stalled, perhaps because people got
> > disappointed by the deficiencies.
> 
> Last time we produced this overblown list which mixed necessities with 
> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152

That list is just our reference and a repository of ideas that came up
in the discussions.  The real requirements are simpler:

  . we must have support for feature we have now on debbugs
  . we should decide which additional features are the absolute
    minimum to justify the switch (those which will attract
    contributors, make feedback easier, and help people who are more
    used to PR-type workflow)
  . all the other features that debbugs doesn't have are a bonus, but
    not hard requirements

Re: Choice of bug tracker

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 29 Aug 2023 00:16:09 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>  emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> > The problem from my POV was that alternatives were researched, the
>> > results of the research were published and discussed, the downsides
>> > identified, and then the process stalled, perhaps because people got
>> > disappointed by the deficiencies.
>> 
>> Last time we produced this overblown list which mixed necessities with 
>> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
>
> That list is just our reference and a repository of ideas that came up
> in the discussions.  The real requirements are simpler:
>
>   . we must have support for feature we have now on debbugs

We count the fact that everything can everything can be done via Email
as a feature, right?

>   . we should decide which additional features are the absolute
>     minimum to justify the switch (those which will attract
>     contributors, make feedback easier, and help people who are more
>     used to PR-type workflow)
>   . all the other features that debbugs doesn't have are a bonus, but
>     not hard requirements

Re: Choice of bug tracker

[Po Lu]

Philip Kaludercic <philipk@posteo.net> writes:

> We count the fact that everything can everything can be done via Email
> as a feature, right?

I think so.  I hope we will also consider the capacity for separate
threads of discussion within an individual bug report a feature.

I would also appreciate if the bug tracker did not adorn emails
transmitted through it with its own embellishments, something Bugzilla
does with alacrity (as evidenced in the traffic of the bug-binutils
list.)

Re: Choice of bug tracker

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> We count the fact that everything can everything can be done via Email
>> as a feature, right?
>
> I think so.  I hope we will also consider the capacity for separate
> threads of discussion within an individual bug report a feature.

But isn't it discouraged in debbugs?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[brickviking]

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

On Thu, 31 Aug 2023 at 22:34, Ihor Radchenko <yantar92@posteo.net> wrote:

> Po Lu <luangruo@yahoo.com> writes:
>
> > Philip Kaludercic <philipk@posteo.net> writes:
> >
> >> We count the fact that everything can everything can be done via Email
> >> as a feature, right?
> >
> > I think so.  I hope we will also consider the capacity for separate
> > threads of discussion within an individual bug report a feature.
>
> But isn't it discouraged in debbugs?
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>
What if there was a hypothetical bug report that actually had a multiple
number of things to address, but was only being reported under the original
"bug" that the user reported on? That'd still be a good reason to be able
to discuss #bugnum, #bugnum-feature1, #bugnum-feature2 and so on. I'm
assuming that this is what debbugs is "discouraging"?

Regards, brickviking

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

Re: Choice of bug tracker

[Ihor Radchenko]

brickviking <brickviking@gmail.com> writes:

>> > I think so.  I hope we will also consider the capacity for separate
>> > threads of discussion within an individual bug report a feature.
>>
>> But isn't it discouraged in debbugs?
>> ...
> What if there was a hypothetical bug report that actually had a multiple
> number of things to address, but was only being reported under the original
> "bug" that the user reported on? That'd still be a good reason to be able
> to discuss #bugnum, #bugnum-feature1, #bugnum-feature2 and so on. I'm
> assuming that this is what debbugs is "discouraging"?

Yup. It feels "illegal" to open side discussions out of debbugs email
threads. Though, on the second thought, nothing should stop users from
branching off the thread into emacs-devel while dropping debbugs
address.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 13:53, Ihor Radchenko wrote:
> brickviking<brickviking@gmail.com>  writes:
> 
>>>> I think so.  I hope we will also consider the capacity for separate
>>>> threads of discussion within an individual bug report a feature.
>>> But isn't it discouraged in debbugs?
>>> ...
>> What if there was a hypothetical bug report that actually had a multiple
>> number of things to address, but was only being reported under the original
>> "bug" that the user reported on? That'd still be a good reason to be able
>> to discuss #bugnum, #bugnum-feature1, #bugnum-feature2 and so on. I'm
>> assuming that this is what debbugs is "discouraging"?
> Yup. It feels "illegal" to open side discussions out of debbugs email
> threads. Though, on the second thought, nothing should stop users from
> branching off the thread into emacs-devel while dropping debbugs
> address.

The common approach is modern trackers is to create a new issue# for 
every sub-discussion, and leave a link to it in the parent one.

Re: Choice of bug tracker

[Ihor Radchenko]

Dmitry Gutov <dmitry@gutov.dev> writes:

>> Yup. It feels "illegal" to open side discussions out of debbugs email
>> threads. Though, on the second thought, nothing should stop users from
>> branching off the thread into emacs-devel while dropping debbugs
>> address.
>
> The common approach is modern trackers is to create a new issue# for 
> every sub-discussion, and leave a link to it in the parent one.

... and it is what I dislike about modern trackers.
Email threads make such branching trivial.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: brickviking <brickviking@gmail.com>, emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 11:03:44 +0000
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> >> Yup. It feels "illegal" to open side discussions out of debbugs email
> >> threads. Though, on the second thought, nothing should stop users from
> >> branching off the thread into emacs-devel while dropping debbugs
> >> address.
> >
> > The common approach is modern trackers is to create a new issue# for 
> > every sub-discussion, and leave a link to it in the parent one.
> 
> ... and it is what I dislike about modern trackers.
> Email threads make such branching trivial.

It isn't trivial when people respond to several threads in the same
message.  You can see examples of this on this list, just look at the
recent large threads.

Re: Choice of bug tracker

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > The common approach is modern trackers is to create a new issue# for 
>> > every sub-discussion, and leave a link to it in the parent one.
>> 
>> ... and it is what I dislike about modern trackers.
>> Email threads make such branching trivial.
>
> It isn't trivial when people respond to several threads in the same
> message.  You can see examples of this on this list, just look at the
> recent large threads.

I can see how that is a problem. So, is it a +1 for "modern trackers"
and -1 for "mailing lists"?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Stefan Kangas]

Ihor Radchenko <yantar92@posteo.net> writes:

> > It isn't trivial when people respond to several threads in the same
> > message.  You can see examples of this on this list, just look at the
> > recent large threads.
>
> I can see how that is a problem. So, is it a +1 for "modern trackers"
> and -1 for "mailing lists"?

Perhaps, yes.  I'd definitely be much happier if we had a bug tracker
that made it possible to split threads after the fact.  If that's
something you can do with a "modern tracker", then it would certainly
help.

We are more disciplined these days, but I have seen many old,
sprawling bug threads with dozens upon dozens of replies, more than
half of which are about something else entirely.  Coming back to such
threads after N years, as I've often done, it does take a long time to
find some signal in there: to figure out what is fixed, what is not,
what is a separate issue, and so on.

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 23:44, Stefan Kangas wrote:
> Ihor Radchenko<yantar92@posteo.net>  writes:
> 
>>> It isn't trivial when people respond to several threads in the same
>>> message.  You can see examples of this on this list, just look at the
>>> recent large threads.
>> I can see how that is a problem. So, is it a +1 for "modern trackers"
>> and -1 for "mailing lists"?
> Perhaps, yes.  I'd definitely be much happier if we had a bug tracker
> that made it possible to split threads after the fact.  If that's
> something you can do with a "modern tracker", then it would certainly
> help.
> 
> We are more disciplined these days, but I have seen many old,
> sprawling bug threads with dozens upon dozens of replies, more than
> half of which are about something else entirely.  Coming back to such
> threads after N years, as I've often done, it does take a long time to
> find some signal in there: to figure out what is fixed, what is not,
> what is a separate issue, and so on.

That would be nice to be able to do, but is that feasible?

If the main interface for interacting with discussions for many people 
remains their mail client, whatever we try to split after the fact (BTW, 
I know of such features in "forum software" similar to Discourse, but 
probably not in Gitlab's issues) wouldn't be reflected in everybody's 
existing mail archives.

This would only work if we/they used an Emacs client that worked off 
Gitlab's programmatic API instead, showing the most recent views. But 
that would take a fair amount of work to create, and wouldn't support 
the existing mail rules/filters/etc, at the very least.

A "modern tracker" could encourage us to use more structured threads 
going forward, though.

Re: Choice of bug tracker

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> That would be nice to be able to do, but is that feasible?

With mail?  No idea.  I've never seen anything like it.

I reacted to people saying that mail threads in debbugs are great for
keeping track of separate issues, because that's not always been my
experience.

> A "modern tracker" could encourage us to use more structured threads
> going forward, though.

That would be my hope, too.  The proof of the pudding is in the eating though.

Re: Choice of bug tracker

[Richard Stallman]

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

  > > We are more disciplined these days, but I have seen many old,
  > > sprawling bug threads with dozens upon dozens of replies, more than
  > > half of which are about something else entirely.

This is a serious but perhaps difficult question.
What is it that leads people to post about other topics
in a thread that is meant to be about a very specific topic?

I'm hoping for specific answers, not vague ones like "getting
distracted" or "carried away by a thought."  Those do happen, but I
would expect them to happen regardless of what interface is in use.

If it is true that something about email conduces to this, we ought to
be able to figure out concretely what it is.  And then maybe a
concrete change in email usage might make it less likely.


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

Drifting away from thread topic in large email discussions (was: Choice of bug tracker)

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > > We are more disciplined these days, but I have seen many old,
>   > > sprawling bug threads with dozens upon dozens of replies, more than
>   > > half of which are about something else entirely.
>
> This is a serious but perhaps difficult question.
> What is it that leads people to post about other topics
> in a thread that is meant to be about a very specific topic?
>
> I'm hoping for specific answers, not vague ones like "getting
> distracted" or "carried away by a thought."  Those do happen, but I
> would expect them to happen regardless of what interface is in use.

I can tell for myself, because I am guilty doing off-topic comments from
time to time.

I can recall three reasons:

1. When replying to email, I sometimes want to comment or ask something
   not directly on topic, but related to one of the points raised in a
   message I am replying to.

   I think about such questions when I am already writing the reply, and
   in the process of editing the quoted message I am replying to:

   > quote 1
   My on-topic answer.
   > quote 2
   Another on-topic answer.
   > quote 3
   By the way, what about <off-topic staff>
   > quote 4
   On topic again.

   I sometimes try to watch myself and reply with several messages,
   changing the email subject appropriately. But I only managed to
   remember doing this a handful of times only.

2.  Sometimes, the situation is even more subtle:

   > quote X
   _almost_ on-topic answer

   then, the reply to my reply will be

   >> quote X
   > _almost_ on-topic anser
   an answer drifting slightly further away

   <skip N replies>

   <totally off-topic>

3. On some cases, somebody clearly replies off-topic, but that off-topic
   still seems interesting to continue.

   Then, multiple answers sprawl, with some inevitably not changing the
   subject:

   Reply 1: <same subject>
   > off-topic quote
   Off-topic reply

   Reply 2: <same subject>
   > off-topic quote
   Off-topic reply 2

   Then, doing my own reply with

   My reply: <changed subject>
   feels pointless, because part of the new topic discussion will inevitably
   remain under the parent subject thread.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Richard Stallman]

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

  > We are more disciplined these days, but I have seen many old,
  > sprawling bug threads with dozens upon dozens of replies, more than
  > half of which are about something else entirely.

Any change in bug tracker will affect only future discussions.
Thus, the rambling nature of old threads is not really pertinent
to the issue at hand.

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

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 14:03, Ihor Radchenko wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>>> Yup. It feels "illegal" to open side discussions out of debbugs email
>>> threads. Though, on the second thought, nothing should stop users from
>>> branching off the thread into emacs-devel while dropping debbugs
>>> address.
>> The common approach is modern trackers is to create a new issue# for
>> every sub-discussion, and leave a link to it in the parent one.
> ... and it is what I dislike about modern trackers.
> Email threads make such branching trivial.

It indeed requires a little more overhead for branching, but OTOH the 
explicitness makes it easier to remember to split off issues, and since 
those appear separately as new threads, new such discussions are easier 
to notice when you are not reading everything.

The mailing-list style is lower-friction, but it's also messier: 
changing a subject is easier, but then if the discussion has been 
dragging on for a long time, nobody using Thunderbird, at least, will 
notice the change because the thread tree is so deep already, and there 
are cross-posts and stuff, which gitlab-style issue trackers make 
basically impossible.

A lot of that is also due to a limitation of how web UIs commonly look 
in those: the lists of messages are flat (hopefully they can still look 
threaded in the mail client), so the practice of separating different 
subthreads automatically became more important.

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: emacs-devel@gnu.org
> Date: Thu, 31 Aug 2023 10:53:26 +0000
> 
> brickviking <brickviking@gmail.com> writes:
> 
> >> > I think so.  I hope we will also consider the capacity for separate
> >> > threads of discussion within an individual bug report a feature.
> >>
> >> But isn't it discouraged in debbugs?
> >> ...
> > What if there was a hypothetical bug report that actually had a multiple
> > number of things to address, but was only being reported under the original
> > "bug" that the user reported on? That'd still be a good reason to be able
> > to discuss #bugnum, #bugnum-feature1, #bugnum-feature2 and so on. I'm
> > assuming that this is what debbugs is "discouraging"?
> 
> Yup. It feels "illegal" to open side discussions out of debbugs email
> threads. Though, on the second thought, nothing should stop users from
> branching off the thread into emacs-devel while dropping debbugs
> address.

Discussing several separate issues in the same bug report is
discouraged because (a) it makes reference to the discussion
problematic in the commit log messages, and (b) it makes the
discussion larger and harder to follow, since people frequently mix
several issues in a single response.

So our conventions when using debbugs is to open a separate bug report
for each issue.

Re: Choice of bug tracker

[Richard Stallman]

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

  > What if there was a hypothetical bug report that actually had a multiple
  > number of things to address, but was only being reported under the original
  > "bug" that the user reported on? That'd still be a good reason to be able
  > to discuss #bugnum, #bugnum-feature1, #bugnum-feature2 and so on. I'm
  > assuming that this is what debbugs is "discouraging"?

That suggests to me we would want a feature to split one bug report
ticket into multiple entirely separate tickets.  Or something that
could give the same results in practice.

That would be a lot easier to add than a way to subdivide one ticket
while keeping it somehow as one ticket.


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

Re: Choice of bug tracker

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> We count the fact that everything can everything can be done via Email
>>> as a feature, right?
>>
>> I think so.  I hope we will also consider the capacity for separate
>> threads of discussion within an individual bug report a feature.
>
> But isn't it discouraged in debbugs?

No, I think not.  It is crucial for separating different discussions
within a single bug report, which is a prerequisite for filtering out
those that are not of interest to me.

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>,  danny@dfreeman.email,
>   stefankangas@gmail.com,  emacs-devel@gnu.org,
>   manuel.uberti@inventati.org
> Date: Tue, 29 Aug 2023 11:58:19 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > That list is just our reference and a repository of ideas that came up
> > in the discussions.  The real requirements are simpler:
> >
> >   . we must have support for feature we have now on debbugs
> 
> We count the fact that everything can everything can be done via Email
> as a feature, right?

Not everything, only what's possible with debbugs.

Re: Choice of bug tracker

[Richard Stallman]

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

  > > We count the fact that everything can everything can be done via Email
  > > as a feature, right?

  > Not everything, only what's possible with debbugs.

I think that expanding what we can do with email is not a requirement,
but it is quite desirable.  A web interface can be snazzy and
superficially convenient, but email is superior fundamentally because
it is asynchronous, and because it is less capable of freedom
denial and mistreatment of users than a web browser can be.

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

Re: Choice of bug tracker

[Dmitry Gutov]

On 29/08/2023 14:26, Eli Zaretskii wrote:
>> Date: Tue, 29 Aug 2023 00:16:09 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>   emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>> The problem from my POV was that alternatives were researched, the
>>> results of the research were published and discussed, the downsides
>>> identified, and then the process stalled, perhaps because people got
>>> disappointed by the deficiencies.
>>
>> Last time we produced this overblown list which mixed necessities with
>> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
> 
> That list is just our reference and a repository of ideas that came up
> in the discussions.  The real requirements are simpler:
> 
>    . we must have support for feature we have now on debbugs

As a very reluctant user of Debbugs, I have say this is not a clear 
description for me. But as mentioned previously, the main features like 
modifying bug reports from email should either work, or are possible to 
implement/fix in a reasonable time frame.

The main thing I'm not sure about are bug reports from users without 
accounts, without requiring them to make accounts before making a bug 
report. We could even create an email address with an account which 
would create reports under its name, but forwarding subsequent 
correspondence on those issues back and forth seems more difficult. It's 
like we'd have to reimplement a mailing list, basically, but not a 
public one.

>    . we should decide which additional features are the absolute
>      minimum to justify the switch (those which will attract
>      contributors, make feedback easier, and help people who are more
>      used to PR-type workflow)

FWIW, PRs/MRs can be initially disabled, if most of the heavy 
contributors prefer to stay on the email-driven workflow.

Then, as people get comfortable with the rest of the changes, we can try 
and see how the presence of MRs from various contributors affects 
everybody's ability to review code and comment on them. Enable them for 
a certain period, and experiment, and so on.

Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Wed, 30 Aug 2023 03:11:21 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >    . we must have support for features we have now on debbugs
> 
> As a very reluctant user of Debbugs, I have say this is not a clear 
> description for me. But as mentioned previously, the main features like 
> modifying bug reports from email should either work, or are possible to 
> implement/fix in a reasonable time frame.

We could produce a detailed list of capabilities that must not regress
wrt debbugs, if that would be useful.  The number of those
capabilities is small.

> The main thing I'm not sure about are bug reports from users without 
> accounts, without requiring them to make accounts before making a bug 
> report. We could even create an email address with an account which 
> would create reports under its name, but forwarding subsequent 
> correspondence on those issues back and forth seems more difficult. It's 
> like we'd have to reimplement a mailing list, basically, but not a 
> public one.

I think it would be unfortunate to ask users to create an account just
to report a bug and ask questions about it.  At least the email
gateway should be free of this complication (for casual submitters,
not for the developers and maintainers whom we could ask to register).

> >    . we should decide which additional features are the absolute
> >      minimum to justify the switch (those which will attract
> >      contributors, make feedback easier, and help people who are more
> >      used to PR-type workflow)
> 
> FWIW, PRs/MRs can be initially disabled, if most of the heavy 
> contributors prefer to stay on the email-driven workflow.

I thought that was the single most important deficiency of debbugs?

If they aren't, then which capabilities _are_ important to have that
we don't have on debbugs?

Re: Choice of bug tracker

[Dmitry Gutov]

On 30/08/2023 14:24, Eli Zaretskii wrote:
>> Date: Wed, 30 Aug 2023 03:11:21 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>   emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>     . we must have support for features we have now on debbugs
>>
>> As a very reluctant user of Debbugs, I have say this is not a clear
>> description for me. But as mentioned previously, the main features like
>> modifying bug reports from email should either work, or are possible to
>> implement/fix in a reasonable time frame.
> 
> We could produce a detailed list of capabilities that must not regress
> wrt debbugs, if that would be useful.  The number of those
> capabilities is small.

That can help.

>> The main thing I'm not sure about are bug reports from users without
>> accounts, without requiring them to make accounts before making a bug
>> report. We could even create an email address with an account which
>> would create reports under its name, but forwarding subsequent
>> correspondence on those issues back and forth seems more difficult. It's
>> like we'd have to reimplement a mailing list, basically, but not a
>> public one.
> 
> I think it would be unfortunate to ask users to create an account just
> to report a bug and ask questions about it.  At least the email
> gateway should be free of this complication (for casual submitters,
> not for the developers and maintainers whom we could ask to register).

Like I said, it's feasible to set up an email gateway that is one-way. 
But juggling responses back to unregistered users and forwarding their 
emails again seems (for those discussions to be continued) like a 
full-blown mailing list software. Maybe something like that already 
exists or could be written without too many complications. I cannot 
guarantee that in advance, however. From what I see, none of the "big 
and popular" solutions have that kind of feature, even Bugzilla's 
"Inbound email gateway".

Though at their scale it's likely to result in too much spam anyway.

>>>     . we should decide which additional features are the absolute
>>>       minimum to justify the switch (those which will attract
>>>       contributors, make feedback easier, and help people who are more
>>>       used to PR-type workflow)
>>
>> FWIW, PRs/MRs can be initially disabled, if most of the heavy
>> contributors prefer to stay on the email-driven workflow.
> 
> I thought that was the single most important deficiency of debbugs?

It's a feature that could make it more pleasant/familiar for certain 
developers to contribute code, and lead the discussions around such new 
code (aka code review). But I wouldn't blame a bug tracker for not being 
a code review tool. Bugzilla isn't one either: it seems that projects 
using it used something like Gerrit for code review in the past (I have 
no experience with it).

> If they aren't, then which capabilities _are_ important to have that
> we don't have on debbugs?

Just the common bug tracker stuff, mostly related to Web UI (allowing 
one to easily read and join a discussion, subscribe to it, unsubscribe, 
syntax-highlighted code snippets, linking of issues between themselves, 
links between issues and commits, closing issues from commits, assigning 
issues to specific developers, ...). Also better working search and a 
very visible page "latest active issues/discussions".

I expect a more "modern" bug tracker to result in higher volume of bug 
reports (good and bad ones, as discussed previously), reports from more 
different kinds of users, possibly resulting in faster bug reports too. 
This is just a hypothesis (that a younger user has lower patience on 
average), but it seems logical to me.

Re: Choice of bug tracker

[Eli Zaretskii]

> Date: Wed, 30 Aug 2023 23:29:11 +0300
> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>  emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >>>     . we must have support for features we have now on debbugs
> >>
> >> As a very reluctant user of Debbugs, I have say this is not a clear
> >> description for me. But as mentioned previously, the main features like
> >> modifying bug reports from email should either work, or are possible to
> >> implement/fix in a reasonable time frame.
> > 
> > We could produce a detailed list of capabilities that must not regress
> > wrt debbugs, if that would be useful.  The number of those
> > capabilities is small.
> 
> That can help.

Here's a list of features that I think we want to preserve:

  . submit a bug report via email
  . receive bug reports and related discussions via email
  . give instructions to the tracker via email:
    - close/reopen/merge issues
    - add/remove tags from issues
    - mark a closed bug with the Emacs version where it is fixed
  . continue discussion of an issue even after it is closed

If I missed something important, Michael and Stefan, please add to
this list.

> > I think it would be unfortunate to ask users to create an account just
> > to report a bug and ask questions about it.  At least the email
> > gateway should be free of this complication (for casual submitters,
> > not for the developers and maintainers whom we could ask to register).
> 
> Like I said, it's feasible to set up an email gateway that is one-way. 
> But juggling responses back to unregistered users and forwarding their 
> emails again seems (for those discussions to be continued) like a 
> full-blown mailing list software. Maybe something like that already 
> exists or could be written without too many complications. I cannot 
> guarantee that in advance, however. From what I see, none of the "big 
> and popular" solutions have that kind of feature, even Bugzilla's 
> "Inbound email gateway".

I think this is imperative.  An alternative would be to have Emacs
commands to let users continue discussions of an issue via some other
medium, but frankly, nothing beats email in its easiness,
pervasiveness, and the abundance of different MUAs.  There must be a
possibility to get the users involved in the discussion of bugs they
submitted, because frequently we need more info to investigate and
decide on solutions.

So if this is not trivial, perhaps we should bring someone on board to
add such facilities for us, as our special add-on to a good bug
tracker which doesn't have that OOTB.  Like savannah-hackers or people
who manage the GNU mailing lists, for example.

> Though at their scale it's likely to result in too much spam anyway.

GNU mailing lists have a very efficient system for blocking spam.

> >> FWIW, PRs/MRs can be initially disabled, if most of the heavy
> >> contributors prefer to stay on the email-driven workflow.
> > 
> > I thought that was the single most important deficiency of debbugs?
> 
> It's a feature that could make it more pleasant/familiar for certain 
> developers to contribute code, and lead the discussions around such new 
> code (aka code review). But I wouldn't blame a bug tracker for not being 
> a code review tool. Bugzilla isn't one either: it seems that projects 
> using it used something like Gerrit for code review in the past (I have 
> no experience with it).

Bugzilla _can_ be used for patch review, albeit maybe not conveniently
enough.  And I don't think I'd like a bug tracker that doesn't allow
to review code as part of the discussion -- where else will we then do
the latter?  Maybe I just don't understand what you mean by that, but
if you do mean patch review, then how can a good bug tracker possibly
lack that??

> > If they aren't, then which capabilities _are_ important to have that
> > we don't have on debbugs?
> 
> Just the common bug tracker stuff, mostly related to Web UI (allowing 
> one to easily read and join a discussion, subscribe to it, unsubscribe, 
> syntax-highlighted code snippets, linking of issues between themselves, 
> links between issues and commits, closing issues from commits, assigning 
> issues to specific developers, ...). Also better working search and a 
> very visible page "latest active issues/discussions".

If those are the main points, perhaps we should also explore the
possibility of adding them to debbugs?

> I expect a more "modern" bug tracker to result in higher volume of bug 
> reports (good and bad ones, as discussed previously), reports from more 
> different kinds of users, possibly resulting in faster bug reports too. 
> This is just a hypothesis (that a younger user has lower patience on 
> average), but it seems logical to me.

We want to test this theory, but we don't want to give up too many
useful features of the current workflow, at least from the
maintainer's POV.  The challenge is to find a way of satisfying both
kinds of needs and requirements with "minimum blood".

Re: Choice of bug tracker

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Here's a list of features that I think we want to preserve:
>
>   . submit a bug report via email
>   . receive bug reports and related discussions via email
>   . give instructions to the tracker via email:
>     - close/reopen/merge issues
>     - add/remove tags from issues
>     - mark a closed bug with the Emacs version where it is fixed
>   . continue discussion of an issue even after it is closed
>
> If I missed something important, Michael and Stefan, please add to
> this list.

Sounds OK.

>> Though at their scale it's likely to result in too much spam anyway.
>
> GNU mailing lists have a very efficient system for blocking spam.

Whatever system is taken, you'll need ML moderators. Volunteers,
committed for years.

>> > If they aren't, then which capabilities _are_ important to have that
>> > we don't have on debbugs?
>>
>> Just the common bug tracker stuff, mostly related to Web UI (allowing
>> one to easily read and join a discussion, subscribe to it, unsubscribe,
>> syntax-highlighted code snippets, linking of issues between themselves,
>> links between issues and commits, closing issues from commits, assigning
>> issues to specific developers, ...). Also better working search and a
>> very visible page "latest active issues/discussions".
>
> If those are the main points, perhaps we should also explore the
> possibility of adding them to debbugs?

The Guix people have written their own Web UI on top of debbugs.gnu.org,
<https://issues.guix.gnu.org/>. Perhaps you can ask for their view.

Best regards, Michael.

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 17:09, Michael Albinus wrote:
>>>> If they aren't, then which capabilities_are_  important to have that
>>>> we don't have on debbugs?
>>> Just the common bug tracker stuff, mostly related to Web UI (allowing
>>> one to easily read and join a discussion, subscribe to it, unsubscribe,
>>> syntax-highlighted code snippets, linking of issues between themselves,
>>> links between issues and commits, closing issues from commits, assigning
>>> issues to specific developers, ...). Also better working search and a
>>> very visible page "latest active issues/discussions".
>> If those are the main points, perhaps we should also explore the
>> possibility of adding them to debbugs?
> The Guix people have written their own Web UI on top of debbugs.gnu.org,
> <https://issues.guix.gnu.org/>. Perhaps you can ask for their view.

Thank you for the reminder. It's a definite improvement over Debbugs's 
website. And I think it's a little better since I last saw it, too.

Rather interesting on its own, it's a Scheme (Guile) application working 
on top of the Debbugs database schema (which is apparently just one 
table, huh).

It's not a very ambitious project (at least judging by the readme: 
https://git.elephly.net/software/mumi/tree/-//README.org), so it seems 
we're not very likely to see it grow into something bigger. There is no 
interaction with the discussions from the browser that I could test 
(apparently, there is some commenting feature, but it's disabled on 
Guix's installation).

Either way, it checks off a few items from my list (the "Recent 
activity" being IMHO the most important, but also better search), so if 
we could have it in use right now just by snapping a finger, I'd 
probably vote yes. A definite winner in the category of keeping 
everybody's workflows as-is while still improving some things.

Re: Choice of bug tracker

[Yuan Fu]

> On Aug 31, 2023, at 4:21 PM, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
> On 31/08/2023 17:09, Michael Albinus wrote:
>>>>> If they aren't, then which capabilities_are_  important to have that
>>>>> we don't have on debbugs?
>>>> Just the common bug tracker stuff, mostly related to Web UI (allowing
>>>> one to easily read and join a discussion, subscribe to it, unsubscribe,
>>>> syntax-highlighted code snippets, linking of issues between themselves,
>>>> links between issues and commits, closing issues from commits, assigning
>>>> issues to specific developers, ...). Also better working search and a
>>>> very visible page "latest active issues/discussions".
>>> If those are the main points, perhaps we should also explore the
>>> possibility of adding them to debbugs?
>> The Guix people have written their own Web UI on top of debbugs.gnu.org,
>> <https://issues.guix.gnu.org/>. Perhaps you can ask for their view.
> 
> Thank you for the reminder. It's a definite improvement over Debbugs's website. And I think it's a little better since I last saw it, too.
> 
> Rather interesting on its own, it's a Scheme (Guile) application working on top of the Debbugs database schema (which is apparently just one table, huh).
> 
> It's not a very ambitious project (at least judging by the readme: https://git.elephly.net/software/mumi/tree/-//README.org), so it seems we're not very likely to see it grow into something bigger. There is no interaction with the discussions from the browser that I could test (apparently, there is some commenting feature, but it's disabled on Guix's installation).
> 
> Either way, it checks off a few items from my list (the "Recent activity" being IMHO the most important, but also better search), so if we could have it in use right now just by snapping a finger, I'd probably vote yes. A definite winner in the category of keeping everybody's workflows as-is while still improving some things.


In that vein, woof [1] of Org Mode is also a nice project that communicates recent development activities.

[1] https://tracker.orgmode.org/

Yuan

Re: Choice of bug tracker

[Dmitry Gutov]

On 01/09/2023 07:20, Yuan Fu wrote:
> In that vein, woof [1] of Org Mode is also a nice project that communicates recent development activities.
> 
> [1]https://tracker.orgmode.org/

That one's not too bad either, as far as lightweight incremental 
improvements go.

The web page design looks a little better than mumi (which is to be 
expected of the Org crowd), but it seems leaner on the functionality 
(e.g. search).

I'm also not sure whether it works with Debbugs' database or just 
indexes the mailing lists.

Re: Choice of bug tracker

[Ihor Radchenko]

Dmitry Gutov <dmitry@gutov.dev> writes:

> The web page design looks a little better than mumi (which is to be 
> expected of the Org crowd), but it seems leaner on the functionality 
> (e.g. search).

May you elaborate about the missing search functionality?
CCing Bastien, the author of Woof!

> I'm also not sure whether it works with Debbugs' database or just 
> indexes the mailing lists.

Woof! is specifically designed to index mailing lists.
Actually, it is a kind of lightweight re-implementation of debbugs -
similar control messages can be used to control the bug status. See
https://tracker.orgmode.org/howto

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Dmitry Gutov]

On 01/09/2023 12:47, Ihor Radchenko wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> The web page design looks a little better than mumi (which is to be
>> expected of the Org crowd), but it seems leaner on the functionality
>> (e.g. search).
> May you elaborate about the missing search functionality?
> CCing Bastien, the author of Woof!

Click the "Hint" button below the search bar here: 
https://issues.guix.gnu.org/

It describes a certain search syntax. Woof could use a similar help 
button, at least. And if it had, we could compare the capabilities.

>> I'm also not sure whether it works with Debbugs' database or just
>> indexes the mailing lists.
> Woof! is specifically designed to index mailing lists.
> Actually, it is a kind of lightweight re-implementation of debbugs -
> similar control messages can be used to control the bug status. See
> https://tracker.orgmode.org/howto

Interesting.

RE: [External] : Re: Choice of bug tracker

[Drew Adams]

> . receive bug reports and related discussions via email

How about this minor change (which I'm
guessing you meant implicitly)?

. receive and contribute to bug reports
  and related discussions using email

IOW, create, receive, and _update_ bug
reports and related discussions.

Re: [External] : Re: Choice of bug tracker

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "philipk@posteo.net" <philipk@posteo.net>,
>         "stefankangas@gmail.com"
> 	<stefankangas@gmail.com>,
>         "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Thu, 31 Aug 2023 14:54:33 +0000
> 
> > . receive bug reports and related discussions via email
> 
> How about this minor change (which I'm
> guessing you meant implicitly)?
> 
> . receive and contribute to bug reports
>   and related discussions using email
> 
> IOW, create, receive, and _update_ bug
> reports and related discussions.

I don't see what's missing from the list (which really requires an
amendment).  It's all there, including what you want to dd.

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 10:18, Eli Zaretskii wrote:
>> Date: Wed, 30 Aug 2023 23:29:11 +0300
>> Cc: philipk@posteo.net, danny@dfreeman.email, stefankangas@gmail.com,
>>   emacs-devel@gnu.org, manuel.uberti@inventati.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>>
>>>>>      . we must have support for features we have now on debbugs
>>>>
>>>> As a very reluctant user of Debbugs, I have say this is not a clear
>>>> description for me. But as mentioned previously, the main features like
>>>> modifying bug reports from email should either work, or are possible to
>>>> implement/fix in a reasonable time frame.
>>>
>>> We could produce a detailed list of capabilities that must not regress
>>> wrt debbugs, if that would be useful.  The number of those
>>> capabilities is small.
>>
>> That can help.
> 
> Here's a list of features that I think we want to preserve:
> 
>    . submit a bug report via email
>    . receive bug reports and related discussions via email
>    . give instructions to the tracker via email:
>      - close/reopen/merge issues
>      - add/remove tags from issues
>      - mark a closed bug with the Emacs version where it is fixed
>    . continue discussion of an issue even after it is closed
> 
> If I missed something important, Michael and Stefan, please add to
> this list.

Sounds good. Modification of issues via email is definitely supported to 
an extent, and some features could be added if missing.

>>> I think it would be unfortunate to ask users to create an account just
>>> to report a bug and ask questions about it.  At least the email
>>> gateway should be free of this complication (for casual submitters,
>>> not for the developers and maintainers whom we could ask to register).
>>
>> Like I said, it's feasible to set up an email gateway that is one-way.
>> But juggling responses back to unregistered users and forwarding their
>> emails again seems (for those discussions to be continued) like a
>> full-blown mailing list software. Maybe something like that already
>> exists or could be written without too many complications. I cannot
>> guarantee that in advance, however. From what I see, none of the "big
>> and popular" solutions have that kind of feature, even Bugzilla's
>> "Inbound email gateway".
> 
> I think this is imperative.  An alternative would be to have Emacs
> commands to let users continue discussions of an issue via some other
> medium, but frankly, nothing beats email in its easiness,
> pervasiveness, and the abundance of different MUAs.  There must be a
> possibility to get the users involved in the discussion of bugs they
> submitted, because frequently we need more info to investigate and
> decide on solutions.

As a very low-tech fallback, we would still have emacs-devel, or a 
separate mailing list where we could forward bug emails from users who 
don't want to register an account.

> So if this is not trivial, perhaps we should bring someone on board to
> add such facilities for us, as our special add-on to a good bug
> tracker which doesn't have that OOTB.  Like savannah-hackers or people
> who manage the GNU mailing lists, for example.

I've never worked on any email-related software, and this does sound 
like a job for a mailing list program.

It could be useful to bring in someone with that expertise, even if they 
only share some ideas about all that.

>>>> FWIW, PRs/MRs can be initially disabled, if most of the heavy
>>>> contributors prefer to stay on the email-driven workflow.
>>>
>>> I thought that was the single most important deficiency of debbugs?
>>
>> It's a feature that could make it more pleasant/familiar for certain
>> developers to contribute code, and lead the discussions around such new
>> code (aka code review). But I wouldn't blame a bug tracker for not being
>> a code review tool. Bugzilla isn't one either: it seems that projects
>> using it used something like Gerrit for code review in the past (I have
>> no experience with it).
> 
> Bugzilla _can_ be used for patch review, albeit maybe not conveniently
> enough.  And I don't think I'd like a bug tracker that doesn't allow
> to review code as part of the discussion -- where else will we then do
> the latter?  Maybe I just don't understand what you mean by that, but
> if you do mean patch review, then how can a good bug tracker possibly
> lack that??

I meant tool-assisted code review. As an industry term for a (usually 
web-based) solution that allows attaching comments to parts of diffs 
(with an inline view), continuing those discussions, marking comments as 
"solved", automatic marking of them as "stale" on pushes, and so on. 
View a separate list of all commits on a branch, commit since last 
viewer, a combined diff of all commits, and etc. One characteristic of 
such interfaces is a button called "Merge pull request". Though there 
are more complex tools, e.g. IIUC Differential (another tool) works with 
more bureaucracy than that.

Of course we can read patches an comment on them without any such tools. 
Both Debbugs and Bugzilla aren't going to prevent that.

>>> If they aren't, then which capabilities _are_ important to have that
>>> we don't have on debbugs?
>>
>> Just the common bug tracker stuff, mostly related to Web UI (allowing
>> one to easily read and join a discussion, subscribe to it, unsubscribe,
>> syntax-highlighted code snippets, linking of issues between themselves,
>> links between issues and commits, closing issues from commits, assigning
>> issues to specific developers, ...). Also better working search and a
>> very visible page "latest active issues/discussions".
> 
> If those are the main points, perhaps we should also explore the
> possibility of adding them to debbugs?

We've known and discussed many of them over the course of a number of 
years. There is no active development for Debbugs that I know of, and 
adding all (or most, or any) of those features would really amount to 
writing a new issue tracker from scratch, which is not really our 
specialization. It doesn't sound like the best use of our time.

Even with "mumi" (Guix's Debbugs replacement that Michael has linked to) 
I hesitate to discuss any plans of extension because every new web-only 
or web-oriented, or "modern tracker"-oriented feature would not only be 
a significant job on its own, it would also be a political fight at the 
same time, one after another. And, well, I'm not a Scheme hacker anyway, 
although we know some.

By choosing any of the existing bug trackers we would adopt a set of 
existing well-understood tradeoffs wholesale, which everybody would have 
to adapt to over time. And then either adjust their workflows or build 
improvements/additional tools gradually on top of that fixed base.

>> I expect a more "modern" bug tracker to result in higher volume of bug
>> reports (good and bad ones, as discussed previously), reports from more
>> different kinds of users, possibly resulting in faster bug reports too.
>> This is just a hypothesis (that a younger user has lower patience on
>> average), but it seems logical to me.
> 
> We want to test this theory, but we don't want to give up too many
> useful features of the current workflow, at least from the
> maintainer's POV.  The challenge is to find a way of satisfying both
> kinds of needs and requirements with "minimum blood".

The "minimum blood" would be mumi because from what it seems like it 
retains all the email interactions and adds some moderately better looks 
when viewed on the web on top of that. As well as faster search.

But since it has the least "familiarity" factor among all of the 
discussed solutions (and features, of course, and usability testing, and 
etc...), the ability to attract more and more diverse users and 
developers though modern tooling would correspondingly be lower.

There is a sweet spot somewhere, but I don't have any scientific 
argument for its position. Though if I try to imagine myself 10-15 years 
younger (rather difficult), the grading would most likely be Github > 
Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of course.

There should also be SourceHut on this scale, but I don't know where to 
put it.

Re: Choice of bug tracker

[Visuwesh]

[வெள்ளி செப்டம்பர் 01, 2023] Dmitry Gutov wrote:

> [...]
> The "minimum blood" would be mumi because from what it seems like it
> retains all the email interactions and adds some moderately better
> looks when viewed on the web on top of that. As well as faster search.
>
> But since it has the least "familiarity" factor among all of the
> discussed solutions (and features, of course, and usability testing,
> and etc...), the ability to attract more and more diverse users and
> developers though modern tooling would correspondingly be lower.
>
> There is a sweet spot somewhere, but I don't have any scientific
> argument for its position. Though if I try to imagine myself 10-15
> years younger (rather difficult), the grading would most likely be
> Github > Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of
> course.

You don't have to imagine yourself younger because I was eighteen or
nineteen when I first posted a bug report to debbugs.  ;-) Not sure if
this is your target audience though.
I did not have problems with sending the mail to the right address but
knowing whether my mail reached the mailing list/debbugs was an issue
since I could not see it pop up in the bug-gnu-emacs mailing list
archive.  Much later I learnt that there is a manual approval process
for fresh email addresses and that's why my acknowledgement mail was
sent some 10 hours later (I went to sleep after submitting said bug
report).  If there was a message along the lines of, “Your message has
been received and will be forwarded to the Emacs developers once your
email address has been manually approved to check whether your mail is
spam or not” I think the first experience would have been smoother.

As for submitting patches, I much much much much prefer the Emacs way™.
It is so much better than forking the repo, creating a new branch,
fighting with Git to merge/rebase and push properly without --force (I
still don't know how to do the latter FWIW). And don't get me started on
amendments after creating the PR...  For Emacs, I can develop the patch
however I want and simply attach it to a mail---I cannot emphasise how
much simpler and effortless this feels.  It is a good thing that Emacs
actually prefers patches as assignment over `git send-email'---nothing
is more of a pain than setting up an email client especially in a
CLI/TUI setting.  When you have only used the GMail/Yahoo web client for
email, all the terminologies that the man page and the tutorials throw
at you simply flies over your head and you give up.  Now, the most
common mail provider Gmail has made it a huge PITA to use a custom email
client as well...

So let me reiterate: I find it so comforting that Emacs accepts patches
(1) via email, and (2) as attachments.

> There should also be SourceHut on this scale, but I don't know where
> to put it.

Cannot comment on how everyone else uses Sourcehut but my experience was
slightly better than Debbugs because I got instant feedback from the
mailing list archive and Philip accepts patches as attachments.  ;-)
Generally, I don't find their web UI all that useful since they drop the
entire message after the attachment.  I am not sure if there are plans
to fix it since Sourcehut people prefer `git send-email' AFAIK.

Re: Choice of bug tracker

[Manuel Giraud via Emacs development discussions.]

Visuwesh <visuweshm@gmail.com> writes:

> [வெள்ளி செப்டம்பர் 01, 2023] Dmitry Gutov wrote:

[...]

> As for submitting patches, I much much much much prefer the Emacs way™.
> It is so much better than forking the repo, creating a new branch,
> fighting with Git to merge/rebase and push properly without --force (I
> still don't know how to do the latter FWIW). And don't get me started on
> amendments after creating the PR...  For Emacs, I can develop the patch
> however I want and simply attach it to a mail---I cannot emphasise how
> much simpler and effortless this feels.  It is a good thing that Emacs
> actually prefers patches as assignment over `git send-email'---nothing
> is more of a pain than setting up an email client especially in a
> CLI/TUI setting.  When you have only used the GMail/Yahoo web client for
> email, all the terminologies that the man page and the tutorials throw
> at you simply flies over your head and you give up.  Now, the most
> common mail provider Gmail has made it a huge PITA to use a custom email
> client as well...

Amen to that!  Once everything is in place™ (good MUA, git
integration…), this workflow feels easier to me too.
-- 
Manuel Giraud

Re: Choice of bug tracker

[Dmitry Gutov]

Hi!

On 01/09/2023 10:15, Visuwesh wrote:
> [வெள்ளி செப்டம்பர் 01, 2023] Dmitry Gutov wrote:
> 
>> [...]
>> The "minimum blood" would be mumi because from what it seems like it
>> retains all the email interactions and adds some moderately better
>> looks when viewed on the web on top of that. As well as faster search.
>>
>> But since it has the least "familiarity" factor among all of the
>> discussed solutions (and features, of course, and usability testing,
>> and etc...), the ability to attract more and more diverse users and
>> developers though modern tooling would correspondingly be lower.
>>
>> There is a sweet spot somewhere, but I don't have any scientific
>> argument for its position. Though if I try to imagine myself 10-15
>> years younger (rather difficult), the grading would most likely be
>> Github > Gitlab >> Bugzilla > mumi >> Debbugs. Add a pound of salt, of
>> course.
> 
> You don't have to imagine yourself younger because I was eighteen or
> nineteen when I first posted a bug report to debbugs.  ;-) Not sure if
> this is your target audience though.

You are part of my target audience, of course. Hopefully.

> I did not have problems with sending the mail to the right address but
> knowing whether my mail reached the mailing list/debbugs was an issue
> since I could not see it pop up in the bug-gnu-emacs mailing list
> archive.  Much later I learnt that there is a manual approval process
> for fresh email addresses and that's why my acknowledgement mail was
> sent some 10 hours later (I went to sleep after submitting said bug
> report).  If there was a message along the lines of, “Your message has
> been received and will be forwarded to the Emacs developers once your
> email address has been manually approved to check whether your mail is
> spam or not” I think the first experience would have been smoother.
> 
> As for submitting patches, I much much much much prefer the Emacs way™.
> It is so much better than forking the repo, creating a new branch,
> fighting with Git to merge/rebase and push properly without --force (I
> still don't know how to do the latter FWIW). And don't get me started on
> amendments after creating the PR...  For Emacs, I can develop the patch
> however I want and simply attach it to a mail---I cannot emphasise how
> much simpler and effortless this feels.  It is a good thing that Emacs
> actually prefers patches as assignment over `git send-email'---nothing
> is more of a pain than setting up an email client especially in a
> CLI/TUI setting.  When you have only used the GMail/Yahoo web client for
> email, all the terminologies that the man page and the tutorials throw
> at you simply flies over your head and you give up.  Now, the most
> common mail provider Gmail has made it a huge PITA to use a custom email
> client as well...
> 
> So let me reiterate: I find it so comforting that Emacs accepts patches
> (1) via email, and (2) as attachments.

I'm glad that you like it here, and we should say that the ability to 
submit patch via an attachment shouldn't ever go away. I even post 
patches on Github inline (via markdown blocks) sometimes, puzzling 
occasional passers-by. So the number of options how to submit and 
discuss a patch shouldn't go down in any case, only up.

Note, however, that knowing how to work with Git and understanding its 
repository model (and knowing to to do merges/rebases/etc) is going to 
be very useful for your career, at least if you're a programmer or a 
data scientist.

>> There should also be SourceHut on this scale, but I don't know where
>> to put it.
> 
> Cannot comment on how everyone else uses Sourcehut but my experience was
> slightly better than Debbugs because I got instant feedback from the
> mailing list archive and Philip accepts patches as attachments.  ;-)
> Generally, I don't find their web UI all that useful since they drop the
> entire message after the attachment.  I am not sure if there are plans
> to fix it since Sourcehut people prefer `git send-email' AFAIK.

Yes, they do have a weak spot in the web UI department. But basically 
anything is better than Debbugs, IMO ;-(

Re: Choice of bug tracker

[Visuwesh]

[வெள்ளி செப்டம்பர் 01, 2023] Dmitry Gutov wrote:

>> I did not have problems with sending the mail to the right address but
>> knowing whether my mail reached the mailing list/debbugs was an issue
>> since I could not see it pop up in the bug-gnu-emacs mailing list
>> archive.  Much later I learnt that there is a manual approval process
>> for fresh email addresses and that's why my acknowledgement mail was
>> sent some 10 hours later (I went to sleep after submitting said bug
>> report).  If there was a message along the lines of, “Your message has
>> been received and will be forwarded to the Emacs developers once your
>> email address has been manually approved to check whether your mail is
>> spam or not” I think the first experience would have been smoother.
>> As for submitting patches, I much much much much prefer the Emacs
>> way™.
>> It is so much better than forking the repo, creating a new branch,
>> fighting with Git to merge/rebase and push properly without --force (I
>> still don't know how to do the latter FWIW). And don't get me started on
>> amendments after creating the PR...  For Emacs, I can develop the patch
>> however I want and simply attach it to a mail---I cannot emphasise how
>> much simpler and effortless this feels.  It is a good thing that Emacs
>> actually prefers patches as assignment over `git send-email'---nothing
>> is more of a pain than setting up an email client especially in a
>> CLI/TUI setting.  When you have only used the GMail/Yahoo web client for
>> email, all the terminologies that the man page and the tutorials throw
>> at you simply flies over your head and you give up.  Now, the most
>> common mail provider Gmail has made it a huge PITA to use a custom email
>> client as well...
>> So let me reiterate: I find it so comforting that Emacs accepts
>> patches
>> (1) via email, and (2) as attachments.
>
> I'm glad that you like it here, and we should say that the ability to
> submit patch via an attachment shouldn't ever go away. I even post
> patches on Github inline (via markdown blocks) sometimes, puzzling
> occasional passers-by. So the number of options how to submit and
> discuss a patch shouldn't go down in any case, only up.
>
> Note, however, that knowing how to work with Git and understanding its
> repository model (and knowing to to do merges/rebases/etc) is going to
> be very useful for your career, at least if you're a programmer or a
> data scientist.

I can merge and rebase fine now but I can never get `git push' to work
to my fork repo.  Whenever I lookup how to `git push' without --force, I
could never use the answers given in the internet.

>>> There should also be SourceHut on this scale, but I don't know where
>>> to put it.
>> Cannot comment on how everyone else uses Sourcehut but my experience
>> was
>> slightly better than Debbugs because I got instant feedback from the
>> mailing list archive and Philip accepts patches as attachments.  ;-)
>> Generally, I don't find their web UI all that useful since they drop the
>> entire message after the attachment.  I am not sure if there are plans
>> to fix it since Sourcehut people prefer `git send-email' AFAIK.
>
> Yes, they do have a weak spot in the web UI department. But basically
> anything is better than Debbugs, IMO ;-(

At least for search, yhetil.org is much better (read: actually working).

Re: Choice of bug tracker

[Ihor Radchenko]

Visuwesh <visuweshm@gmail.com> writes:

> I did not have problems with sending the mail to the right address but
> knowing whether my mail reached the mailing list/debbugs was an issue
> since I could not see it pop up in the bug-gnu-emacs mailing list
> archive.  Much later I learnt that there is a manual approval process
> for fresh email addresses and that's why my acknowledgement mail was
> sent some 10 hours later (I went to sleep after submitting said bug
> report).  If there was a message along the lines of, “Your message has
> been received and will be forwarded to the Emacs developers once your
> email address has been manually approved to check whether your mail is
> spam or not” I think the first experience would have been smoother.

Agree. Isn't is possible to create an automatic bouncer for
non-subscribed non-whitelisted users to notify them about moderation?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Michael Albinus]

Ihor Radchenko <yantar92@posteo.net> writes:

Hi,

>> I did not have problems with sending the mail to the right address but
>> knowing whether my mail reached the mailing list/debbugs was an issue
>> since I could not see it pop up in the bug-gnu-emacs mailing list
>> archive.  Much later I learnt that there is a manual approval process
>> for fresh email addresses and that's why my acknowledgement mail was
>> sent some 10 hours later (I went to sleep after submitting said bug
>> report).  If there was a message along the lines of, “Your message has
>> been received and will be forwarded to the Emacs developers once your
>> email address has been manually approved to check whether your mail is
>> spam or not” I think the first experience would have been smoother.
>
> Agree. Isn't is possible to create an automatic bouncer for
> non-subscribed non-whitelisted users to notify them about moderation?

That's not done because it would give the spammers the feedback that the
used mail address is valid. With the likelihood to get more spam.

Best regards, Michael.

Re: Choice of bug tracker

[Ihor Radchenko]

Michael Albinus <michael.albinus@gmx.de> writes:

>> Agree. Isn't is possible to create an automatic bouncer for
>> non-subscribed non-whitelisted users to notify them about moderation?
>
> That's not done because it would give the spammers the feedback that the
> used mail address is valid. With the likelihood to get more spam.

Is it something that was tried and then had to be removed?

I do agree that the amount of spam will likely increase, but I am not
sure if it will be unbearable. So, insight from moderators would be
useful.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Michael Albinus]

Ihor Radchenko <yantar92@posteo.net> writes:

Hi Ihor,

>>> Agree. Isn't is possible to create an automatic bouncer for
>>> non-subscribed non-whitelisted users to notify them about moderation?
>>
>> That's not done because it would give the spammers the feedback that the
>> used mail address is valid. With the likelihood to get more spam.
>
> Is it something that was tried and then had to be removed?

Don't know, I'm not a debbugs moderator from the beginning.

> I do agree that the amount of spam will likely increase, but I am not
> sure if it will be unbearable. So, insight from moderators would be
> useful.

Given, that I'm almost the only moderator these days, I wouldn't like to
check out. Remember, it isn't only Emacs bugs which go through.

If there would be more debbugs ML moderators, it might be worth to
try. My occasional requests to volunteer die away unheard. No surprise,
given the bad reputation people rank debbugs here.

Best regards, Michael.

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: Visuwesh <visuweshm@gmail.com>,  Dmitry Gutov <dmitry@gutov.dev>,  Eli
>  Zaretskii <eliz@gnu.org>,  Stefan Kangas <stefankangas@gmail.com>,
>   philipk@posteo.net,  emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 15:41:38 +0200
> 
> Ihor Radchenko <yantar92@posteo.net> writes:
> 
> Hi Ihor,
> 
> >>> Agree. Isn't is possible to create an automatic bouncer for
> >>> non-subscribed non-whitelisted users to notify them about moderation?
> >>
> >> That's not done because it would give the spammers the feedback that the
> >> used mail address is valid. With the likelihood to get more spam.
> >
> > Is it something that was tried and then had to be removed?
> 
> Don't know, I'm not a debbugs moderator from the beginning.

I can tell that bug-gnu-emacs was once full of spam, so much so that
it was useless for actually working on Emacs.  You can see it in the
archives.

Re: Choice of bug tracker

[Corwin Brust]

On Fri, Sep 1, 2023 at 8:41 AM Michael Albinus <michael.albinus@gmx.de> wrote:
> >>> Agree. Isn't is possible to create an automatic bouncer for
> >>> non-subscribed non-whitelisted users to notify them about moderation?
> >>
> >> That's not done because it would give the spammers the feedback that the
> >> used mail address is valid. With the likelihood to get more spam.
> >
> > Is it something that was tried and then had to be removed?
>
> Don't know, I'm not a debbugs moderator from the beginning.
>
> > I do agree that the amount of spam will likely increase, but I am not
> > sure if it will be unbearable. So, insight from moderators would be
> > useful.
>
> Given, that I'm almost the only moderator these days, I wouldn't like to
> check out. Remember, it isn't only Emacs bugs which go through.
>
> If there would be more debbugs ML moderators, it might be worth to
> try. My occasional requests to volunteer die away unheard.

I hear you.  I will help with this, if you like.  Is there a guide for
ml moderation?  I saw a page on EmacsWiki[1] but it is mostly a list
of lists.  In any event, you are welcome to contact me off list by
email or via carlc@svh.  I am volunteering mostly for async types of
tasks like this right now because coding currently goes very slowly
for me, so I think you should take on others also given more people do
step forward. (And please feel free to disregard this if you already
got enough help, etc.. :)

Warm regards,
Corwin

[1] https://www.emacswiki.org/emacs/EmacsMailingLists

Re: Choice of bug tracker

[Michael Albinus]

Corwin Brust <corwin@bru.st> writes:

Hi Corwin,

> I hear you.  I will help with this, if you like.  Is there a guide for
> ml moderation?  I saw a page on EmacsWiki[1] but it is mostly a list
> of lists.  In any event, you are welcome to contact me off list by
> email or via carlc@svh.  I am volunteering mostly for async types of
> tasks like this right now because coding currently goes very slowly
> for me, so I think you should take on others also given more people do
> step forward. (And please feel free to disregard this if you already
> got enough help, etc.. :)

Many thanks for the offer, I much appreciate it! These days I haven't
too much time; I'll come back to you latest over the weekend with details.

> Warm regards,
> Corwin

Best regards, Michael.

Re: Choice of bug tracker

[Philip Kaludercic]

Visuwesh <visuweshm@gmail.com> writes:

> As for submitting patches, I much much much much prefer the Emacs way™.
> It is so much better than forking the repo, creating a new branch,
> fighting with Git to merge/rebase and push properly without --force (I
> still don't know how to do the latter FWIW). And don't get me started on
> amendments after creating the PR...

People appear to forget how unintuitive the PR approach actually is, and
prefer it mostly because they are used to the notion of doing what you
describe here.  But I (unsurprisingly) agree, I submitted a few patches
to Agda-mode earlier this year[0], but because they depend on one
another, the web UI is confused and displays all the commits.  Perhaps
just anecdotal, but at least an example of how these kinds of interfaces
restrict the Git workflow.

[0] https://github.com/agda/agda/pull/6123#issuecomment-1472151296
[1] https://github.com/agda/agda/pull/6540/commits

>> There should also be SourceHut on this scale, but I don't know where
>> to put it.
>
> Cannot comment on how everyone else uses Sourcehut but my experience was
> slightly better than Debbugs because I got instant feedback from the
> mailing list archive and Philip accepts patches as attachments.  ;-)
> Generally, I don't find their web UI all that useful since they drop the
> entire message after the attachment.  I am not sure if there are plans
> to fix it since Sourcehut people prefer `git send-email' AFAIK.

FWIW I spoke with the Sourcehut developers at FOSDEM this year and IIRC
they told me that while they aren't interested in upstreaming the
features that would be nice to have for Emacs development, they would be
happy to help with any issues if a fork were to be maintained.

Re: Choice of bug tracker

[Hugo Thunnissen]

Dmitry Gutov <dmitry@gutov.dev> writes:
>
> There is a sweet spot somewhere, but I don't have any scientific argument for
> its position. Though if I try to imagine myself 10-15 years younger (rather
> difficult), the grading would most likely be Github > Gitlab >> Bugzilla > mumi
>>> Debbugs. Add a pound of salt, of course.
>
> There should also be SourceHut on this scale, but I don't know where to put it.

From the perspective of a zoomer (born 1997), I'll fill that in for you:
Github > Gitlab > Sourcehut > Bugzilla > mumi. Not that this reflects my
personal preference, but looking at my peers it is clear that they
overwhelmingly prefer the "pull-request GUI" workflow. Looking at
bugzilla I don't see what it does differently from sourcehut's ticket
tracker, but sourcehut is more than just a ticket tracker so I rank it
higher.

PS: I'm a little surprised that sourcehut is not receiving more love
here. Looking at sourcehut it seems to be the only forge where email
based developmen is a first-class citizen. It's also the only forge that
is licensed under the GPL and whose developers politically align with
the FSF. It seems to me that a better fit for the emacs project doesn't
exist.

Re: Choice of bug tracker

[Ihor Radchenko]

Hugo Thunnissen <devel@hugot.nl> writes:

> PS: I'm a little surprised that sourcehut is not receiving more love
> here. Looking at sourcehut it seems to be the only forge where email
> based developmen is a first-class citizen. It's also the only forge that
> is licensed under the GPL and whose developers politically align with
> the FSF. It seems to me that a better fit for the emacs project doesn't
> exist.

Yes, but they are even more conservative about email-driven and
patch-driven workflows. For example, they are against html emails.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Choice of bug tracker

[Dmitry Gutov]

On 01/09/2023 10:59, Hugo Thunnissen wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> There is a sweet spot somewhere, but I don't have any scientific argument for
>> its position. Though if I try to imagine myself 10-15 years younger (rather
>> difficult), the grading would most likely be Github > Gitlab >> Bugzilla > mumi
>>>> Debbugs. Add a pound of salt, of course.
>> There should also be SourceHut on this scale, but I don't know where to put it.
>  From the perspective of a zoomer (born 1997), I'll fill that in for you:
> Github > Gitlab > Sourcehut > Bugzilla > mumi. Not that this reflects my
> personal preference, but looking at my peers it is clear that they
> overwhelmingly prefer the "pull-request GUI" workflow. Looking at
> bugzilla I don't see what it does differently from sourcehut's ticket
> tracker, but sourcehut is more than just a ticket tracker so I rank it
> higher.

Thank you.

> PS: I'm a little surprised that sourcehut is not receiving more love
> here. Looking at sourcehut it seems to be the only forge where email
> based developmen is a first-class citizen. It's also the only forge that
> is licensed under the GPL and whose developers politically align with
> the FSF. It seems to me that a better fit for the emacs project doesn't
> exist.

They do have an email-drived workflow, but a somewhat different one ;-D. 
And they're moderately rigid about it. So that turned out to be a hard 
sell too, at least the last time it was discussed and considered.

Re: Choice of bug tracker

[Richard Stallman]

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

  > As a very low-tech fallback, we would still have emacs-devel, or a 
  > separate mailing list where we could forward bug emails from users who 
  > don't want to register an account.

Email has to be a first-class option.  Making email a "fall-back" will
not get my approval.

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

Re: Choice of bug tracker

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Last time we produced this overblown list which mixed necessities with
> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152

Hmm, some of the ideas on there seem very ambitious, indeed.  I'd
propose forgetting about the wishlist type items and focusing hard on
what really matters.  The list Eli just posted seems like the best
starting point.

>   - ReCaptcha replacement (actually seems fixed now:
> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493)
>   - LibreJS (we already know the JS files have satisfactory licenses;
> there was a fair amount of discussion around the assets pipeline, but no
> resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196)

We can't rely on non-free software, so these would need to be fixed.
At least for the GNU/Emacs instance, but even better in the Gitlab
upstream.

> There were also a few functional things like inability to include diffs
> in Merge Request notifications which seems like a genuine omission, that
> seems easy to sell to gitlabbers, and I wouldn't mind looking into.

Sounds great!

> Regarding "workability", we have EMBA for people to try out. It's been
> there for several years. Unless Gitlab is crossed out from the list of
> contestants already.

AFAIU, we did not cross out Gitlab.  It is a candidate, provided that
we can fix any outstanding issues, and make it fit existing workflows
well enough.

> I suppose [Bugzilla] was not in the list of "forges" because it only provides
> bug tracking. If we don't manage to switch to Gitlab or SourceHut, we
> can try using Bugzilla, at least. I'm not loving its "new bug" and the
> nonexistent "most recent issues/activity" pages, but it would still be
> an improvement.

Something like Gitlab or Sourcehut would be more capable, yes.  I also
believe they are closer to what we need if we are looking to make it
easier to recruit new developers.

The risk with spending time on Bugzilla is that we would end up using
that for the next 10+ years, when a bit (a lot?) more work could have
moved us to something like Sourcehut or Gitlab instead.  So
personally, I'd rather see that we focused on more featureful options.
But that's me.

> 2) Other bug trackers/forges which have any kind of web API can be
> adapted in a similar fashion: running a script when an email is received
> is easier than implementing a new feature in Gitlab, with
> UI/settings/permissions, so if we find that Gitlab is otherwise okay but
> its capability to modify issues over email is lacking, I can volunteer
> to look into this too.

That sounds workable.

Re: Choice of bug tracker

[João Távora]

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

On Tue, Aug 29, 2023, 16:10 Stefan Kangas <stefankangas@gmail.com> wrote:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
> > Last time we produced this overblown list which mixed necessities with
> > nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
>
> Hmm, some of the ideas on there seem very ambitious, indeed.  I'd
> propose forgetting about the wishlist type items and focusing hard on
> what really matters.  The list Eli just posted seems like the best
> starting point.
>

+1

>

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

Re: Choice of bug tracker

[Dmitry Gutov]

On 29/08/2023 18:06, Stefan Kangas wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Last time we produced this overblown list which mixed necessities with
>> nice-to-haves: https://gitlab.com/gitlab-org/gitlab/-/issues/28152
> 
> Hmm, some of the ideas on there seem very ambitious, indeed.  I'd
> propose forgetting about the wishlist type items and focusing hard on
> what really matters.  The list Eli just posted seems like the best
> starting point.

Very good.

>>    - ReCaptcha replacement (actually seems fixed now:
>> https://gitlab.com/gitlab-org/gitlab-foss/-/issues/46548#note_203922493)
>>    - LibreJS (we already know the JS files have satisfactory licenses;
>> there was a fair amount of discussion around the assets pipeline, but no
>> resolution: https://gitlab.com/gitlab-org/gitlab/-/issues/15196)
> 
> We can't rely on non-free software, so these would need to be fixed.
> At least for the GNU/Emacs instance, but even better in the Gitlab
> upstream.

The fact that LibreJS complains doesn't mean that the software is 
non-free. It just means that the annotations that LibreJS would 
recognize are missing. Most of the Internet is missing those. The 
overall mission of having JS files come with licenses in some form or 
other doesn't sound bad, but it shouldn't be a hard requirement for our 
platform, I think. It's not an urgent thing to fix.

(OTOH, for the main endeavor of finding the new common Forge software 
for all GNU projects it does seem pretty valuable, if only for political 
reasons.)

>> Regarding "workability", we have EMBA for people to try out. It's been
>> there for several years. Unless Gitlab is crossed out from the list of
>> contestants already.
> 
> AFAIU, we did not cross out Gitlab.  It is a candidate, provided that
> we can fix any outstanding issues, and make it fit existing workflows
> well enough.

Very good.

We have an existing Gitlab instance which should work at the testing 
ground. It's probably better to ask the admins to upgrade it to the 
latest version first, or if it was not their job, get in touch the 
people previously responsible for it.

And then we should ask some more folks to start working with it and come 
back with *prioritized* list of current problems.

>> I suppose [Bugzilla] was not in the list of "forges" because it only provides
>> bug tracking. If we don't manage to switch to Gitlab or SourceHut, we
>> can try using Bugzilla, at least. I'm not loving its "new bug" and the
>> nonexistent "most recent issues/activity" pages, but it would still be
>> an improvement.
> 
> Something like Gitlab or Sourcehut would be more capable, yes.  I also
> believe they are closer to what we need if we are looking to make it
> easier to recruit new developers.

Probably, yes. Though I'm less sure about that regarding Sourcehut, 
personally. It's new and fairly novel, but familiarity (for the general 
crowd) is not high on its list of priorities.

> The risk with spending time on Bugzilla is that we would end up using
> that for the next 10+ years, when a bit (a lot?) more work could have
> moved us to something like Sourcehut or Gitlab instead.  So
> personally, I'd rather see that we focused on more featureful options.
> But that's me.

Bugzilla is indeed the fallback option from my POV. But the other danger 
is that we spend the next 10+ years never agreeing on anything and not 
moving at all; Bugzilla is definitely better than *that* outcome.

Re: Choice of bug tracker

[Stefan Kangas]

Dmitry Gutov <dmitry@gutov.dev> writes:

> The fact that LibreJS complains doesn't mean that the software is
> non-free. It just means that the annotations that LibreJS would
> recognize are missing. Most of the Internet is missing those. The
> overall mission of having JS files come with licenses in some form or
> other doesn't sound bad, but it shouldn't be a hard requirement for our
> platform, I think. It's not an urgent thing to fix.

I'm afraid that this is non-optional according to GNU project policy:
https://www.gnu.org/prep/maintain/html_node/Freedom-for-Web-Pages.html

I'm looking at the LibreJS documentation here...
https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html

...and here's a naive question: Is it that hard to fix this, if we are
happy to just hack up a solution, even an "ugly" one?  (As opposed to
doing a clean job, hooking into the correct Gitlab asset pipelines and
what have you.)

Re: Choice of bug tracker

[Dmitry Gutov]

On 30/08/2023 21:03, Stefan Kangas wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> The fact that LibreJS complains doesn't mean that the software is
>> non-free. It just means that the annotations that LibreJS would
>> recognize are missing. Most of the Internet is missing those. The
>> overall mission of having JS files come with licenses in some form or
>> other doesn't sound bad, but it shouldn't be a hard requirement for our
>> platform, I think. It's not an urgent thing to fix.
> 
> I'm afraid that this is non-optional according to GNU project policy:
> https://www.gnu.org/prep/maintain/html_node/Freedom-for-Web-Pages.html

I guess I shouldn't be surprised.

> I'm looking at the LibreJS documentation here...
> https://www.gnu.org/software/librejs/manual/html_node/Setting-Your-JavaScript-Free.html
> 
> ...and here's a naive question: Is it that hard to fix this, if we are
> happy to just hack up a solution, even an "ugly" one?  (As opposed to
> doing a clean job, hooking into the correct Gitlab asset pipelines and
> what have you.)

Here's the latest on the issue: 
https://gitlab.com/gitlab-org/gitlab/-/issues/15196#note_327436569

But if we wanted to circumvent the upstream, I suppose someone could 
write a script which would go around every .js file in /assets/webpack 
and made sure the appropriate comment is added there. That would have to 
be run every time we upgrade refresh/reinstall Gitlab, I suppose. We'd 
also have to watch out for any changes in assets pipeline (maybe the dir 
changes, maybe an extra dir appears).

If LibreJS allowed a way to say "we've checked our dependencies and all 
of them are fine", maybe listing them all in a tag once, that would be 
easier. But more ambiguous in the legal sense.

Re: Choice of bug tracker

[Richard Stallman]

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

  > But if we wanted to circumvent the upstream, I suppose someone could 
  > write a script which would go around every .js file in /assets/webpack 
  > and made sure the appropriate comment is added there.

That is not feasible.

1. Understanding the licensing of a file of code, with license notices
meant for humans to understand, and figuring out the proper equivalemt
machie-understandable notices meant to be read by LibreJS, requires
human intelligence.  A "script" can't do it.

That is why we needed a different representation for LibreJS to use:
so it would not require human intelligence.

2. If anything causes use of JavaScript code from other sites,
we won't be able to add any comments to them.

In addition, this presupposes that the page in question is on a site
where we could modify it.

That might be the case.  But we must not forget that requirement.

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

Re: Choice of bug tracker

[Dmitry Gutov]

On 02/09/2023 04:52, 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. ]]]
> 
>    > But if we wanted to circumvent the upstream, I suppose someone could
>    > write a script which would go around every .js file in /assets/webpack
>    > and made sure the appropriate comment is added there.
> 
> That is not feasible.
> 
> 1. Understanding the licensing of a file of code, with license notices
> meant for humans to understand, and figuring out the proper equivalemt
> machie-understandable notices meant to be read by LibreJS, requires
> human intelligence.  A "script" can't do it.
> 
> That is why we needed a different representation for LibreJS to use:
> so it would not require human intelligence.
> 
> 2. If anything causes use of JavaScript code from other sites,
> we won't be able to add any comments to them.
> 
> In addition, this presupposes that the page in question is on a site
> where we could modify it.
> 
> That might be the case.  But we must not forget that requirement.

We, again, were talking about self-hosted Gitlab. Where all of the above 
is more-or-less feasible, including monitoring its major releases for 
changes in licensing.

I'm not seeing any links to external JS files in the sources of 
https://emba.gnu.org.

Re: Choice of bug tracker

[Richard Stallman]

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

  > The fact that LibreJS complains doesn't mean that the software is 
  > non-free. It just means that the annotations that LibreJS would 
  > recognize are missing. Most of the Internet is missing those.

That is the understatement of the year.  Most of the Web is full
of nonfree Javascript, and detecting it is why we need LibreJS. 

                                                                  The 
  > overall mission of having JS files come with licenses in some form or 
  > other doesn't sound bad, but it shouldn't be a hard requirement for our 
  > platform, I think. It's not an urgent thing to fix.

It is ok to skip the LibreJS check for a specific site if we check its
licenses carefully "by hand".  If done right, that answers the same
question.

But that is harder than one might think.  Many sites load HTML from
other sites.  When they do that, the Javascript used by those other
sites' HTML and Javascript is included by reference into the site
being checked.  So we would need to check the pertinent parts of those
sites too.

We ought to recheck the site from time to time, if we can't get
LibreJS to do it for us.  Or perhaps diff it against its old HTML, to
notice when to recheck.


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

Re: Choice of bug tracker

[Richard Stallman]

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

  > Regarding "workability", we have EMBA for people to try out. It's been 
  > there for several years. Unless Gitlab is crossed out from the list of 
  > contestants already.

gitlab.com gets a failing grade as a repository.
See https://www.gnu.org/software/repo-criteria-evaluation.html.
We urge GNU packages not to use gitlab.com.

Specifically limited use of gitlab.com may not encounter that
problem.  It would be necessary to check the specific case.

However, adopting a bug tracker is a decision we hope not to have to
change again for years.  That calls for using a server run by people
we can trust; which means, people who share our values.  It is hard for
a company to merit that much trust.

The Gitlab software ls a different issue.  I gather that it is all
free software, so there is no bar to our installing it on a server and
running it.  If Gitlab.com changes its policy, we could continue running
the previous version of the software, or else patch their release.

Regarding using an email responder to file submissions in a server:

  > The main limitation, however, is that this design requires people to 
  > create accounts in the system. Even just to file new reports.

If a server requires that, that is a major negative.  Aside from being
a nuisance for each person to start to use, it also infringes each
user's privacy.

Worse, if the site requires that, it may also require running nonfree
Javascript to create an account.  That would be morally unacceptable:
we can't direct users to run nonfree programs.

If the site does not do that now, will it start some years from now?
Will it start using Cloudflare, which requires nonfree Javascript for
users coming in through the Tor network?  If the developers don't
share our values, we have to treat that as a permanent danger.

I have a possible workaround for all of that.  Could we use one single
account GNU-EMAIL to file all email submissions, and record who really
sent each submission (obtained from the From field) in another data
field in the submission?

If the site developers care about us a little, they could add a
feature to use the From-field submitter, for display and search,
instead of the account name, when that latter is GNU-EMAIL.

(With a little more work they could make this feature more elegant and
general, so other projects could do likewise.  Each would make its own
account for email submissions.  We could release the email responder
program as a GNU package so they couid use it.)

  > That's what I was saying: if we encouraged the use of ELPA more, the 
  > issue of our common bug tracker (and whether it's good or not) would be 
  > a little less important.

I presume that ELPA here is short for GNU ELPA.

There are more important reasons to put a given package in GNU ELPA or
core Emacs.  It would not be wise to override them for this.

However, if we have an email responder that files submissions in
another server, it could look at the package name to decide which
server to file them in.  Or a package could specify where to forward
the email to.  This wey we could enable each package to use its choice
among our acceptable bug trackers.  This would work for core packages
just as for GNU ELPA packages.


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

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, emacs-devel@gnu.org
> Date: Wed, 30 Aug 2023 22:07:05 -0400
> 
> However, adopting a bug tracker is a decision we hope not to have to
> change again for years.  That calls for using a server run by people
> we can trust; which means, people who share our values.  It is hard for
> a company to merit that much trust.

To clarify: what we currently discuss is NOT a move to a different bug
tracker; that is a very serious decision, and we are not even close to
be able to make it.  What is being discussed here is how to try using
another tracker, for now using it in parallel with debbugs, until we
have enough experience and data points to make that decision about
switching away from debbugs.  Also, which alternative tracker(s) to
try and how to evaluate their merits and demerits.

Until now such discussions were purely theoretical: we didn't try to
actually use any of the alternatives for real work.  My hope is that
we could now conduct a more practical experiment and gain some
real-life experience and conclusions.

> I have a possible workaround for all of that.  Could we use one single
> account GNU-EMAIL to file all email submissions, and record who really
> sent each submission (obtained from the From field) in another data
> field in the submission?

This needs to be set up, since the users who report problems must have
an easy way of receiving the discussions about their issues via email
and sending responses to questions.  Any significant inconvenience in
these aspects will simply kill the email-based workflow of working on
patches and discussing issues and bugs.

Re: Choice of bug tracker

[Richard Stallman]

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

  >   What is being discussed here is how to try using
  > another tracker, for now using it in parallel with debbugs, until we
  > have enough experience and data points to make that decision about
  > switching away from debbugs.

Thanks for clarifying.  I see no harm in trying that.  I did not see
this explicitly stated or clarified this in the recent discussion, so
I did not know.

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

Re: Choice of bug tracker

[Dmitry Gutov]

On 31/08/2023 05:07, Richard Stallman wrote:
> The Gitlab software ls a different issue.  I gather that it is all
> free software, so there is no bar to our installing it on a server and
> running it.  If Gitlab.com changes its policy, we could continue running
> the previous version of the software, or else patch their release.

When we talk about trying Gitlab, we mean this approach. We already have 
an experimental instance running on GNU's servers, after all. The 
aforementioned EMBA.

> Regarding using an email responder to file submissions in a server:
> 
>    > The main limitation, however, is that this design requires people to
>    > create accounts in the system. Even just to file new reports.
> 
> If a server requires that, that is a major negative.  Aside from being
> a nuisance for each person to start to use, it also infringes each
> user's privacy.
> 
> Worse, if the site requires that, it may also require running nonfree
> Javascript to create an account.  That would be morally unacceptable:
> we can't direct users to run nonfree programs.
> 
> If the site does not do that now, will it start some years from now?
> Will it start using Cloudflare, which requires nonfree Javascript for
> users coming in through the Tor network?  If the developers don't
> share our values, we have to treat that as a permanent danger.

Again, we're talking about a self-hosted solution. The (apparently 
solved) issue of reCaptcha was mentioned upthread (there is now a 
setting which switches to a different, simpler method that doesn't use 
Google's solution).

> I have a possible workaround for all of that.  Could we use one single
> account GNU-EMAIL to file all email submissions, and record who really
> sent each submission (obtained from the From field) in another data
> field in the submission?

I don't know about the feasibility of saving the "From" value into 
another data field in the same database, but whatever piece of code 
would be running the "one single account" could potentially maintain a 
database of associations between bug reports and email accounts (reporters).

But that's an open-ended feature, e.g. at some point people will want to 
be able to unsubscribe from email follow-ups in those threads, and we 
would be required to add that feature too (maybe even by law). We're 
talking about a mailing list software, basically.

> If the site developers care about us a little, they could add a
> feature to use the From-field submitter, for display and search,
> instead of the account name, when that latter is GNU-EMAIL.
> 
> (With a little more work they could make this feature more elegant and
> general, so other projects could do likewise.  Each would make its own
> account for email submissions.  We could release the email responder
> program as a GNU package so they couid use it.)

Looking at past reports, Gitlab developers do discuss our issues and fix 
some of them, but not all, and not right away. Which seems logical overall.

Speaking of privacy, though, not exposing everybody's unobfuscated email 
addresses to the web is considered a privacy advantage in many contexts. 
That helps avoid spam, and it helps tracking an individual across the 
Web a little more difficult (because for every platform the searches 
would at least have to work out the specific way every given site 
obfuscates the emails, if they're available at all).

OTOH, having to create an account doesn't seem to create any additional 
privacy risks, if we're only asking for email, password, and the account 
verification using said email.

Re: Choice of bug tracker

[Richard Stallman]

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

  > When we talk about trying Gitlab, we mean this approach. We already have 
  > an experimental instance running on GNU's servers, after all. The 
  > aforementioned EMBA.

That is a better choice, but I had no idea of that choice because
people just said "Gitlab" and never specified the software rather than
the disservice.

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

Re: Choice of bug tracker

[Richard Stallman]

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

Eli, which other bug trackers would you consider switching to?
That is, which ones are good enough to be reasonable choices?

Do they work as well via email as our current bug tracker?

Is any of them maintained by people who are friends of ours
and might add a feature occasionally because we explain how
it would make operations better?


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

Re: Choice of bug tracker

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> cc: emacs-devel@gnu.org
> Date: Wed, 30 Aug 2023 22:07:05 -0400
> 
> Eli, which other bug trackers would you consider switching to?
> That is, which ones are good enough to be reasonable choices?

Sorry, I don't know, and don't have time to do the required research.
Someone else will have to do the job of finding the candidates and
studying their features.  Some of that was already done in the past,
so assuming things didn't change drastically, we already have the
information in our archives.

> Do they work as well via email as our current bug tracker?

Most do, but whether "as well as" is accurate is still being
considered and evaluated.

> Is any of them maintained by people who are friends of ours
> and might add a feature occasionally because we explain how
> it would make operations better?

To some extent, yes.  Again, something to figure out as part of the
above job, which I cannot take up myself.

Re: Choice of bug tracker

[Richard Stallman]

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

  > That's what I was saying: if we encouraged the use of ELPA more, the 
  > issue of our common bug tracker (and whether it's good or not) would be 
  > a little less important.

There are more important reasons to put, or not put, a given package
in GNU ELPA or core Emacs.  It would not be wise to override them for
this.

(I presume you mean GNU ELPA.)

However, if we implement the proposed email responder that files
reports with another server, it could look at the package name to
decide which bug tracker server to file them in.  This wey we could
enable each packages to use its choice of bug tracker, regardless of
which category that package is in.

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

> ...having those not bundled would
> mean users don't have an OOTB solution, and would need to invent their
> own wheels.  It also means the instructions about how to install the
> relevant grammars would not have been in NEWS, so users would need to
> discover that by themselves...

Side question: Is there any reason ORG_NEWS is separate from NEWS?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Dmitry Gutov <dmitry@gutov.dev>, philipk@posteo.net,
>  danny@dfreeman.email, stefankangas@gmail.com, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> Date: Thu, 31 Aug 2023 10:20:18 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > ...having those not bundled would
> > mean users don't have an OOTB solution, and would need to invent their
> > own wheels.  It also means the instructions about how to install the
> > relevant grammars would not have been in NEWS, so users would need to
> > discover that by themselves...
> 
> Side question: Is there any reason ORG_NEWS is separate from NEWS?

Ease of merging, I suppose?  Merging NEWS from the release branch is
tricky enough.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Side question: Is there any reason ORG_NEWS is separate from NEWS?
>
> Ease of merging, I suppose?  Merging NEWS from the release branch is
> tricky enough.

Is there anything Org devs can do to help this?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> Date: Thu, 31 Aug 2023 10:54:52 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Side question: Is there any reason ORG_NEWS is separate from NEWS?
> >
> > Ease of merging, I suppose?  Merging NEWS from the release branch is
> > tricky enough.
> 
> Is there anything Org devs can do to help this?

I don't think so, no.

But please note that NEWS from emacs-NN branch are "merged" into
NEWS.NN on master, whereas ORG-NEWS seem to describe several versions
in the same file.  One more reason to keep them separate, I guess.

Why do you think we should consider merging these two? what is the
advantage?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Is there anything Org devs can do to help this?
>
> I don't think so, no.
>
> But please note that NEWS from emacs-NN branch are "merged" into
> NEWS.NN on master, whereas ORG-NEWS seem to describe several versions
> in the same file.  One more reason to keep them separate, I guess.

For ORG-NEWS, it is trivial to separate news from different versions -
they are all grouped under the common "Version X.X" heading.

> Why do you think we should consider merging these two? what is the
> advantage?

After recent Emacs release, a number of blog posts and videos appeared
reviewing new features and changes in Emacs - none looked into Org mode.

That was natural - people looked into NEWS file, but not ORG-NEWS. I am
not sure if it is common knowledge that ORG-NEWS file, separate from
NEWS is even a thing.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Yeah, a program written in C/C++/Rust which contains an interpreter
> (and multiple jit's) for a dynamic programming language and has most
> of its interface written in it, supports user extensions in the same
> language, support display of arbitrary files and has several related
> but different mechanisms for guiding the visuals and the layout of
> said display. It also supports bidi.

Using Bidi implementations which already exist, implementing standards
already specified, and applying foreknowledge acquired through the
development of other implementations of those standards, correct?

When was the last time Firefox concerned itself with DPMI memory
extenders?  The disparate means of obtaining boot times on different
Unix and Microsoft systems?  File ACLs, SELinux, D-Bus, inode
notifications, ELF, xcoff, the 9k800 aout?

The scale and rapid development that is mandatory for a functioning web
browser sounds impressive, but is ultimately narrow in scope.  Emacs's
requirements are less imposing but greater in number, which compounded
by a group of active developers whose number pales in comparison to that
of Firefox, means that reducing the strain on any one of them is an
overriding objective.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 28/08/2023 03:21, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Yeah, a program written in C/C++/Rust which contains an interpreter
>> (and multiple jit's) for a dynamic programming language and has most
>> of its interface written in it, supports user extensions in the same
>> language, support display of arbitrary files and has several related
>> but different mechanisms for guiding the visuals and the layout of
>> said display. It also supports bidi.
> 
> Using Bidi implementations which already exist, implementing standards
> already specified, and applying foreknowledge acquired through the
> development of other implementations of those standards, correct?

Something that we'd happily do as well, wouldn't we?

> When was the last time Firefox concerned itself with DPMI memory
> extenders?  The disparate means of obtaining boot times on different
> Unix and Microsoft systems?  File ACLs, SELinux, D-Bus, inode
> notifications, ELF, xcoff, the 9k800 aout?

Sorry if I'm not up-to-date with each and every component, but Firefox 
devs surely have to deal with SELinux, D-Bus, and executable formats.

JavaScript also has a filesystem access API.

> The scale and rapid development that is mandatory for a functioning web
> browser sounds impressive, but is ultimately narrow in scope.  Emacs's
> requirements are less imposing but greater in number,

...

> which compounded
> by a group of active developers whose number pales in comparison to that
> of Firefox, means that reducing the strain on any one of them is an
> overriding objective.

Even if that were the case, the plan breaks as soon as we run out of 
existing active developers, if we fail to recruit enough new ones.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Something that we'd happily do as well, wouldn't we?

If it were not for how the nature of our work precludes consulting any
standards, and by extension exploiting any foreknowledge of their
implementation, then yes.

> Sorry if I'm not up-to-date with each and every component, but Firefox
> devs surely have to deal with SELinux, D-Bus, and executable formats.

How so?  And why would Firefox concern itself with XCOFF and aout, when
it doesn't support either AIX or HP-UX?

> JavaScript also has a filesystem access API.

These interfaces are very superficial and haven't been ported to even a
fragment of the systems Emacs has.

> Even if that were the case, the plan breaks as soon as we run out of
> existing active developers, if we fail to recruit enough new ones.

If that hasn't transpired in 35 years, I doubt it will in the next 35.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 03:38:45 +0300
> Cc: Eli Zaretskii <eliz@gnu.org>, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 28/08/2023 03:21, Po Lu wrote:
> > Dmitry Gutov <dmitry@gutov.dev> writes:
> > 
> >> Yeah, a program written in C/C++/Rust which contains an interpreter
> >> (and multiple jit's) for a dynamic programming language and has most
> >> of its interface written in it, supports user extensions in the same
> >> language, support display of arbitrary files and has several related
> >> but different mechanisms for guiding the visuals and the layout of
> >> said display. It also supports bidi.
> > 
> > Using Bidi implementations which already exist, implementing standards
> > already specified, and applying foreknowledge acquired through the
> > development of other implementations of those standards, correct?
> 
> Something that we'd happily do as well, wouldn't we?

We do that always when the library fits the bill.  But in many cases
it doesn't (or a library doesn't yet exist), because Emacs has some
unique requirements.

> > The scale and rapid development that is mandatory for a functioning web
> > browser sounds impressive, but is ultimately narrow in scope.  Emacs's
> > requirements are less imposing but greater in number,
> 
> ...
> 
> > which compounded
> > by a group of active developers whose number pales in comparison to that
> > of Firefox, means that reducing the strain on any one of them is an
> > overriding objective.
> 
> Even if that were the case, the plan breaks as soon as we run out of 
> existing active developers, if we fail to recruit enough new ones.

That's true, but the single most important lesson we learn from the
history of GNU Emacs is that this danger never actually materialized.
Which doesn't mean we should not try to recruit more, of course, it
just means that we shouldn't be too pessimist about this.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 28/08/2023 15:17, Eli Zaretskii wrote:
>>> which compounded
>>> by a group of active developers whose number pales in comparison to that
>>> of Firefox, means that reducing the strain on any one of them is an
>>> overriding objective.
>> Even if that were the case, the plan breaks as soon as we run out of
>> existing active developers, if we fail to recruit enough new ones.
> That's true, but the single most important lesson we learn from the
> history of GNU Emacs is that this danger never actually materialized.
> Which doesn't mean we should not try to recruit more, of course, it
> just means that we shouldn't be too pessimist about this.

When it materializes, we're simply done. There won't be any learning 
from that lesson.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Mon, 28 Aug 2023 15:22:13 +0300
> Cc: luangruo@yahoo.com, philipk@posteo.net, danny@dfreeman.email,
>  stefankangas@gmail.com, emacs-devel@gnu.org, manuel.uberti@inventati.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 28/08/2023 15:17, Eli Zaretskii wrote:
> >>> which compounded
> >>> by a group of active developers whose number pales in comparison to that
> >>> of Firefox, means that reducing the strain on any one of them is an
> >>> overriding objective.
> >> Even if that were the case, the plan breaks as soon as we run out of
> >> existing active developers, if we fail to recruit enough new ones.
> > That's true, but the single most important lesson we learn from the
> > history of GNU Emacs is that this danger never actually materialized.
> > Which doesn't mean we should not try to recruit more, of course, it
> > just means that we shouldn't be too pessimist about this.
> 
> When it materializes, we're simply done. There won't be any learning 
> from that lesson.

When and _if_ it materializes.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

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

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

>

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 09:26, João Távora wrote:
> 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.

Have you noticed any difference in the amount of bug reports here vs 
Github? Any difference in the volume of user participation: further 
comments, follow-ups, etc?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Sun, Aug 27, 2023 at 11:51 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 27/08/2023 09:26, João Távora wrote:
> > 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.
>
> Have you noticed any difference in the amount of bug reports here vs
> Github? Any difference in the volume of user participation: further
> comments, follow-ups, etc?

I still keep the GitHub repo open for those, though it's not the code
upstream anymore.  Some discussions still happen there (and I ask to move
them here if I find them particularly relevant).  A hybrid solution much
like TRAMP and Gnus and other projects.  I'd say I notice an increase
in _total_ participation if I add the Emacs bug tracker + emacs-devel +
that, but one would have to measure.  The ratio seems to be about
two GitHub posts for every Emacs tracker post.

These things are very seasonal though, and usually correlate with
announcement of new features, new versions of the LSP standard, etc.
And of course they correlate heavily with the time that _I_ have to
devote to the project.  If I am more active, so are Eglot's users.

A point worth mentioning is that the quality of bug reports (and
feature requests and support requests) is generally slightly higher
in the Emacs bug tracker, as I think people feel the responsibility
of writing something structured and consistent instead of just a screenshot
and a "look it doesn't work".  They write it usually under their own name
and email address (as opposed to a somewhat anonymous alias).  I think this
is a good thing.

So I don't know how to answer your question, given this hybrid model.
I think if I had just shut down the GitHub, we'd see more stuff pop up in
Emacs tracker, but admittedly some users would give up.  Then again, as
Po observes, some users likely find the GitHub registration a barrier to
participation, too.  I get some personal email as well.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 14:10, João Távora wrote:
> On Sun, Aug 27, 2023 at 11:51 AM Dmitry Gutov<dmitry@gutov.dev>  wrote:
>> On 27/08/2023 09:26, João Távora wrote:
>>> 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.
>> Have you noticed any difference in the amount of bug reports here vs
>> Github? Any difference in the volume of user participation: further
>> comments, follow-ups, etc?
> I still keep the GitHub repo open for those, though it's not the code
> upstream anymore.  Some discussions still happen there (and I ask to move
> them here if I find them particularly relevant).  A hybrid solution much
> like TRAMP and Gnus and other projects.  I'd say I notice an increase
> in_total_  participation if I add the Emacs bug tracker + emacs-devel +
> that, but one would have to measure.  The ratio seems to be about
> two GitHub posts for every Emacs tracker post.

Naturally the sum of the two will be higher, but you *are* keeping the 
GitHub tracker alive, and people still use it 2x as often as Debbugs, 
even though the README asks them to use the latter. Even though that 
last part by itself necessarily increases the visibility of Debbugs with 
this additional advertisement. And despite all the active contributors 
having moved to Debbugs, again, by your request.

This is the point I was making.

As a thought experiment, I invite the reader to imagine how much fewer 
Eglot activity on Debbugs we'd be getting without that GitHub page at all.

> These things are very seasonal though, and usually correlate with
> announcement of new features, new versions of the LSP standard, etc.
> And of course they correlate heavily with the time that_I_  have to
> devote to the project.  If I am more active, so are Eglot's users.

Naturally.

> A point worth mentioning is that the quality of bug reports (and
> feature requests and support requests) is generally slightly higher
> in the Emacs bug tracker, as I think people feel the responsibility
> of writing something structured and consistent instead of just a screenshot
> and a "look it doesn't work".  They write it usually under their own name
> and email address (as opposed to a somewhat anonymous alias).  I think this
> is a good thing.

That's the same "50 squats" principle I mentioned previously.

> So I don't know how to answer your question, given this hybrid model.
> I think if I had just shut down the GitHub, we'd see more stuff pop up in
> Emacs tracker, ...

Interesting theory. I half-wish we could try it someday.

My own experience is that the projects inside the core, which were never 
on Github, get incomparably less feedback. Much fewer bug reports, 
questions, suggestions, and so on.

project.el (for example) is most of the time treated like a code drop 
which people either use, or code around, or revert to Projectile.

Same for Xref, except without the third option.

> Then again, as
> Po observes, some users likely find the GitHub registration a barrier to
> participation, too.

Those could just be using Debbugs, no?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Those could just be using Debbugs, no?

Of course, but not if the plans you propose come to fruition, in which
case Debbugs will be supplanted in its entirety.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 27/08/2023 16:42, Po Lu wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> Those could just be using Debbugs, no?
> Of course, but not if the plans you propose come to fruition, in which
> case Debbugs will be supplanted in its entirety.

I figured that sentence was related to the next one (about personal 
emails). That got me puzzled.

Anyway, to answer your question, it's possible to have an automatic 
forwarding system (where there would be one account which creates all 
reports that arrive at a certain address), but there would be no way to 
get answers for follow-up questions. Looks like that's what the 
discussion here arrived at as well: 
https://bugzilla.mozilla.org/show_bug.cgi?id=105629#c12

A possible alternative is if we'll have an Emacs package for interacting 
with the bug tracker anyway, it could use (or ask for) credentials, and 
when those are missing, try to help out with registration and passing 
the send-email-click-confirmation loop. Not 100% sure how stable such an 
implementation would be, but we could try and see.

Or those users would just use the mailing lists (I'm guessing those 
won't go away anytime soon). Or email Joao directly again.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 27/08/2023 16:42, Po Lu wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> 
>>> Those could just be using Debbugs, no?
>> Of course, but not if the plans you propose come to fruition, in
>> which
>> case Debbugs will be supplanted in its entirety.
>
> I figured that sentence was related to the next one (about personal
> emails). That got me puzzled.
>
> Anyway, to answer your question, it's possible to have an automatic
> forwarding system (where there would be one account which creates all
> reports that arrive at a certain address), but there would be no way
> to get answers for follow-up questions. Looks like that's what the
> discussion here arrived at as well:
> https://bugzilla.mozilla.org/show_bug.cgi?id=105629#c12
>
> A possible alternative is if we'll have an Emacs package for
> interacting with the bug tracker anyway, it could use (or ask for)
> credentials, and when those are missing, try to help out with
> registration and passing the send-email-click-confirmation loop. Not
> 100% sure how stable such an implementation would be, but we could try
> and see.

That only satisfies one half of the problem; Emacs developers also
expect a bug tracker that functions well with E-mail.  It should be
possible to open, close, and tag bugs from mail, and the bug tracker
should propagate reference and In-Reply-To headers so that threading can
continue to function.  AFAIU when this subject was last visited, we
arrived at the conclusion that no extant bug tracker except Debbugs
provides such functionality.

Debbugs also provides a lot of latitude to reporters, whereby they can
tag or close bugs at will.  This isn't afforded by the other major bug
tracking systems in existence, and we can't predict how well such an
approach will scale to them.  Just another thing to contemplate, I
suppose...

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 28/08/2023 03:08, Po Lu wrote:
>> A possible alternative is if we'll have an Emacs package for
>> interacting with the bug tracker anyway, it could use (or ask for)
>> credentials, and when those are missing, try to help out with
>> registration and passing the send-email-click-confirmation loop. Not
>> 100% sure how stable such an implementation would be, but we could try
>> and see.
> That only satisfies one half of the problem; Emacs developers also
> expect a bug tracker that functions well with E-mail.  It should be
> possible to open, close, and tag bugs from mail, and the bug tracker
> should propagate reference and In-Reply-To headers so that threading can
> continue to function.  AFAIU when this subject was last visited, we
> arrived at the conclusion that no extant bug tracker except Debbugs
> provides such functionality.

Not 100% the same, but there's this thing called Bugzilla Inbound Email 
Interface: https://www.bugzilla.org/docs/4.4/en/html/api/email_in.html 
which allows creating or modifying bugs from email (as long as the email 
belongs to a valid account).

(Redhat's installation apparently checks against verified PGP keys too, 
but the basic one doesn't).

It's not immediately apparent whether this script allows closing bugs, 
but it's Perl. Given some familiarity, shouldn't be too hard to extend.

In-Reply-To should also work 
(https://bugzilla.mozilla.org/show_bug.cgi?id=31314).

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

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

On Sun, Aug 27, 2023, 22:59 Dmitry Gutov <dmitry@gutov.dev> wrote:

>
>
> Or those users would just use the mailing lists (I'm guessing those
> won't go away anytime soon). Or email Joao directly again.
>

You can't get enough of me, it seems :-)  Why have I popped up here
again, what's the relation?

>

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Naturally the sum of the two will be higher, but you *are* keeping the
> GitHub tracker alive, and people still use it 2x as often as Debbugs,
> even though the README asks them to use the latter. Even though that
> last part by itself necessarily increases the visibility of Debbugs
> with this additional advertisement. And despite all the active
> contributors having moved to Debbugs, again, by your request.
>
> This is the point I was making.

Just open

   https://github.com/joaotavora/eglot/issues/new/choose

And see these three proposed actions, in order

1. Bug report with MRE recipe
   Something didn't work right, and you've written a perfect MRE recipe

2. Report bugs informally, discuss Eglot, request features
   Informally and freely report problems, ask questions, etc

3. Start an email discussion in bug-gnu-emacs@gnu.org

...

The first two go GitHub's discussion facilities.  So, it's not true I
ask people to use Debbugs exclusively.  So please don't twist facts to
indulge your intuition, which is quite probably wrong in at least some
aspects.  You know these low-effort users don't even read the README
(most haven't read the big letters saying that the repo isn't the
upstream anymore, so I still get GitHub PRs).  They google "Eglot", land
on the github repo, press "issues", look around, press "new issue" and
get that list.  Then they choose most likely one of the first two
bullets..

>> and a "look it doesn't work".  They write it usually under their own name
>> and email address (as opposed to a somewhat anonymous alias).  I think this
>> is a good thing.
>
> That's the same "50 squats" principle I mentioned previously.

I missed it, but it's not a very good sporting analogy.  50 squats are
useless unless you're some kind of gym bronco.  In contrast, spending 5
minutes reading some prose I wrote about the usual difficulties with
Eglot bug reports is not 50 squats, it is time well spent.  And not much
to request of a user of Free software about to ask for much more than 5
minutes of my mind.  It will reduce the amount of questioning and
guessing that I have to do, thus severely increasing the chances that
the report reaches some positive outcome.

Even the super-fancy super-modern JS frameworks on GitHub ask reporters
to do much more, down to actually proving their MREs in actual code.

And yet I still explicitly offer people a forum to "informally and
freely report problems".  Of course, if they just want to chat, there's
a limit on how I can help, so often I end up referring people to the
troubleshooting guide.

>> So I don't know how to answer your question, given this hybrid model.
>> I think if I had just shut down the GitHub, we'd see more stuff pop up in
>> Emacs tracker, ...
>
> Interesting theory. I half-wish we could try it someday.

Why?  You asked questions about the frequency of bug reports I get on
both forums and I gave honest answers.  This last week I got more
Debbugs Eglot email feedback than GitHub email,for example.  Again,
don't try to twist my data to somehow categorically prove debbugs sucks.

Corny as it sounds, instead advance your goals with positivity.  There
can be a better bug tracker out there, of course.  I think you should
"sit down and do the work" (TM).  If you're an expert in these things,
find a forge, implement all or at least most of the hard requirements.
Discuss (preferably offline) with the main stakeholders, show something
palpable even if not finished.  And yes, with every serious enterprise
comes the possibility of failure, partial or even total.  That's part of
the game and part of the thrill to be honest.

But Eli has already said that he's willing to give it a fair shot, IIUC.
I would just trust him.  You also have my support.  And because you
can't do omelettes without eggs, you could probably even muster some
financial support, an effort which I would contribute to..

> My own experience is that the projects inside the core, which were
> never on Github, get incomparably less feedback. Much fewer bug
> reports, questions, suggestions, and so on.
>
> project.el (for example) is most of the time treated like a code drop
> which people either use, or code around, or revert to Projectile.

What "feedback" are you looking for?  Improvements? Recognition?
(serious recognition, not silly github stars).  Scrutiny?  riticism?
All of the above?

Not every package has to have direct feedback about it.  Some packages
are about infrastructure, and project.el is like that, partly.  Others
are about UI, like Company, so it makes sense you have more feedback
there.  It's good to have discrete packages, to be honest.  Who gives
feedback on Emacs's wonderful C macrology?  Yet they use it every day.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 28/08/2023 04:37, João Távora wrote:

> The first two go GitHub's discussion facilities.  So, it's not true I
> ask people to use Debbugs exclusively.  So please don't twist facts to
> indulge your intuition, which is quite probably wrong in at least some
> aspects.

I made that conclusion from your past statements and, yes, the README: 
https://github.com/joaotavora/eglot#status-of-this-github-repository

> You know these low-effort users don't even read the README
> (most haven't read the big letters saying that the repo isn't the
> upstream anymore, so I still get GitHub PRs).  They google "Eglot", land
> on the github repo, press "issues", look around, press "new issue" and
> get that list.  Then they choose most likely one of the first two
> bullets..

Surely what "low-effort" users do or do not do would not reflect on the 
number of reports in Debbugs where only "good" bug reports arrive?

>>> and a "look it doesn't work".  They write it usually under their own name
>>> and email address (as opposed to a somewhat anonymous alias).  I think this
>>> is a good thing.
>>
>> That's the same "50 squats" principle I mentioned previously.
> 
> I missed it, but it's not a very good sporting analogy.  50 squats are
> useless unless you're some kind of gym bronco.  In contrast, spending 5
> minutes reading some prose I wrote about the usual difficulties with
> Eglot bug reports is not 50 squats, it is time well spent.  And not much
> to request of a user of Free software about to ask for much more than 5
> minutes of my mind.  It will reduce the amount of questioning and
> guessing that I have to do, thus severely increasing the chances that
> the report reaches some positive outcome.

The point was that any kind of barrier will filter out the less 
motivated, likely resulting in higher average quality.

It will filter some very good ones too, though.

> Even the super-fancy super-modern JS frameworks on GitHub ask reporters
> to do much more, down to actually proving their MREs in actual code.
> 
> And yet I still explicitly offer people a forum to "informally and
> freely report problems".  Of course, if they just want to chat, there's
> a limit on how I can help, so often I end up referring people to the
> troubleshooting guide.

All good to me.

> Corny as it sounds, instead advance your goals with positivity.  There
> can be a better bug tracker out there, of course.  I think you should
> "sit down and do the work" (TM).  If you're an expert in these things,
> find a forge, implement all or at least most of the hard requirements.
> Discuss (preferably offline) with the main stakeholders, show something
> palpable even if not finished.  And yes, with every serious enterprise
> comes the possibility of failure, partial or even total.  That's part of
> the game and part of the thrill to be honest.

That almost sounds easy when you phrase it like that.

>> My own experience is that the projects inside the core, which were
>> never on Github, get incomparably less feedback. Much fewer bug
>> reports, questions, suggestions, and so on.
>>
>> project.el (for example) is most of the time treated like a code drop
>> which people either use, or code around, or revert to Projectile.
> 
> What "feedback" are you looking for?  Improvements? Recognition?
> (serious recognition, not silly github stars).  Scrutiny?  riticism?
> All of the above?

Sure.

> Not every package has to have direct feedback about it.  Some packages
> are about infrastructure, and project.el is like that, partly.  Others
> are about UI, like Company, so it makes sense you have more feedback
> there.

I can see when people have issues, from discussions online. And in one 
case they ask, in the other -- more readily work around.

> It's good to have discrete packages, to be honest.  Who gives
> feedback on Emacs's wonderful C macrology?  Yet they use it every day.

The principle extends to all the core packages I had been paying 
attention to. ruby-mode and VC have graphical components as well. Xref 
-- even more so.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Surely what "low-effort" users do or do not do would not reflect on
> the number of reports in Debbugs where only "good" bug reports arrive?

Of course not, but it reflects on the _ratio_ of one type of reports to
the other, which is the data point I provided and the one which is
half-relevant to your quest of finding out if debbbugs is The Worst Bug
Tracker of All Time.

By the way, I get good bug reports in GitHub too.  I just meant that,
overwhelmingly the less good bug reports happen in GitHub.

> The point was that any kind of barrier will filter out the less
> motivated, likely resulting in higher average quality.

What you call the "barrier" are actually helpful instructions to provide
a better bug report, at least one I can help with.  In any sort of
office with a feedback loop, there's usually some kind of formality to
communicate feedback, not some box labeled "vomit any idea in here
please".  And I'm not particularly interested in ideas of people who
just dump their thoughts.  Even though sometimes they may be the
beginnings of interesting thoughts.

> It will filter some very good ones too, though.

I really can't see how.  If you have a "very good one" and can't be
bothered to provide some information (which isn't even absolutely
required to start the conversation), then I don't think you have a "very
good one", not even a decent one.

>> Corny as it sounds, instead advance your goals with positivity.  There
>> can be a better bug tracker out there, of course.  I think you should
>> "sit down and do the work" (TM).  If you're an expert in these things,
>> find a forge, implement all or at least most of the hard requirements.
>> Discuss (preferably offline) with the main stakeholders, show something
>> palpable even if not finished.  And yes, with every serious enterprise
>> comes the possibility of failure, partial or even total.  That's part of
>> the game and part of the thrill to be honest.
>
> That almost sounds easy when you phrase it like that.

No, it sounds easy when _you_ talk about it.  It certainly wouldn't be
easy _for me_ to do this work but you talk with such authority,
frequency and passion about it that I'm convinced you would be a
promising lead to the project.  I don't have to 100% agree to your views
to give you my support, and you shouldn't try to make everybody buy into
your plan beforehand.  At a certain point, just do it (more TM) You may
fail, but you may also succeed, and at least you did more than talk.

>> Not every package has to have direct feedback about it.  Some packages
>> are about infrastructure, and project.el is like that, partly.  Others
>> are about UI, like Company, so it makes sense you have more feedback
>> there.
>
> I can see when people have issues, from discussions online. And in one
> case they ask, in the other -- more readily work around.

That's a good thing: that can be just because the software you provided
is good and allows you to.  Do you like the workarounds or are they
somehow ghastly?  If the latter, the problem is the design of your
program.

By they way, I see lots of Eglot hacks and recipes and workarounds for
which I don't see any question in any of Eglot's forums.  It's just a
question of the general dimension of the program and the visibility it
has.

It seems you work on parts of Emacs with less visibility... Well, that's
life!  But it doesn't mean they are less important.  As, I've already
said that Xref, Eldoc, Flymake, Project and priceless completion system
tips from Stefan are the real champions that made Eglot possible.  But
Eglot gets much of the the visibility, it's true.  It's "bones of the
trade" as we say around here.

By the way, there's an Eglot report on Debbugs that is really more about
Xref, as usual (bug#65578).

>> It's good to have discrete packages, to be honest.  Who gives
>> feedback on Emacs's wonderful C macrology?  Yet they use it every day.
>
> The principle extends to all the core packages I had been paying
> attention to. ruby-mode and VC have graphical components as well. Xref
> -- even more so.

I use all your packages except ruby-mode.  I like them, but their
interfaces probably aren't as spiffy as Magit or packages with fancy
postmodern names.  I like that.  And they are stable, which I like even
more.  And the reason I don't comment on them too much is because they
mostly work.

A point worth making is that if you want to have a high visibility
project, start a high visibility project.  For the matter at hand, I
think a Debbugs replacement won't fundamentally change how people and
interact, judge or care about your work.  I would hope it would just
simplify the boring tasks we do currently.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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

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

Mainly because I am under the impression that of all the contributors to
Eglot, you have the best understanding of LSP as a protocol.  But you
are right, it was mostly the first example that came to mind when
comparing it to CEDET.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Sun, Aug 27, 2023 at 2:17 PM Philip Kaludercic <philipk@posteo.net> wrote:

> > 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.
>
> Mainly because I am under the impression that of all the contributors to
> Eglot, you have the best understanding of LSP as a protocol.  But you
> are right, it was mostly the first example that came to mind when
> comparing it to CEDET.


LSP is not hard at all, it's just a RPC protocol with a growing but
still fairly digestible spec.  You could "master" it if you wanted to,
perhaps in one or two afternoons, just by reading through it closely.
And in fact I invite you (and others) to do that.

I'm not that much of an expert in it anymore, and I mainly just consult it
for reference when someone requests a particular feature.

My "hard to replace" expertise in Eglot is more in niche areas like
that mammoth eglot-completion-at-point function and the techniques
to keep completion responsive and accurate.  But even others like JD
Smith have developed a decent idea of what's going on there (they also
have ideas of how it should work alternatively, which I don't agree
with at all, but that's another matter).

Anyway, a considerable contribution to Eglot would be just to
to do that close reading of the LSP standard and then survey exactly
what parts of it Eglot uses and what parts it doesn't, then add that
information to the manual or some internal document.  Also, as you read
through the LSP standard I'm sure you would collect lots of ideas,
maybe even some low-hanging fruit, or things to contribute to Eglot
as code.

J

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

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

On Sun, Aug 27, 2023, 2:25 AM João Távora <joaotavora@gmail.com> wrote:

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

There was a big discussion (or maybe many small ones) a few months ago on
the issues you had trying to coordinate releases if eglot as a standalone
package with its release in the core.


Lynn

>
>

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Sun, Aug 27, 2023 at 2:38 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Sun, Aug 27, 2023, 2:25 AM João Távora <joaotavora@gmail.com> wrote:
>>
>> 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.
>
>
> There was a big discussion (or maybe many small ones) a few months ago on the issues you had trying to coordinate releases if eglot as a standalone package with its release in the core.

I remember it, I was there, but I do hope that doesn't make me
a candidate for forced disappearance in any way.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

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

On Sun, Aug 27, 2023, 9:44 AM João Távora <joaotavora@gmail.com> wrote:

> On Sun, Aug 27, 2023 at 2:38 PM Lynn Winebarger <owinebar@gmail.com>
> wrote:
> >
> > On Sun, Aug 27, 2023, 2:25 AM João Távora <joaotavora@gmail.com> wrote:
> >>
> >> 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.
> >
> >
> > There was a big discussion (or maybe many small ones) a few months ago
> on the issues you had trying to coordinate releases if eglot as a
> standalone package with its release in the core.
>
> I remember it, I was there, but I do hope that doesn't make me
> a candidate for forced disappearance in any way.
>

No, but it would be one explanation of why you would be top of mind in a
discussion of why developers might not be inclined to be directly involved
in core development.

Lynn

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Sun, Aug 27, 2023 at 3:24 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Sun, Aug 27, 2023, 9:44 AM João Távora <joaotavora@gmail.com> wrote:
>>
>> On Sun, Aug 27, 2023 at 2:38 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>> >
>> > On Sun, Aug 27, 2023, 2:25 AM João Távora <joaotavora@gmail.com> wrote:
>> >>
>> >> 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.
>> >
>> >
>> > There was a big discussion (or maybe many small ones) a few months ago on the issues you had trying to coordinate releases if eglot as a standalone package with its release in the core.
>>
>> I remember it, I was there, but I do hope that doesn't make me
>> a candidate for forced disappearance in any way.
>
>
> No, but it would be one explanation of why you would be top of mind in a discussion of why developers might not be inclined to be directly involved in core development.

If it were that it misses the mark.  I had already been involved in
core  development years before Eglot, and in many other places, and I
have no plans to stop just because of that one divergence, which
wasn't even anything special considering baggage accumulated over
the 10+ years I've been doing this.

João

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

On Sun, Aug 27, 2023 at 11:14 AM João Távora <joaotavora@gmail.com> wrote:
> >
> > No, but it would be one explanation of why you would be top of mind in a discussion of why developers might not be inclined to be directly involved in core development.
>
> If it were that it misses the mark.  I had already been involved in
> core  development years before Eglot, and in many other places, and I
> have no plans to stop just because of that one divergence, which
> wasn't even anything special considering baggage accumulated over
> the 10+ years I've been doing this.

Right, that's where you would come down.  But if I were a developer of
an external package considering whether it should be moved into core
emacs, that discussion would be one I would be considering.

Lynn

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[João Távora]

On Mon, Aug 28, 2023 at 3:59 PM Lynn Winebarger <owinebar@gmail.com> wrote:
>
> On Sun, Aug 27, 2023 at 11:14 AM João Távora <joaotavora@gmail.com> wrote:
> > >
> > > No, but it would be one explanation of why you would be top of mind in a discussion of why developers might not be inclined to be directly involved in core development.
> >
> > If it were that it misses the mark.  I had already been involved in
> > core  development years before Eglot, and in many other places, and I
> > have no plans to stop just because of that one divergence, which
> > wasn't even anything special considering baggage accumulated over
> > the 10+ years I've been doing this.
>
> Right, that's where you would come down.  But if I were a developer of
> an external package considering whether it should be moved into core
> emacs, that discussion would be one I would be considering.

Sure, but also consider that a reasonable compromise was found in
the end, and that the move as a whole was a great success, and was
complemented by many existing Eglot users.  Dmitry is the sole
exception I know of, for other reasons being discussed in a side thread,
Dmitry isn't even a user yet, rather a provider of very important
infrastructure to Eglot.

So I get that reading a large energetic discussion is very
exciting but not need to lose track of the forest just
because you spot a particular branch of a tree catch fire from time
to time.

No bridges were burned and before and since that discussion much
more interesting things have been happening to Eglot in Emacs, and
the participants  in that discussion have resumed the healthy
collaboration of always.  Even though that may be more boring, I
would focus on that when considering moving a package to core.

João

RE: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Drew Adams]

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

;-)

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Dmitry Gutov <dmitry@gutov.dev> writes:

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

What about using something other than forge for discussions?
On Org ML, we have recently discussed an idea to have Discourse as the
means for users to interact with the mailing list via web UI:
https://list.orgmode.org/orgmode/87edvxnnqw.fsf@localhost/

Discourse has free licence, can be self-hosted, and has mailing list
integration.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Ihor Radchenko <yantar92@posteo.net> writes:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
>> - 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).
>
> What about using something other than forge for discussions?
> On Org ML, we have recently discussed an idea to have Discourse as the
> means for users to interact with the mailing list via web UI:
> https://list.orgmode.org/orgmode/87edvxnnqw.fsf@localhost/

Do you have an example of how this looks like, eg. a link to both a
mailing list archive and a discourse forum?

> Discourse has free licence, can be self-hosted, and has mailing list
> integration.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Philip Kaludercic <philipk@posteo.net> writes:

>> What about using something other than forge for discussions?
>> On Org ML, we have recently discussed an idea to have Discourse as the
>> means for users to interact with the mailing list via web UI:
>> https://list.orgmode.org/orgmode/87edvxnnqw.fsf@localhost/
>
> Do you have an example of how this looks like, eg. a link to both a
> mailing list archive and a discourse forum?

It is actually not exactly designed for mailing lists - rather as a
replacement for mailing lists.
What Discourse does is somewhat similar to Github - you can subscribe to
notifications via email and reply via email. In addition, new threads
can be created by sending emails, even by anonymous users.

Creating new threads works via "inbox" email that will trigger new
topics
https://meta.discourse.org/t/configure-incoming-email-to-create-new-topics-or-group-messages/62977
And replying is simply replying to special email address, automatically
generated for each post.

For mailing list, one may need an extra setup to propagate all the
messages to the associated mailing list (can be done by arranging
mailing list address as a "user" subscribed to all the posts and
comments). If some users submitting new threads via mailing list only,
thins might get a bit more tricky - one may need to arrange redirecting
new threads to the Discourse "inbox".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> It is actually not exactly designed for mailing lists - rather as a
> replacement for mailing lists.
> What Discourse does is somewhat similar to Github - you can subscribe to
> notifications via email and reply via email. In addition, new threads
> can be created by sending emails, even by anonymous users.
>
> Creating new threads works via "inbox" email that will trigger new
> topics
> https://meta.discourse.org/t/configure-incoming-email-to-create-new-topics-or-group-messages/62977
> And replying is simply replying to special email address, automatically
> generated for each post.
>
> For mailing list, one may need an extra setup to propagate all the
> messages to the associated mailing list (can be done by arranging
> mailing list address as a "user" subscribed to all the posts and
> comments). If some users submitting new threads via mailing list only,
> thins might get a bit more tricky - one may need to arrange redirecting
> new threads to the Discourse "inbox".

My experience with Discourse-based forums (such as the Haiku OS forum)
is that their paradigm revolves around linear ``topics'' of discussion,
wherein each post has precisely a single antecedent and a single
successor, and everyone is constantly in reply to all previous posters.

Very different from mail or net news, and not at all befitting Emacs,
much the same way a long flight is not very accommodating towards a
spontaneous bout of dysentry...

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> My experience with Discourse-based forums (such as the Haiku OS forum)
> is that their paradigm revolves around linear ``topics'' of discussion,
> wherein each post has precisely a single antecedent and a single
> successor, and everyone is constantly in reply to all previous posters.

True, although I would not call it as much disaster as you seems to imply.

> Very different from mail or net news, and not at all befitting Emacs,
> much the same way a long flight is not very accommodating towards a
> spontaneous bout of dysentry...

What about having Discourse as a supplement - Discourse discussions are
all mirrored on the mailing lists, but mailing list can have separate
discussions?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> True, although I would not call it as much disaster as you seems to
> imply.

How would you copy bug-gnulib into such a Discourse-managed thread?

> What about having Discourse as a supplement - Discourse discussions are
> all mirrored on the mailing lists, but mailing list can have separate
> discussions?

Then presumably the Discourse users would be left out, defeating the
very justification proposed for its use.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> True, although I would not call it as much disaster as you seems to
>> imply.
>
> How would you copy bug-gnulib into such a Discourse-managed thread?

Sorry, but I do not understand what you are referring to. Is bug-gnulib
is a mailing list? Is it any different from emacs-devel or gnu-emacs-help?

>> What about having Discourse as a supplement - Discourse discussions are
>> all mirrored on the mailing lists, but mailing list can have separate
>> discussions?
>
> Then presumably the Discourse users would be left out, defeating the
> very justification proposed for its use.

That way, some users may be able to create new threads at least, which
is apparently more comfortable for some users.

Also, Discourse allows per-thread subscription - a feature that is
absent from mailing lists. I heard multiple times from some users that
they do not want to subscribe to the mailing lists because of too much
traffic.

Note that Discourse-only threads are principally not any different from
different Discourse categories.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Sorry, but I do not understand what you are referring to. Is bug-gnulib
> is a mailing list? Is it any different from emacs-devel or gnu-emacs-help?

bug-gnulib is the list for the Gnulib portability library, from which
Emacs developers routinely seek assistance.

> That way, some users may be able to create new threads at least, which
> is apparently more comfortable for some users.

Do we really want to trouble Emacs development with yet another burden
to mind?  Two kinds of threads, in one of which certain subjects or
measures are off-limits, really?

> Also, Discourse allows per-thread subscription - a feature that is
> absent from mailing lists. I heard multiple times from some users that
> they do not want to subscribe to the mailing lists because of too much
> traffic.

Absent a subscription to a mailing list, you only receive mail that
names you in its carbon copy list, attaining that behavior with no
explicit action from you.  So in fact Discourse's ``per-thread
subscription'' shares nothing in common with a subscription to a mailing
list.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> That way, some users may be able to create new threads at least, which
>> is apparently more comfortable for some users.
>
> Do we really want to trouble Emacs development with yet another burden
> to mind?  Two kinds of threads, in one of which certain subjects or
> measures are off-limits, really?

What about using mailing list first then?
For mailing list users, there will be no difference.
For Disccourse, some topics might remain merged even when mailing list
thread branched off several discussion threads.

>> Also, Discourse allows per-thread subscription - a feature that is
>> absent from mailing lists. I heard multiple times from some users that
>> they do not want to subscribe to the mailing lists because of too much
>> traffic.
>
> Absent a subscription to a mailing list, you only receive mail that
> names you in its carbon copy list, attaining that behavior with no
> explicit action from you.  So in fact Discourse's ``per-thread
> subscription'' shares nothing in common with a subscription to a mailing
> list.

Sure. And some users do not want to subscribe to a mailing list. They
just want CC for certain threads they choose manually.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> What about using mailing list first then?
> For mailing list users, there will be no difference.
> For Disccourse, some topics might remain merged even when mailing list
> thread branched off several discussion threads.

I don't understand what you're proposing.  What is ``merged'' in this
context?  Is Discourse to assign each mailing list thread to a topic,
and post all follow ups there?

When I asked for these features in the context of a Chinese Emacs forum,
which also employs Discourse, I was informed that this was beyond its
capabilities.

> Sure. And some users do not want to subscribe to a mailing list. They
> just want CC for certain threads they choose manually.

Perhaps we are miscommunicating: participation in emacs-devel does not
demand a subscription.  Without one, you are only sent mail you are
expressly copied into.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> What about using mailing list first then?
>> For mailing list users, there will be no difference.
>> For Disccourse, some topics might remain merged even when mailing list
>> thread branched off several discussion threads.
>
> I don't understand what you're proposing.  What is ``merged'' in this
> context?  Is Discourse to assign each mailing list thread to a topic,
> and post all follow ups there?

To a category.

> When I asked for these features in the context of a Chinese Emacs forum,
> which also employs Discourse, I was informed that this was beyond its
> capabilities.

AFAIU, it is possible:
https://meta.discourse.org/t/configure-incoming-email-to-create-new-topics-or-group-messages/62977
https://meta.discourse.org/t/set-up-reply-by-email-with-pop3-polling/14003

May you point me to the emacs-china post where you asked about this?

>> Sure. And some users do not want to subscribe to a mailing list. They
>> just want CC for certain threads they choose manually.
>
> Perhaps we are miscommunicating: participation in emacs-devel does not
> demand a subscription.  Without one, you are only sent mail you are
> expressly copied into.

I am talking about lurkers - users who do not participate in a thread,
but want to get notified about _all_ the new emails.

Also, participation will only work for the thread branch that is
in-reply to an email send by an unsubscribed user, but not for other
emails in the thread.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> To a category.

[...]

> AFAIU, it is possible:
> https://meta.discourse.org/t/configure-incoming-email-to-create-new-topics-or-group-messages/62977
> https://meta.discourse.org/t/set-up-reply-by-email-with-pop3-polling/14003
>
> May you point me to the emacs-china post where you asked about this?

I don't have that link at hand, sorry.  But I asked about threads, and
how they are merged into topics, not ``categories''.

> I am talking about lurkers - users who do not participate in a thread,
> but want to get notified about _all_ the new emails.
>
> Also, participation will only work for the thread branch that is
> in-reply to an email send by an unsubscribed user, but not for other
> emails in the thread.

Ask the interlocutors to copy you in; it's no insurmountable hassle,
and a request I have made many times.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> AFAIU, it is possible:
>> https://meta.discourse.org/t/configure-incoming-email-to-create-new-topics-or-group-messages/62977
>> https://meta.discourse.org/t/set-up-reply-by-email-with-pop3-polling/14003
>>
>> May you point me to the emacs-china post where you asked about this?
>
> I don't have that link at hand, sorry.  But I asked about threads, and
> how they are merged into topics, not ``categories''.

From my understanding, it is also possible, although in limited way
(because of lack of reply branching in Discourse). emacs-china admins
may know better though - I'm just looking up Discourse docs.

>> I am talking about lurkers - users who do not participate in a thread,
>> but want to get notified about _all_ the new emails.
>>
>> Also, participation will only work for the thread branch that is
>> in-reply to an email send by an unsubscribed user, but not for other
>> emails in the thread.
>
> Ask the interlocutors to copy you in; it's no insurmountable hassle,
> and a request I have made many times.

I have to say that it is quite a hassle for a number of people.
As a lurker in most threads, sending a message and bothering all the
participants with such a request is not easy at all (I know that it is
not the case for all people, but it is really hard to jump in with
random seemingly unrelated request for someone like me).

Also, it does not feel reliable - I know very well how people forget
Reply All, let alone deliberately adding somebody in CC. Especially in
an active discussion where the participants may not immediately (or at
all) see a random email at the bottom of the thread tree.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> From my understanding, it is also possible, although in limited way
> (because of lack of reply branching in Discourse). emacs-china admins
> may know better though - I'm just looking up Discourse docs.

I'm inclined to believe them.

> not the case for all people, but it is really hard to jump in with
> random seemingly unrelated request for someone like me).

So we are obliged to sign up for more trouble, because of certain
individuals' ungrounded and moreover untrue qualms about etiquette?
Wouldn't we be better served by explaining how that _is_ acceptable?

> Also, it does not feel reliable - I know very well how people forget
> Reply All, let alone deliberately adding somebody in CC. Especially in
> an active discussion where the participants may not immediately (or at
> all) see a random email at the bottom of the thread tree.

When you witness this, feel free to complain.  It is a legitimate
greviance.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> not the case for all people, but it is really hard to jump in with
>> random seemingly unrelated request for someone like me).
>
> So we are obliged to sign up for more trouble, because of certain
> individuals' ungrounded and moreover untrue qualms about etiquette?
> Wouldn't we be better served by explaining how that _is_ acceptable?

This is not about etiquette. This is about personal feelings. Whether
acceptable for you or not, it is something very real and affects human
behaviour.

And what do you mean by "sign up for more trouble"? What I essentially
asked for - "It would be nice if anyone can subscribe to an individual
thread anonymously." I am not 100% sure why mailing list software does
not have such feature, but the fact that web forges do have it is one of
the objective reasons why they are viewed as more comfortable option.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> This is not about etiquette. This is about personal feelings. Whether
> acceptable for you or not, it is something very real and affects human
> behaviour.

We can't take everyone's misgivings at face value.  There is nothing
wrong with requesting to be copied in to a thread; if someone hestiates
to do so, we can explain that there is nothing to fear.  If he is still
hesitant thereafter, we won't be obliged to further accommodate him.

> And what do you mean by "sign up for more trouble"? What I essentially
> asked for - "It would be nice if anyone can subscribe to an individual
> thread anonymously." I am not 100% sure why mailing list software does
> not have such feature, but the fact that web forges do have it is one of
> the objective reasons why they are viewed as more comfortable option.

Introducing such a capability to the Emacs lists will compel us to bear
two different types of threads in mind, and that constitutes trouble.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> This is not about etiquette. This is about personal feelings. Whether
>> acceptable for you or not, it is something very real and affects human
>> behaviour.
>
> We can't take everyone's misgivings at face value.  There is nothing
> wrong with requesting to be copied in to a thread; if someone hestiates
> to do so, we can explain that there is nothing to fear.  If he is still
> hesitant thereafter, we won't be obliged to further accommodate him.

It would be an improvement if this were articulated somewhere in list
description. AFAIK, it is not.

Though I do not agree that explaining that "there is nothing to fear"
will remove the fear. It is not how things work in psychology. Not
always, at least.

In any case, explained or not, this kind of convention will (1) force
people to expose their email in the thread; (2) create an extra obstacle
to participate; (3) still gives no 100% guarantee that future discussion
will be CCed.

>> And what do you mean by "sign up for more trouble"? What I essentially
>> asked for - "It would be nice if anyone can subscribe to an individual
>> thread anonymously." I am not 100% sure why mailing list software does
>> not have such feature, but the fact that web forges do have it is one of
>> the objective reasons why they are viewed as more comfortable option.
>
> Introducing such a capability to the Emacs lists will compel us to bear
> two different types of threads in mind, and that constitutes trouble.

May you elaborate?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Though I do not agree that explaining that "there is nothing to fear"
> will remove the fear. It is not how things work in psychology. Not
> always, at least.

This brings to mind:

  Canst thou not minister to a mind diseased,
  Pluck from the memory a rooted sorrow,
  Raze out the written troubles of the brain,
  And with some sweet oblivious antidote
  Cleanse the stuffed bosom of that perilous stuff
  Which weighs upon the heart?

and of course, the only valid answer:

  Therein the patient
  Must minister to himself.

> In any case, explained or not, this kind of convention will (1) force
> people to expose their email in the thread

Which is a problem because?

> (2) create an extra obstacle to participate

A justified and insignificant one, however.

> (3) still gives no 100% guarantee that future discussion
> will be CCed.

How is this distinct from omitting the list itself from the carbon copy
list?  People (or MUAs) don't intentionally remove only individuals from
the carbon copy list, they either preserve it intact or delete
_everyone_, which includes the list and whatever message forwarding
system it might use.

Read only access to the list through a more reasonable system is
afforded through Gmane, and we could always start gnu.emacs.devel once
the FSF repairs the net news gateway.

> May you elaborate?

Any such forwarding system, if it does materialize, will compel us to
account for its existence and limitations before posting.  Or else it
will be absolutely meaningless.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> In any case, explained or not, this kind of convention will (1) force
>> people to expose their email in the thread
>
> Which is a problem because?

... a number of people are concerned about privacy and prefer to not
expose their emails.

>> (2) create an extra obstacle to participate
>
> A justified and insignificant one, however.

Lets agree to disagree here.

>> (3) still gives no 100% guarantee that future discussion
>> will be CCed.
>
> How is this distinct from omitting the list itself from the carbon copy
> list?  People (or MUAs) don't intentionally remove only individuals from
> the carbon copy list, they either preserve it intact or delete
> _everyone_, which includes the list and whatever message forwarding
> system it might use.
>
> Read only access to the list through a more reasonable system is
> afforded through Gmane, and we could always start gnu.emacs.devel once
> the FSF repairs the net news gateway.

Read-only access is precisely what I am talking about. But not for the
whole list - just for a single thread.

News gateway is much harder to setup and severely limits the available
MUA. For example, I have never managed to do it and instead relying on
emails.

>> May you elaborate?
>
> Any such forwarding system, if it does materialize, will compel us to
> account for its existence and limitations before posting.  Or else it
> will be absolutely meaningless.

Sorry, but I still don't understand. All the mailing list emails are
public already. How will the fact that some people read the same public
emails anonymously not from lists.gnu.org web interface, but from their
email client change anything?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> ... a number of people are concerned about privacy and prefer to not
> expose their emails.

In which case, they can read or download the list archives, correct?

> Read-only access is precisely what I am talking about. But not for the
> whole list - just for a single thread.

So IIUC, you're proposing that a significant amount of time and energy
be expended on an endeavor meant to accommodate a very small fraction of
people who are loath to subscribe to the list, reluctant to browse the
list archives by hand, and desire the contents of a single thread to be
delivered to them, without sending mail to each of its participants and
thereby disclosing their e-mail addresses.  A mouthful, right?

If we commit to embarking on this journey, then several requirements
have to be met at its outset.  Servers to run such a Discourse instance
must be located, and the help of a system administrator ready to
dedicate his time to its maintainence must be secured.  Moderators must
enlist to filter spam and other distasteful content emanating from
Discourse.

All to accommodate a smattering of individuals, whose existence is only
attested by circumstantial evidence and word-of-mouth.

Does this not impart upon you the impression that the problem is
patently inconsequential, and the proposed remedy extreme?

> News gateway is much harder to setup and severely limits the available
> MUA.

I am told Thunderbird is also a newsreader, and it is installed by
default on most of popular GNU/Linux distributions.

> For example, I have never managed to do it and instead relying on
> emails.

Open Gnus, then type:

  B news.gmane.io RET

Search for:

  gmane.emacs.devel

then type RET.

> Sorry, but I still don't understand. All the mailing list emails are
> public already. How will the fact that some people read the same public
> emails anonymously not from lists.gnu.org web interface, but from their
> email client change anything?

If the capacity to subscribe to a single thread from an MUA is truly all
that is being pursued, we would be better off operating a service for
that express purpose than a bulletin board system.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 12:00, Po Lu wrote:
> So IIUC, you're proposing that a significant amount of time and energy
> be expended on an endeavor meant to accommodate a very small fraction of
> people who are loath to subscribe to the list, reluctant to browse the
> list archives by hand, and desire the contents of a single thread to be
> delivered to them, without sending mail to each of its participants and
> thereby disclosing their e-mail addresses.

I imagine that it might be a large number of people, actually. Possibly 
larger than the number of active participants on this list, maybe even 
by an order or a magnitude (Emacs has more users).

Who would at least like to read-browse-follow some of our discussions 
without fully subscribing to the lists or interjecting into the threads.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 02/09/2023 12:00, Po Lu wrote:
>> So IIUC, you're proposing that a significant amount of time and energy
>> be expended on an endeavor meant to accommodate a very small fraction of
>> people who are loath to subscribe to the list, reluctant to browse the
>> list archives by hand, and desire the contents of a single thread to be
>> delivered to them, without sending mail to each of its participants and
>> thereby disclosing their e-mail addresses.
>
> I imagine that it might be a large number of people,
> actually. Possibly larger than the number of active participants on
> this list, maybe even by an order or a magnitude (Emacs has more
> users).
>
> Who would at least like to read-browse-follow some of our discussions
> without fully subscribing to the lists or interjecting into the
> threads.

And are loath to read the archives off lists.gnu.org or Gmane?  Again,
where are the statistics?

I'm inclined to believe that the number of such individuals is actually
minuscule, since this problem was not mentioned by one of _them_, but by
the two of you, both regulars on this list with a penchant for
conjecturing on behalf of others.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 14:45, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> On 02/09/2023 12:00, Po Lu wrote:
>>> So IIUC, you're proposing that a significant amount of time and energy
>>> be expended on an endeavor meant to accommodate a very small fraction of
>>> people who are loath to subscribe to the list, reluctant to browse the
>>> list archives by hand, and desire the contents of a single thread to be
>>> delivered to them, without sending mail to each of its participants and
>>> thereby disclosing their e-mail addresses.
>>
>> I imagine that it might be a large number of people,
>> actually. Possibly larger than the number of active participants on
>> this list, maybe even by an order or a magnitude (Emacs has more
>> users).
>>
>> Who would at least like to read-browse-follow some of our discussions
>> without fully subscribing to the lists or interjecting into the
>> threads.
> 
> And are loath to read the archives off lists.gnu.org or Gmane?  Again,
> where are the statistics?

How would you collect such statistics?

There is no way to subscribe to lists.gnu.org (but some obviously read 
from there). And don't get me started on Gmane.

> I'm inclined to believe that the number of such individuals is actually
> minuscule, since this problem was not mentioned by one of _them_, but by
> the two of you, both regulars on this list with a penchant for
> conjecturing on behalf of others.

We're talking about people hesitant to insert themselves into 
development conversations, so for proof you're asking for someone to do so?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> We're talking about people hesitant to insert themselves into
> development conversations, so for proof you're asking for someone to
> do so?

Yes?  Where else will any such proof come from?  Perhaps it will be
conjured out of thin air to suit the narrative of whoever wishes to
launch into a lengthy, impassioned harangue over at this Speakers'
Corner?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Alan Mackenzie]

Hello, Po and Dmitry.

On Sat, Sep 02, 2023 at 20:01:25 +0800, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:

> > We're talking about people hesitant to insert themselves into
> > development conversations, so for proof you're asking for someone to
> > do so?

> Yes?  Where else will any such proof come from?  Perhaps it will be
> conjured out of thin air to suit the narrative of whoever wishes to
> launch into a lengthy, impassioned harangue over at this Speakers'
> Corner?

This discussion appears to be heading into not nice exchanges.  Could we
possibly please lower the temperature?

Thanks!

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Alan Mackenzie <acm@muc.de> writes:

>> Yes?  Where else will any such proof come from?  Perhaps it will be
>> conjured out of thin air to suit the narrative of whoever wishes to
>> launch into a lengthy, impassioned harangue over at this Speakers'
>> Corner?
>
> This discussion appears to be heading into not nice exchanges.  Could we
> possibly please lower the temperature?
>
> Thanks!

I apologize, should my reply have come off as hostile.

The point I was attempting to articulate is that hesitation is not
tantamount to refusal; if a bona fide large number of Emacs users are
blighted by this problem, one of them should have steeled himself and
reflected that fact to us by now.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Stefan Kangas]

Po Lu <luangruo@yahoo.com> writes:

> The point I was attempting to articulate is that hesitation is not
> tantamount to refusal; if a bona fide large number of Emacs users are
> blighted by this problem, one of them should have steeled himself and
> reflected that fact to us by now.

Ideally, yes, of course.

The problem is that it doesn't happen as often as we hope.  There is
also a survivor bias to take into account when people do write here.
My conclusion is that, if we want to form an accurate picture of the
sentiments in the wider Emacs community, we have no choice but to pay
attention to what people are saying in other forums too.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Stefan Kangas <stefankangas@gmail.com> writes:

> The problem is that it doesn't happen as often as we hope.  There is
> also a survivor bias to take into account when people do write here.
> My conclusion is that, if we want to form an accurate picture of the
> sentiments in the wider Emacs community, we have no choice but to pay
> attention to what people are saying in other forums too.

That's not the problem here.  Instead, the issue is people are grounding
their recommendations for Emacs on what is at best circumstantial
evidence for the existence of large quanitities of Emacs users
satisfying a litany of very specific criteria, which I recounted earlier
in this godforsaken thread...

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 17:15, Po Lu wrote:
> Stefan Kangas<stefankangas@gmail.com>  writes:
> 
>> The problem is that it doesn't happen as often as we hope.  There is
>> also a survivor bias to take into account when people do write here.
>> My conclusion is that, if we want to form an accurate picture of the
>> sentiments in the wider Emacs community, we have no choice but to pay
>> attention to what people are saying in other forums too.
> That's not the problem here.  Instead, the issue is people are grounding
> their recommendations for Emacs on what is at best circumstantial
> evidence for the existence of large quanitities of Emacs users
> satisfying a litany of very specific criteria, which I recounted earlier
> in this godforsaken thread...

Aside from my own, obviously prolific, imagination, I've been around for 
a while on this and other forums (Emacs-related and otherwise), and saw 
what people say.

Alas, I didn't keep a logbook with easy-to-produce URLs to particular 
exchanges. But a web search could help.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Lynn Winebarger]

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

On Sat, Sep 2, 2023, 7:46 AM Po Lu <luangruo@yahoo.com> wrote:

> Dmitry Gutov <dmitry@gutov.dev> writes:
>
> > On 02/09/2023 12:00, Po Lu wrote:
> >> So IIUC, you're proposing that a significant amount of time and energy
> >> be expended on an endeavor meant to accommodate a very small fraction of
> >> people who are loath to subscribe to the list, reluctant to browse the
> >> list archives by hand, and desire the contents of a single thread to be
> >> delivered to them, without sending mail to each of its participants and
> >> thereby disclosing their e-mail addresses.
> >
> > I imagine that it might be a large number of people,
> > actually. Possibly larger than the number of active participants on
> > this list, maybe even by an order or a magnitude (Emacs has more
> > users).
> >
> > Who would at least like to read-browse-follow some of our discussions
> > without fully subscribing to the lists or interjecting into the
> > threads.
>
> And are loath to read the archives off lists.gnu.org or Gmane?  Again,
> where are the statistics?
>

The search function for the web interface to the emacs-devel archive are
only searchable through some point in 2021.

Lynn

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Lynn Winebarger <owinebar@gmail.com> writes:

> The search function for the web interface to the emacs-devel archive
> are only searchable through some point in 2021.

An actual problem, at last.  The more suitable venue for reporting it
would be the Mailman instance administrators.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Lynn Winebarger <owinebar@gmail.com> writes:
>
>> The search function for the web interface to the emacs-devel archive
>> are only searchable through some point in 2021.
>
> An actual problem, at last.  The more suitable venue for reporting it
> would be the Mailman instance administrators.

Unfortunately, I got no replies upon trying to contact them. This time
and another time I reported a bug (well, previous time I did get a
reply that some patch has been in the works, but no follow-up in more
than one year).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Lynn Winebarger <owinebar@gmail.com>, Dmitry Gutov <dmitry@gutov.dev>,
>  Philip Kaludercic <philipk@posteo.net>, Stefan Kangas
>  <stefankangas@gmail.com>, Danny Freeman <danny@dfreeman.email>, Eli
>  Zaretskii <eliz@gnu.org>, emacs-devel <emacs-devel@gnu.org>, Manuel Uberti
>  <manuel.uberti@inventati.org>
> Date: Fri, 06 Oct 2023 16:32:49 +0000
> 
> Po Lu <luangruo@yahoo.com> writes:
> 
> > Lynn Winebarger <owinebar@gmail.com> writes:
> >
> >> The search function for the web interface to the emacs-devel archive
> >> are only searchable through some point in 2021.
> >
> > An actual problem, at last.  The more suitable venue for reporting it
> > would be the Mailman instance administrators.
> 
> Unfortunately, I got no replies upon trying to contact them. This time
> and another time I reported a bug (well, previous time I did get a
> reply that some patch has been in the works, but no follow-up in more
> than one year).

You can try following up to savannah-hackers-public@gnu.org.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 12:55, Po Lu wrote:
>> I am talking about lurkers - users who do not participate in a thread,
>> but want to get notified about_all_  the new emails.
>>
>> Also, participation will only work for the thread branch that is
>> in-reply to an email send by an unsubscribed user, but not for other
>> emails in the thread.
> Ask the interlocutors to copy you in; it's no insurmountable hassle,
> and a request I have made many times.

So you would feel okay if e.g. 40 lurkers each sent a message into this 
thread asking people to Cc them? And then some of them sent an 
additional message into every subthread that interests them, to ensure 
that they are Cc'd there as well? The lists of addressees tend to alter 
between subthreads, after all.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Ihor Radchenko <yantar92@posteo.net> writes:

> Po Lu <luangruo@yahoo.com> writes:
>
>>> That way, some users may be able to create new threads at least, which
>>> is apparently more comfortable for some users.
>>
>> Do we really want to trouble Emacs development with yet another burden
>> to mind?  Two kinds of threads, in one of which certain subjects or
>> measures are off-limits, really?
>
> What about using mailing list first then?
> For mailing list users, there will be no difference.
> For Disccourse, some topics might remain merged even when mailing list
> thread branched off several discussion threads.

At this point I don't know what the problem is that you are trying to
solve.  If we want to invite more people to participate in discussions
on emacs-devel, but treat those who use Disccourse as lesser citizens.

There comes a point where people have to accept that mailing lists
aren't weird and unusable -- this is not a primarily technical problem.
Some people are afraid of communicating with the mailing list or
reporting bugs because of an image issue.  I have on more than one
occasion heard of people who intentionally avoid communicating with
emacs-devel due to bad experience.  Others fear sending a message out
into the blue and not knowing who will read and respond to what they
said, will they be shouted down or just ignored.  In principle these
issues are shared in common with all other Fora (Discourse, Reddit,
etc.), with perhaps the difference that you can delete and edit a post
after posting it.

What I think the Org project does well is the "This month in Org" line
of posts, that help highlight contributions from newcomers and
familiarise those familiar with a mailing list with the procedures going
on here.  Just in the past few days, I have seen people ask on the
#emacs@libera.chat IRC channel what they think would happen if they were
to submit a patch, and if it would be accepted.  This demonstrates an
uncertainty, that apparently cannot be resolved by actually sending a
patch and seeing what happens.  I have mentioned the idea of a ELPA
newsletter somewhere around here once, but upon reflection, it seems
like a TMIO-like idea should be implemented to the entire
core-development, not just the ELPAs.  Would anyone here be interested
in working on something like that?
 

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Jens Schmidt]

On 2023-08-31  20:17, Philip Kaludercic wrote:

Speaking as a relative newcomer - being active on emacs-devel since
May or so.  I'm not taking side here in any way, just describing my
experience.

> There comes a point where people have to accept that mailing lists
> aren't weird and unusable -- this is not a primarily technical problem.

Opening the MUA to compose a new mail is easy enough.  But then the
problems start: No HTML mail, please, no top-posting (which is corporate
standard), get your MUA to do decent line wrapping, do all these things
so that your mail on emacs-devel looks like the mails of all the others.
Also, you probably would like to use different identities for Emacs and
the rest of your mail, which adds more trouble.

A side note on "Too much traffic?  Just rely on CC!":  I did so when I
posted my first issue on the Org mailing list - and then started
wondering why communication stopped.  Well, somebody replied only to
the list, and it was rather cumbersome to set up a decent reply to join
that thread again.

What I'm trying to say here is: Email might look like it's easy to use,
but in the context of a mailing list it's not necessarily so, even from
the technical side.  These text entry boxes on Github et al. definitely
feel easier and more inviting to use.

> Some people are afraid of communicating with the mailing list or
> reporting bugs because of an image issue.  I have on more than one
> occasion heard of people who intentionally avoid communicating with
> emacs-devel due to bad experience.  Others fear sending a message out
> into the blue and not knowing who will read and respond to what they
> said, will they be shouted down or just ignored.

Exactly.  TBH I still have to assemble courage to post here.  All these
top dogs with their super-dry yet elaborate communication style are
surely, um, intimidating.  Po Lu's mails, to pick one example, are a
constant source of new English vocabulary for me (recent addition:
"brazen").  But at least RMS lets slip in some typos in his mails...

> What I think the Org project does well is the "This month in Org" line
> of posts, that help highlight contributions from newcomers and
> familiarise those familiar with a mailing list with the procedures going
> on here.

Mixing the "help" mailing list with the "devel" mailing list is another
things that makes Org more attractive to users, I guess.  It feels more
democratic.  But then, Org feels more bazaar-like, as a whole, and Emacs
more cathedral-like.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 00:05:25 +0200
> Cc: Po Lu <luangruo@yahoo.com>, Dmitry Gutov <dmitry@gutov.dev>,
>  Stefan Kangas <stefankangas@gmail.com>, Danny Freeman
>  <danny@dfreeman.email>, Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> From: Jens Schmidt <jschmidt4gnu@vodafonemail.de>
> 
> Opening the MUA to compose a new mail is easy enough.  But then the
> problems start: No HTML mail, please, no top-posting (which is corporate
> standard), get your MUA to do decent line wrapping, do all these things
> so that your mail on emacs-devel looks like the mails of all the others.

None of this is true for Emacs mailing lists, not anymore.  HTML is
nowadays supported by all Emacs MUAs, even Rmail (and people use HTML
here all the time), top-posting is used by some people without causing
any "no top-posting" responses, and quite a few people here post
without wrapping lines all the time.

So I believe these negative experiences are either from many years ago
or from other places.

(Not saying using email doesn't require some getting used to, but at
least the above-mentioned factors are not among the obstacles one must
negotiate, not these days.)

> A side note on "Too much traffic?  Just rely on CC!":  I did so when I
> posted my first issue on the Org mailing list - and then started
> wondering why communication stopped.  Well, somebody replied only to
> the list, and it was rather cumbersome to set up a decent reply to join
> that thread again.

_That_ is worth commenting on the list when it happens: ask people to
use Reply All or Wide Reply or whatever it is called.  That's basic
email courtesy.  I get personal replies from people all the time and
always ask them to replay to the list as well when that happens.

> What I'm trying to say here is: Email might look like it's easy to use,
> but in the context of a mailing list it's not necessarily so, even from
> the technical side.  These text entry boxes on Github et al. definitely
> feel easier and more inviting to use.

Yes, but the cost is that you need to proactively to visit each and
every GitHub repository to see whether something new was posted in the
subjects of your interest, and then refresh the page every so often.
The significant advantage of email is that you don't need to poll, you
just subscribe to the few relevant mailing lists, and stuff gets
pushed to you.

> > Some people are afraid of communicating with the mailing list or
> > reporting bugs because of an image issue.  I have on more than one
> > occasion heard of people who intentionally avoid communicating with
> > emacs-devel due to bad experience.  Others fear sending a message out
> > into the blue and not knowing who will read and respond to what they
> > said, will they be shouted down or just ignored.
> 
> Exactly.  TBH I still have to assemble courage to post here.  All these
> top dogs with their super-dry yet elaborate communication style are
> surely, um, intimidating.  Po Lu's mails, to pick one example, are a
> constant source of new English vocabulary for me (recent addition:
> "brazen").

Why do you think those same people will change their style while
talking through GitHub-style "issues"?  They will use the same
language and the same attitudes.  There will be absolutely no
difference in this aspect if and when we start using the GitHub-style
Web interface for discussing issues.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 09:07, Eli Zaretskii wrote:
>> What I'm trying to say here is: Email might look like it's easy to use,
>> but in the context of a mailing list it's not necessarily so, even from
>> the technical side.  These text entry boxes on Github et al. definitely
>> feel easier and more inviting to use.
> Yes, but the cost is that you need to proactively to visit each and
> every GitHub repository to see whether something new was posted in the
> subjects of your interest, and then refresh the page every so often.

Not really. You visit every such repository once, then click "Watch" on 
the whole repo, or "Subscribe" to individual issues, and see 
notifications go into your email inbox whenever something happens (there 
are some granularity settings as well).

Email is still very much a part of most people's work day. Just 
(usually) not at the intensity of "email-driven workflow".

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Not really. You visit every such repository once, then click "Watch" on 
> the whole repo, or "Subscribe" to individual issues, and see 
> notifications go into your email inbox whenever something happens (there 
> are some granularity settings as well).
>
> Email is still very much a part of most people's work day. Just 
> (usually) not at the intensity of "email-driven workflow".

Confirm. I use Github mostly via email, exactly how you described.
The annoying thing is inability to open new issues via email, though
"forge" package allows to do it from Emacs.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, Jens Schmidt
>  <jschmidt4gnu@vodafonemail.de>, philipk@posteo.net, luangruo@yahoo.com,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 09:55:19 +0000
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > Not really. You visit every such repository once, then click "Watch" on 
> > the whole repo, or "Subscribe" to individual issues, and see 
> > notifications go into your email inbox whenever something happens (there 
> > are some granularity settings as well).
> >
> > Email is still very much a part of most people's work day. Just 
> > (usually) not at the intensity of "email-driven workflow".
> 
> Confirm. I use Github mostly via email, exactly how you described.
> The annoying thing is inability to open new issues via email, though
> "forge" package allows to do it from Emacs.

Is that all that annoys you about GitHub's email?  What about the fact
that you get a lot of useless notifications that cannot be selectively
turned off?  What about the fact that most email messages have zero
context, so you have no idea to which part of the discussion they are
responding, unless you keep everything in mind?

Users of GitHub don't write their posts thinking about email
recipients, they evidently assume that everyone is looking at the
discussion via a Web browser.  Therefore, the email notifications are
no more than indications of "something happened", they don't support
intelligent and efficient participation in the discussion without the
need of reading all of it via the browser.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> Confirm. I use Github mostly via email, exactly how you described.
>> The annoying thing is inability to open new issues via email, though
>> "forge" package allows to do it from Emacs.
>
> Is that all that annoys you about GitHub's email?  What about the fact
> that you get a lot of useless notifications that cannot be selectively
> turned off?

I can turn them off selectively in my MUA.
IMHO, this is not any different from how I approach mailing lists - most
of the discussions on ML are not interesting to me and I simply filter
them out. I think Gnus scoring is relevant (although I use different
approach).

> ... What about the fact that most email messages have zero
> context, so you have no idea to which part of the discussion they are
> responding, unless you keep everything in mind?

That's not about Github. That's about discussion conventions. At least
some repositories make use of message quoting in the messages to clarify
what each message is replying to. This tends to happen in more complex
issue discussions with multiple points being discussed.

> Users of GitHub don't write their posts thinking about email
> recipients, they evidently assume that everyone is looking at the
> discussion via a Web browser.  Therefore, the email notifications are
> no more than indications of "something happened", they don't support
> intelligent and efficient participation in the discussion without the
> need of reading all of it via the browser.

I do not find much difference when reading Github discussion from
browser vs. from email. They are equally flat in both cases, sometimes
creating confusion. It is also not too different in IRC, IMHO; and, as
IRC shows, it can be solved, even given the flat structure limitations,
using appropriate community conventions.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> I do not find much difference when reading Github discussion from
> browser vs. from email. They are equally flat in both cases, sometimes
> creating confusion. It is also not too different in IRC, IMHO; and, as
> IRC shows, it can be solved, even given the flat structure limitations,
> using appropriate community conventions.

That's your opinion, which is not shared by the majority of those who
read news or mail.

If I had not quoted your message, or introduced suitable references into
its headers, would you be capable of establishing which message this is
meant to reply to?  Just asking.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> I do not find much difference when reading Github discussion from
>> browser vs. from email. They are equally flat in both cases, sometimes
>> creating confusion. It is also not too different in IRC, IMHO; and, as
>> IRC shows, it can be solved, even given the flat structure limitations,
>> using appropriate community conventions.
>
> That's your opinion, which is not shared by the majority of those who
> read news or mail.
>
> If I had not quoted your message, or introduced suitable references into
> its headers, would you be capable of establishing which message this is
> meant to reply to?  Just asking.

In my message, I did say that quoting is a good practice in Github as
well.

    That's not about Github. That's about discussion conventions. At least
    some repositories make use of message quoting in the messages to clarify
    what each message is replying to. This tends to happen in more complex
    issue discussions with multiple points being discussed.

I am not sure what you are trying to argue about. My statement was
referring to Github discussions that follow good practices.

Github or mailing list - bad messaging practices make things unreadable.
It is not about Github, it is about the community practices.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> In my message, I did say that quoting is a good practice in Github as
> well.
>
>     That's not about Github. That's about discussion conventions. At least
>     some repositories make use of message quoting in the messages to clarify
>     what each message is replying to. This tends to happen in more complex
>     issue discussions with multiple points being discussed.
>
> I am not sure what you are trying to argue about. My statement was
> referring to Github discussions that follow good practices.
>
> Github or mailing list - bad messaging practices make things unreadable.
> It is not about Github, it is about the community practices.

Does Github offer to quote the message you are replying to prior to the
reply being sent?  If not, then I think it is fair game to claim that is
not Github convention, particularly inasmuch as I seldom witness Github
issue threads where quoting is the rule rather than the exception.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Po Lu <luangruo@yahoo.com> writes:

>> Github or mailing list - bad messaging practices make things unreadable.
>> It is not about Github, it is about the community practices.
>
> Does Github offer to quote the message you are replying to prior to the
> reply being sent?

If you intent to reply to a specific message, you click "..." -> "Quote
reply". It will quote the message you are replying to in the reply form.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  dmitry@gutov.dev,
>   jschmidt4gnu@vodafonemail.de,  philipk@posteo.net,
>   stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 20:53:55 +0800
> 
> Does Github offer to quote the message you are replying to prior to the
> reply being sent?

It does -- but not before the reply is sent, but when you are actually
replying.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Po Lu <luangruo@yahoo.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  dmitry@gutov.dev,
>>   jschmidt4gnu@vodafonemail.de,  philipk@posteo.net,
>>   stefankangas@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 01 Sep 2023 20:53:55 +0800
>> 
>> Does Github offer to quote the message you are replying to prior to the
>> reply being sent?
>
> It does -- but not before the reply is sent, but when you are actually
> replying.

By default?  For example, when I send a follow up in Gnus, the message
being followed up to is immediately quoted.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: yantar92@posteo.net,  dmitry@gutov.dev,  jschmidt4gnu@vodafonemail.de,
>   philipk@posteo.net,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 21:27:50 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> From: Po Lu <luangruo@yahoo.com>
> >> Cc: Eli Zaretskii <eliz@gnu.org>,  dmitry@gutov.dev,
> >>   jschmidt4gnu@vodafonemail.de,  philipk@posteo.net,
> >>   stefankangas@gmail.com,  emacs-devel@gnu.org
> >> Date: Fri, 01 Sep 2023 20:53:55 +0800
> >> 
> >> Does Github offer to quote the message you are replying to prior to the
> >> reply being sent?
> >
> > It does -- but not before the reply is sent, but when you are actually
> > replying.
> 
> By default?

No, of course not.

> For example, when I send a follow up in Gnus, the message being
> followed up to is immediately quoted.

That's specific to Gnus, I believe.  In Rmail, one needs to quote by
invoking a special command.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> That's specific to Gnus, I believe.  In Rmail, one needs to quote by
> invoking a special command.

That's strange, however I submit Rmail is the exception rather than the
rule, as even the Yahoo Webmail quotes by default.  Bottom-quotes,
admittedly, but that is still quoting.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 11:34:42 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Confirm. I use Github mostly via email, exactly how you described.
> >> The annoying thing is inability to open new issues via email, though
> >> "forge" package allows to do it from Emacs.
> >
> > Is that all that annoys you about GitHub's email?  What about the fact
> > that you get a lot of useless notifications that cannot be selectively
> > turned off?
> 
> I can turn them off selectively in my MUA.
> IMHO, this is not any different from how I approach mailing lists - most
> of the discussions on ML are not interesting to me and I simply filter
> them out. I think Gnus scoring is relevant (although I use different
> approach).

How is this consistent with complaints about the difficulties of using
a MUA in sophisticated ways?

> > Users of GitHub don't write their posts thinking about email
> > recipients, they evidently assume that everyone is looking at the
> > discussion via a Web browser.  Therefore, the email notifications are
> > no more than indications of "something happened", they don't support
> > intelligent and efficient participation in the discussion without the
> > need of reading all of it via the browser.
> 
> I do not find much difference when reading Github discussion from
> browser vs. from email. They are equally flat in both cases, sometimes
> creating confusion.

Really?  Just look at this discussion: each message clearly shows to
what it responds by quoting that text.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> >> Confirm. I use Github mostly via email, exactly how you described.
>> >> The annoying thing is inability to open new issues via email, though
>> >> "forge" package allows to do it from Emacs.
>> >
>> > Is that all that annoys you about GitHub's email?  What about the fact
>> > that you get a lot of useless notifications that cannot be selectively
>> > turned off?
>> 
>> I can turn them off selectively in my MUA.
>> IMHO, this is not any different from how I approach mailing lists - most
>> of the discussions on ML are not interesting to me and I simply filter
>> them out. I think Gnus scoring is relevant (although I use different
>> approach).
>
> How is this consistent with complaints about the difficulties of using
> a MUA in sophisticated ways?

This branch started from your claim that in order to use GitHub one
needs to check each repo manually:

  > What I'm trying to say here is: Email might look like it's easy to use,
  > but in the context of a mailing list it's not necessarily so, even from
  > the technical side.  These text entry boxes on Github et al. definitely
  > feel easier and more inviting to use.
 Yes, but the cost is that you need to proactively to visit each and
 every GitHub repository to see whether something new was posted in the

But it is not, and email workflow (if one wants to use that kind of
workflow) is still viable.

Yet, I sometimes do use those "text entry boxes" because they really
feel easier in some cases.

>> I do not find much difference when reading Github discussion from
>> browser vs. from email. They are equally flat in both cases, sometimes
>> creating confusion.
>
> Really?  Just look at this discussion: each message clearly shows to
> what it responds by quoting that text.

Check out https://github.com/radian-software/straight.el/issues/1107,
for example. Do you find it confusing?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 13:31:05 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I can turn them off selectively in my MUA.
> >> IMHO, this is not any different from how I approach mailing lists - most
> >> of the discussions on ML are not interesting to me and I simply filter
> >> them out. I think Gnus scoring is relevant (although I use different
> >> approach).
> >
> > How is this consistent with complaints about the difficulties of using
> > a MUA in sophisticated ways?
> 
> This branch started from your claim that in order to use GitHub one
> needs to check each repo manually:
> 
>   > What I'm trying to say here is: Email might look like it's easy to use,
>   > but in the context of a mailing list it's not necessarily so, even from
>   > the technical side.  These text entry boxes on Github et al. definitely
>   > feel easier and more inviting to use.
>  Yes, but the cost is that you need to proactively to visit each and
>  every GitHub repository to see whether something new was posted in the
> 
> But it is not, and email workflow (if one wants to use that kind of
> workflow) is still viable.

Are you actually using that with GitHub repositories?  Because I do,
and my comments about that are based on several years of doing it.
It's extremely tedious, to say the least, and following a discussion
is without visiting the corresponding issue in a Web browser is quite
hard, IME.  So please believe me when I say this is very annoying.

> > Really?  Just look at this discussion: each message clearly shows to
> > what it responds by quoting that text.
> 
> Check out https://github.com/radian-software/straight.el/issues/1107,
> for example. Do you find it confusing?

That's a Web page, not an email inbox.  And yes, I'd find it hard to
read due to very few quotes.  And that discussion is unusual in how
much people quote one another.  But still, take a random message
there:

  https://github.com/radian-software/straight.el/issues/1107#issuecomment-1670440497

It says "Should be fixed by #1109" without saying what is fixed.

Or this post:

  https://github.com/radian-software/straight.el/issues/1107#issuecomment-1668343604

It begins with "The function in question is" and goes on to discussing
code, without saying to which part of the discussion this refers.
Imagine that you receive an email like that -- how do you know what is
this about without re-reading the entire discussion?

Of course, people can refrain from quoting in email messages as well.
But my point is that when people use the Web UI, they can easily
forget that someone might be reading their responses via email,
without seeing the previous posts.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

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

Eli Zaretskii <eliz@gnu.org> writes:

>> But it is not, and email workflow (if one wants to use that kind of
>> workflow) is still viable.
>
> Are you actually using that with GitHub repositories?  Because I do,
> and my comments about that are based on several years of doing it.
> It's extremely tedious, to say the least, and following a discussion
> is without visiting the corresponding issue in a Web browser is quite
> hard, IME.  So please believe me when I say this is very annoying.

I am using GitHub via email since I started using Github, and I am
subscribed to 164 repositories. I do not find this annoying with my
Email setup.

>> > Really?  Just look at this discussion: each message clearly shows to
>> > what it responds by quoting that text.
>> 
>> Check out https://github.com/radian-software/straight.el/issues/1107,
>> for example. Do you find it confusing?
>
> That's a Web page, not an email inbox.  And yes, I'd find it hard to
> read due to very few quotes.

See the attached screenshot of my Emacs with the same discussion open.


[-- Attachment #2: 2023-09-01_17-03.png --]
[-- Type: image/png, Size: 213156 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1966 bytes --]


> ... And that discussion is unusual in how much people quote one another.

I'd like to remind that this discussion is about potential forges for
Emacs. Quoting is just a question of asking people to follow the
conventions.

On Github, some projects you follow may not follow quoting conventions.
Bad for them. Other project follow quoting - they are indeed easier to
read. Not just by email, but in the web UI as well.

I appear to be more lucky than you because the projects I follow are
more bearable with their community style.

> ... But still, take a random message
> there:
>
>   https://github.com/radian-software/straight.el/issues/1107#issuecomment-1670440497
>
> It says "Should be fixed by #1109" without saying what is fixed.

The bug, of course. In debbugs, there is even no reference to the commit
that fixes the bug report, which is IMHO worse. You may recall me
complaining about this in the past.

> Or this post:
>
>   https://github.com/radian-software/straight.el/issues/1107#issuecomment-1668343604
>
> It begins with "The function in question is" and goes on to discussing
> code, without saying to which part of the discussion this refers.
> Imagine that you receive an email like that -- how do you know what is
> this about without re-reading the entire discussion?

That's _my_ message. It was a follow-up to my previous message, because I
forgot to add details. I'd do things the same way in email.

> Of course, people can refrain from quoting in email messages as well.
> But my point is that when people use the Web UI, they can easily
> forget that someone might be reading their responses via email,
> without seeing the previous posts.

We are clearly using different MUA. I can see previous emails easily.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Fri, 01 Sep 2023 14:16:26 +0000
> 
> > Of course, people can refrain from quoting in email messages as well.
> > But my point is that when people use the Web UI, they can easily
> > forget that someone might be reading their responses via email,
> > without seeing the previous posts.
> 
> We are clearly using different MUA. I can see previous emails easily.

So can I, but it is much easier to respond to a message when the
context is in the same message than having to look it up up-thread.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Fri, 01 Sep 2023 17:23:17 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de,
>  philipk@posteo.net, luangruo@yahoo.com,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> 
> > From: Ihor Radchenko <yantar92@posteo.net>
> > Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
> >  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> > Date: Fri, 01 Sep 2023 14:16:26 +0000
> > 
> > > Of course, people can refrain from quoting in email messages as well.
> > > But my point is that when people use the Web UI, they can easily
> > > forget that someone might be reading their responses via email,
> > > without seeing the previous posts.
> > 
> > We are clearly using different MUA. I can see previous emails easily.
> 
> So can I, but it is much easier to respond to a message when the
> context is in the same message than having to look it up up-thread.

And then, of course, I regularly purge my inbox, at which point
looking up previous emails becomes even harder.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> > We are clearly using different MUA. I can see previous emails easily.
>> 
>> So can I, but it is much easier to respond to a message when the
>> context is in the same message than having to look it up up-thread.

I can see your point. Although, I still hold on my point of view that it
is more a question of community guidelines. My email client is not
unique - Gmail and other web UIs for email threads often employ
Github-like view, which would have the same net effect if we consider
that it is the UI that is driving people to avoid quoting.

> And then, of course, I regularly purge my inbox, at which point
> looking up previous emails becomes even harder.

That sounds like your MUA deficiency. Looking up previous emails is
critical, even when the established email etiquette is to quote previous
messages. Sometimes, too much context is lost in the quote.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: dmitry@gutov.dev, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Sat, 02 Sep 2023 08:11:35 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > And then, of course, I regularly purge my inbox, at which point
> > looking up previous emails becomes even harder.
> 
> That sounds like your MUA deficiency. Looking up previous emails is
> critical, even when the established email etiquette is to quote previous
> messages. Sometimes, too much context is lost in the quote.

?? You mean I must keep _all_ the emails I receive forever?

What I do is file (a.k.a. "archive") the emails I want to keep, for
whatever reasons, and delete all the rest.  How is that a
"deficiency", let alone one of my MUA?  My MUA simply does what I tell
it to do.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 11:55, Eli Zaretskii wrote:
>> From: Ihor Radchenko<yantar92@posteo.net>
>> Cc:dmitry@gutov.dev,jschmidt4gnu@vodafonemail.de,philipk@posteo.net,
>>   luangruo@yahoo.com,stefankangas@gmail.com,emacs-devel@gnu.org
>> Date: Sat, 02 Sep 2023 08:11:35 +0000
>>
>> Eli Zaretskii<eliz@gnu.org>  writes:
>>
>>> And then, of course, I regularly purge my inbox, at which point
>>> looking up previous emails becomes even harder.
>> That sounds like your MUA deficiency. Looking up previous emails is
>> critical, even when the established email etiquette is to quote previous
>> messages. Sometimes, too much context is lost in the quote.
> ?? You mean I must keep_all_  the emails I receive forever?
> 
> What I do is file (a.k.a. "archive") the emails I want to keep, for
> whatever reasons, and delete all the rest.  How is that a
> "deficiency", let alone one of my MUA?  My MUA simply does what I tell
> it to do.

Both Debbugs and other newer bug trackers keep the history of older 
comments in their database.

So it's not really an issue of someone being forced to keep email 
archives forever: we can read the older threads on the web too.

The problem you are discussing it the difference between flat and 
threaded email conversations' display. Neither is objectively better 
than the other (only better for particular workflows), so this can 
create a tension.

I wonder how projects like Mesa (that previously used an email-only 
workflow but now use Gitlab too) went about resolving that.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sat, 2 Sep 2023 14:41:42 +0300
> Cc: jschmidt4gnu@vodafonemail.de, philipk@posteo.net, luangruo@yahoo.com,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 02/09/2023 11:55, Eli Zaretskii wrote:
> >>
> >> Eli Zaretskii<eliz@gnu.org>  writes:
> >>
> >>> And then, of course, I regularly purge my inbox, at which point
> >>> looking up previous emails becomes even harder.
> >> That sounds like your MUA deficiency. Looking up previous emails is
> >> critical, even when the established email etiquette is to quote previous
> >> messages. Sometimes, too much context is lost in the quote.
> > ?? You mean I must keep_all_  the emails I receive forever?
> > 
> > What I do is file (a.k.a. "archive") the emails I want to keep, for
> > whatever reasons, and delete all the rest.  How is that a
> > "deficiency", let alone one of my MUA?  My MUA simply does what I tell
> > it to do.
> 
> Both Debbugs and other newer bug trackers keep the history of older 
> comments in their database.
> 
> So it's not really an issue of someone being forced to keep email 
> archives forever: we can read the older threads on the web too.

Yes, of course.  I also do that.  I only said that it is less
convenient than having the context right there, in the message to
which I'm replying, that's all.  And that people who participate in
discussions via a Web browser frequently omit the context since it's
"right there", and they don't think about someone who receives the
discussion via email.

> The problem you are discussing it the difference between flat and 
> threaded email conversations' display.

No, the problem _I_ commented on was the importance of having the
context in the message to which I'm replying, in the form of quoted
excerpts from previous messages.  If I'm required to look it up in
previous messages, it is possible, but less convenient, since I don't
know in which message to look for it, and thus need to look back one
message at a time until I find out.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 15:10, Eli Zaretskii wrote:
>>> ?? You mean I must keep_all_  the emails I receive forever?
>>>
>>> What I do is file (a.k.a. "archive") the emails I want to keep, for
>>> whatever reasons, and delete all the rest.  How is that a
>>> "deficiency", let alone one of my MUA?  My MUA simply does what I tell
>>> it to do.
>> Both Debbugs and other newer bug trackers keep the history of older
>> comments in their database.
>>
>> So it's not really an issue of someone being forced to keep email
>> archives forever: we can read the older threads on the web too.
> Yes, of course.  I also do that.  I only said that it is less
> convenient than having the context right there, in the message to
> which I'm replying, that's all.  And that people who participate in
> discussions via a Web browser frequently omit the context since it's
> "right there", and they don't think about someone who receives the
> discussion via email.

Agree on both counts.

I'd just like to add (or reiterate?) that the "browser users" aren't 
being irrational either: for the "flat" display which is common for both 
the Web browser view and the browser email clients such as 
Gmail/Proton/Fastmail adding too much context can feel like a disservice 
to other parties as well, because if you expect them to use the same 
method when reading (rather than a traditional email client with 
threaded display, which I BTW use myself), it would look and feel 
excessive, both because the reader has to skip over more text to find 
the new message, and because fewer messages fit in one screen.

>> The problem you are discussing it the difference between flat and
>> threaded email conversations' display.
> No, the problem_I_  commented on was the importance of having the
> context in the message to which I'm replying, in the form of quoted
> excerpts from previous messages.  If I'm required to look it up in
> previous messages, it is possible, but less convenient, since I don't
> know in which message to look for it, and thus need to look back one
> message at a time until I find out.

So, where do we go from here?

If the new bug tracker allows users to leave comments using the browser, 
and if enough of them start using that feature, they can naturally 
gravitate to leaving less context in quotes, for both of the reasons 
described above.

I don't remember seeing any popular newer bug trackers which would use 
threaded display for discussions either. Even SourceHut's todo 
discussions are displayed as flat (despite it having no in-browser 
commenting UI so far): https://todo.sr.ht/~emacs/emacs/1

If we put a lot of priority on the community quoting habits staying the 
same, that would seem to mean we should only allow replying in our 
discussions using an email client.

As opposed to, for example, tolerating that style in bug report comments 
(possibly with a convention that we try to keep those threads relatively 
short, either splitting a bug# into several or moving to the mailing 
list, whenever a discussion grows too large).

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Sun, 3 Sep 2023 01:12:31 +0300
> Cc: yantar92@posteo.net, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> >> The problem you are discussing it the difference between flat and
> >> threaded email conversations' display.
> > No, the problem_I_  commented on was the importance of having the
> > context in the message to which I'm replying, in the form of quoted
> > excerpts from previous messages.  If I'm required to look it up in
> > previous messages, it is possible, but less convenient, since I don't
> > know in which message to look for it, and thus need to look back one
> > message at a time until I find out.
> 
> So, where do we go from here?

The same place where we were going before, I hope.  This is just a
side comment that escalated into a significant sub-thread, for no good
reason.  All I wanted to do is to make a minor comment on email
interfaces to Web-based code-review and issue discussions, and convey
some of my personal bad experience with GitHub's emails.  There's no
solution to this except self-discipline of the participants, we just
need to keep this in mind and try not to encourage the undisciplined
parties.

IOW, it's a classic example how a naïve side comment in some
Emacs-related discussion snowballs into a large balloon for no good
reason.  This is a minor side issue, and I don't expect it to be
solved by the issue tracker.  We shouldn't let that cause us to lose
focus.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Ihor Radchenko <yantar92@posteo.net> writes:

> Looking up previous emails is critical, even when the established
> email etiquette is to quote previous messages. Sometimes, too much
> context is lost in the quote.

I can only disagree at this patently untrue statement, at least from my
and Eli's perspectives.

> That sounds like your MUA deficiency.

I feel obliged to comment on something.

Why are some of the posters in this thread so ready, indeed almost
impatient, to pronounce judgement upon others' habits and routines?  Are
Emacs developers really expected to be so altruistic and
self-sacrificing that we must subjugate ourselves to the every whim of
nowhere-near-prospective future developers, or rather what is
furthermore an intangible group of individuals whose existence and
quanity is so far only testified to by anecdotes and inconclusive
circumstantial evidence?

I've only heard people castigate Eli for his purportedly obstructive,
anachronistic, and ``deficient'' practices.  Never has it been proposed,
as is perhaps only natural, that those who wish to involve themselves in
our affairs make some effort to bend themselves into conformity with our
established practices and procedures.  Would you, as a new employee,
demand your workplace realign its customs to match your own habits?  Or
more germanely for this thread, demand your workplace to realign its
customs with your predictions of the habits of future recruits?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 12:19, Po Lu wrote:
> Never has it been proposed,
> as is perhaps only natural, that those who wish to involve themselves in
> our affairs make some effort to bend themselves into conformity with our
> established practices and procedures. Would you, as a new employee,
> demand your workplace realign its customs to match your own habits?

Most of us here already "made some effort" are are already "bent" to 
some degree or other.

Neither are all of the participants "new employees".

> Or
> more germanely for this thread, demand your workplace to realign its
> customs with your predictions of the habits of future recruits?

That can indeed be a good idea to bring up in a corporation of a 
reasonable size (that hasn't yet been bogged down by bureaucracy), 
especially when the hiring market is tough.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> Most of us here already "made some effort" are are already "bent" to
> some degree or other.

So there you have it.  Why is it such a calamity for us to expect the
same of others as well?

> Neither are all of the participants "new employees".

That is not relevant to the point I'm making.

> That can indeed be a good idea to bring up in a corporation of a
> reasonable size (that hasn't yet been bogged down by bureaucracy),
> especially when the hiring market is tough.

It makes you come across as an arrogant person, particularly if these
customs are tried-and-true, and everyone else appears to be abiding by
them to no great detriment.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 02/09/2023 14:53, Po Lu wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> Most of us here already "made some effort" are are already "bent" to
>> some degree or other.
> 
> So there you have it.  Why is it such a calamity for us to expect the
> same of others as well?

There is no calamity. We aren't going to migrate off mailing lists for 
general development discussions anytime soon, perhaps never.

But it's good to have a common understanding of the strong sides of 
different workflows. Some of them we could hopefully adopt at some 
point, some -- won't.

You come off as very confident in one particular workflow, with very 
strong negative opinion toward the alternatives (some of them quite 
popular in our profession). It's hard to avoid leaving commentary.

>> Neither are all of the participants "new employees".
> 
> That is not relevant to the point I'm making.

Seemed very relevant to me.

>> That can indeed be a good idea to bring up in a corporation of a
>> reasonable size (that hasn't yet been bogged down by bureaucracy),
>> especially when the hiring market is tough.
> 
> It makes you come across as an arrogant person, particularly if these
> customs are tried-and-true, and everyone else appears to be abiding by
> them to no great detriment.

Back atcha.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 16:16, Eli Zaretskii wrote:
>> I can turn them off selectively in my MUA.
>> IMHO, this is not any different from how I approach mailing lists - most
>> of the discussions on ML are not interesting to me and I simply filter
>> them out. I think Gnus scoring is relevant (although I use different
>> approach).
> How is this consistent with complaints about the difficulties of using
> a MUA in sophisticated ways?

Very consistent: people who find using a MUA in complex ways difficult 
don't set up additional filtering and usually don't complain about it 
(the default volume of notifications usually seems fine for me, for 
example).

What's odd is when people who know how to set up MUA filters and 
everything produce such complaints.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 16:44:35 +0300
> Cc: jschmidt4gnu@vodafonemail.de, philipk@posteo.net, luangruo@yahoo.com,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 16:16, Eli Zaretskii wrote:
> >> I can turn them off selectively in my MUA.
> >> IMHO, this is not any different from how I approach mailing lists - most
> >> of the discussions on ML are not interesting to me and I simply filter
> >> them out. I think Gnus scoring is relevant (although I use different
> >> approach).
> > How is this consistent with complaints about the difficulties of using
> > a MUA in sophisticated ways?
> 
> Very consistent: people who find using a MUA in complex ways difficult 
> don't set up additional filtering and usually don't complain about it 
> (the default volume of notifications usually seems fine for me, for 
> example).
> 
> What's odd is when people who know how to set up MUA filters and 
> everything produce such complaints.

Such responses make me wish I never participated in this discussion.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 16:51, Eli Zaretskii wrote:
>> Date: Fri, 1 Sep 2023 16:44:35 +0300
>> Cc:jschmidt4gnu@vodafonemail.de,philipk@posteo.net,luangruo@yahoo.com,
>>   stefankangas@gmail.com,emacs-devel@gnu.org
>> From: Dmitry Gutov<dmitry@gutov.dev>
>>
>> On 01/09/2023 16:16, Eli Zaretskii wrote:
>>>> I can turn them off selectively in my MUA.
>>>> IMHO, this is not any different from how I approach mailing lists - most
>>>> of the discussions on ML are not interesting to me and I simply filter
>>>> them out. I think Gnus scoring is relevant (although I use different
>>>> approach).
>>> How is this consistent with complaints about the difficulties of using
>>> a MUA in sophisticated ways?
>> Very consistent: people who find using a MUA in complex ways difficult
>> don't set up additional filtering and usually don't complain about it
>> (the default volume of notifications usually seems fine for me, for
>> example).
>>
>> What's odd is when people who know how to set up MUA filters and
>> everything produce such complaints.
> Such responses make me wish I never participated in this discussion.

No need to be rude.

You judged some other people's workflows by your own standards and got 
an answer that when participating in those workflows it's entirely 
feasible to improve them to your liking using the tools you are 
certainly familiar with (and not just you, but every old-timer with a 
customizable MUA). I got that answer every time when pointing difficulty 
managing the email-driven workflow here (I only have a 
moderately-customizable MUA, however).

And that those other people (ones with web-based workflows) are largely 
unbothered by their experience, possibly due to not knowing better 
alternatives (but that very debatable). But they can also customize 
their notification a little if they're using Github, and a lot, if 
they're using Gitlab.

There is a dedicated section in Github's docs about filtering on the 
level of MUA: 
https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#filtering-email-notifications, 
though for some reasons they don't mention the available headers 
X-Github-Reason and X-Github-Sender.

What is missing here?

Re. using Gitlab I already said I'd try to look into settings for 
filtering emails, if we ever reach the stage of experimenting with it 
when it becomes relevant. There existing controls listed are here, and 
there are a lot (perhaps they extended that feature over the several 
years since we last looked): 
https://docs.gitlab.com/ee/user/profile/notifications.html#notification-events-on-issues-merge-requests-and-epics

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 17:21:50 +0300
> Cc: yantar92@posteo.net, jschmidt4gnu@vodafonemail.de, philipk@posteo.net,
>  luangruo@yahoo.com, stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 16:51, Eli Zaretskii wrote:
> >> Date: Fri, 1 Sep 2023 16:44:35 +0300
> >> Cc:jschmidt4gnu@vodafonemail.de,philipk@posteo.net,luangruo@yahoo.com,
> >>   stefankangas@gmail.com,emacs-devel@gnu.org
> >> From: Dmitry Gutov<dmitry@gutov.dev>
> >>
> >> On 01/09/2023 16:16, Eli Zaretskii wrote:
> >>>> I can turn them off selectively in my MUA.
> >>>> IMHO, this is not any different from how I approach mailing lists - most
> >>>> of the discussions on ML are not interesting to me and I simply filter
> >>>> them out. I think Gnus scoring is relevant (although I use different
> >>>> approach).
> >>> How is this consistent with complaints about the difficulties of using
> >>> a MUA in sophisticated ways?
> >> Very consistent: people who find using a MUA in complex ways difficult
> >> don't set up additional filtering and usually don't complain about it
> >> (the default volume of notifications usually seems fine for me, for
> >> example).
> >>
> >> What's odd is when people who know how to set up MUA filters and
> >> everything produce such complaints.
> > Such responses make me wish I never participated in this discussion.
> 
> No need to be rude.

Yes, of course: everyone else is rude, just not yourself.  Even when
you are.

> You judged some other people's workflows by your own standards

I haven't judged anyone.  I provided what I thought was a useful
feedback about some workflows.  If that's not useful, feel free to
ignore.  Refraining from response is orders of magnitude more polite
than posting innuendo about my alleged inability to use my MUA.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 17:28, Eli Zaretskii wrote:
> Refraining from response is orders of magnitude more polite
> than posting innuendo about my alleged inability to use my MUA.

No inability was implied.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

> Date: Fri, 1 Sep 2023 12:49:48 +0300
> Cc: philipk@posteo.net, yantar92@posteo.net, luangruo@yahoo.com,
>  stefankangas@gmail.com, emacs-devel@gnu.org
> From: Dmitry Gutov <dmitry@gutov.dev>
> 
> On 01/09/2023 09:07, Eli Zaretskii wrote:
> >> What I'm trying to say here is: Email might look like it's easy to use,
> >> but in the context of a mailing list it's not necessarily so, even from
> >> the technical side.  These text entry boxes on Github et al. definitely
> >> feel easier and more inviting to use.
> > Yes, but the cost is that you need to proactively to visit each and
> > every GitHub repository to see whether something new was posted in the
> > subjects of your interest, and then refresh the page every so often.
> 
> Not really. You visit every such repository once, then click "Watch" on 
> the whole repo, or "Subscribe" to individual issues, and see 
> notifications go into your email inbox whenever something happens (there 
> are some granularity settings as well).

I know.  But the "Watch" feature IME produces a lot of noise, and
there's no way AFAIK to be selective there.  For example, I don't want
to see the "closed" and "merged" notifications, not machine-generated
links to commits, I only want to see discussions posted by humans.

In any case, this feature of GitHub is not relevant, because in this
sub-thread I was comparing the email-based workflow with the GitHub
one.  That GitHub has a feature to deliver email is not relevant since
the message to which I responded in effect said "I don't want to use
email".

> Email is still very much a part of most people's work day.

Not according to the OP, no.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 01/09/2023 14:07, Eli Zaretskii wrote:
> In any case, this feature of GitHub is not relevant, because in this
> sub-thread I was comparing the email-based workflow with the GitHub
> one.  That GitHub has a feature to deliver email is not relevant since
> the message to which I responded in effect said "I don't want to use
> email".
> 
>> Email is still very much a part of most people's work day.
> Not according to the OP, no.

I'm pretty sure OP's message was just missing those extra details. But 
they are welcome to clarify.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

Jens Schmidt <jschmidt4gnu@vodafonemail.de> writes:

>> Some people are afraid of communicating with the mailing list or
>> reporting bugs because of an image issue.  I have on more than one
>> occasion heard of people who intentionally avoid communicating with
>> emacs-devel due to bad experience.  Others fear sending a message out
>> into the blue and not knowing who will read and respond to what they
>> said, will they be shouted down or just ignored.
>
> Exactly.  TBH I still have to assemble courage to post here.  All these
> top dogs with their super-dry yet elaborate communication style are
> surely, um, intimidating.  Po Lu's mails, to pick one example, are a
> constant source of new English vocabulary for me (recent addition:
> "brazen").  But at least RMS lets slip in some typos in his mails...

I think everyone makes mistakes sometimes when posting here.  I can't
count the number of times when I added the wrong patch, forgot to CC
everyone, responded to the wrong message, misunderstood someones point
entirely, typos .... and nobody really cares.  If I see someone make a
mistake, I just gloss over it (unless it affects me or I can help in
some way).

The fear you describe is relatable, my first message to the Emacs
developers was written just over 4½ years ago, and I have only been
contributing more regularly for about 3 years.  That being said, I
cannot explain the fact that I don't worry about every message, other
than if you send normal and kind messages, you get normal and kind
responses.

>> What I think the Org project does well is the "This month in Org" line
>> of posts, that help highlight contributions from newcomers and
>> familiarise those familiar with a mailing list with the procedures going
>> on here.
>
> Mixing the "help" mailing list with the "devel" mailing list is another
> things that makes Org more attractive to users, I guess.  It feels more
> democratic.  But then, Org feels more bazaar-like, as a whole, and Emacs
> more cathedral-like.

Democratic is a weird word to use here, IMO.  Either way, I think it
makes sense to split between development-talk and regular help.  There
is a lot of weird noise on help-gnu-emacs@ that really don't have
to make reading emacs-devel@ any more difficult.

RE: [External] : Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Drew Adams]

> I think it makes sense to split between
> development-talk and regular help.

Agreed.

And announcements (info-gnu-emacs@gnu.org).
And source code (gnu-emacs-sources@gnu.org).
And humanities (emacs-humanities@gnu.org).
And sundry (emacs-tangents@gnu.org).

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Richard Stallman]

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

The problems you've reported with emacs-devel seem significant.
Thanks for describing them clearly.

  >   These text entry boxes on Github et al. definitely
  > feel easier and more inviting to use.

Github is a non-starter for the GNU Project for moral reasons: it
requires users to run nonfree JavaScript.  We can't direct users
there.

Another problem is that one can't use Emacs editing for editing text
entry in IceCat, which is the browser I can trust to protect me from
JavaScript malware.

The email interface must continue to work.  But I don't see anything
wrong in offering a web interface _also_, provided it is only an
alternate, not the recommended way.

But we shouldn't neglect the email problems you've repoeted.

I think we can fix them, at least some of them, in Emacs's mail
composition modes.  First, we could give them a list of the mailing
lists we want them to handle specially -- you could put in the lists
you use.  That way you won't have to explicitly request special handling
for them.

Then we could automaticall add or enable various features, such as
auto-fill, when sending to those lists.

We could have a way of recognizing that certain CC addresses are on
the list so they can be dropped automatically from the CC of the
reply, while retaining others.

Maybe we could modify the list handler server software to do some of
this automatically.  Perhaps to indicate in some extension header
which cc'd addresses are not on the mailing list, and the mail mode
would put those by default into the CC header of the reply.

I think we could eliminate the inconveniences of email this way.

  > Exactly.  TBH I still have to assemble courage to post here.  All these
  > top dogs with their super-dry yet elaborate communication style are
  > surely, um, intimidating.

That is not a good thing.  Maybe we can continue on the path of the Kind
Communication Guidelines (https://gnu.org/philosophy/kind-communication.html)
to make emacs-devel less intimidating.

Would you like to start accumulating a list of examples that do,
or did in the past, feel intimidating to you?  We could learn ommething
from that.

First step, we could set up a web page that explais the conventions
in a clear and kind way, so that when we ask newcomers to follow them,
we won't make per feel bad.

But I don't deserve credit for my typos.  I must admit that they are
all unintentional ;-{.



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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ahmed Khanzada via Emacs development discussions.]

I am a 34 year old hacker that grew up with web browsers and GitHub. I
contribute to a number of GPL packages on GitHub. Only recently I have
managed to switch over to a comfortable mailing list workflow. Some
thoughts on the learning curve involved there:

- Younger users are used to the mouse-centric UI conventions of web
  apps. Once I was mentoring a young student, and they decided to use
  terminal vim because that's what the cool kids do, and they then asked
  me why their mouse wasn't working.

- A new mailing list user might try to use a webmail client, which does
  not thread appropriately, and which primarily deals with HTML
  email. Using a client that does not thread properly makes using
  mailing lists impossible.

- A new mailing list user might try to use a corporate email server,
  which fights against their use of traditional open protocols like
  IMAP. They end up fighting their corporate mail provider for days.

Ultimately, what made mailing lists working for me was the following:

- Setting up my own email server on OpenBSD so that I could use my email 
  account in whatever matter I chose.

- Setting up OfflineIMAP which would grab email from my OpenBSD server,
  and convert it to the Maildir format locally.

- Tagging Maildir email with notmuch so everything was filtered into
  well-sized readable folders.

- Using Gnus which displays threads wonderfully, and lets you run
  through email with a few keystrokes.

After all that, I can now see the superiority of a mailing list workflow
over the clumsy PR workflows of the forges, although I miss the "social
network" aspect of GitHub that lets you follow your favorite developers
and see what they are up to.

I have been playing with the idea that I should make a simple program
that will:

- Register you with an email service that has a long track record of
  being friendly

- Ask what mailing lists you are interested in signing up for and
  registering you with them

- Asking some remaining questions so that it can setup OfflineIMAP,
  Notmuch, Emacs, and Gnus appropriately for you

I think rather than creating a web frontend that none of us will use,
maybe we should make our advanced Emacs+Gnus workflows more
accessible. But that might also be exactly the wrong move. :)

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Jens Schmidt]

On 2023-09-02  03:51, 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. ]]]
> 
> The problems you've reported with emacs-devel seem significant.
> Thanks for describing them clearly.
> 
>   >   These text entry boxes on Github et al. definitely
>   > feel easier and more inviting to use.
> 
> Github is a non-starter for the GNU Project for moral reasons: it
> requires users to run nonfree JavaScript.  We can't direct users
> there.

Github was just one example of these forges, on some other thread
a self-hosted Gitlab has been mentioned.  SourceHut advertises
its JavaScript-freeness, and while they currently "only" have a
mail-based workflow, some web front-end seems to be in their
pipeline.

> But we shouldn't neglect the email problems you've repoeted.

Most of the problems I described stem from the fact that I have
been determined to use my readily set-up Thunderbird as email
client also for Emacs development mail, and not one of the Emacs
alternatives.  But I feel this is really an uphill battle and I
will probably migrate to Gnus at least for my Emacs development
mail.

> I think we could eliminate the inconveniences of email this way.

If there are any ... I could try keeping track of my experiences
when I change to Gnus.

>   > Exactly.  TBH I still have to assemble courage to post here.  All these
>   > top dogs with their super-dry yet elaborate communication style are
>   > surely, um, intimidating.
> 
> That is not a good thing.  Maybe we can continue on the path of the Kind
> Communication Guidelines (https://gnu.org/philosophy/kind-communication.html)
> to make emacs-devel less intimidating.
> 
> Would you like to start accumulating a list of examples that do,
> or did in the past, feel intimidating to you?  We could learn ommething
> from that.

There aren't any particular examples, really.  Let's try a comparison
instead, slightly exaggerating:

- On help-gnu-emacs/gmane.emacs.help I feel like on a market place,
  chatting to others;
- When opening a bug on bug-gnu-emacs, I feel like at the doctor's;
- But on emacs-devel I feel like in a temple with the priests scrutinely
  examining me and weighing my words, while the crowd watches.

> First step, we could set up a web page that explais the conventions
> in a clear and kind way, so that when we ask newcomers to follow them,
> we won't make per feel bad.

Exactly.  I'm not sure about the relationship between Emacs development
and the Emacs Wiki, but there you have at least something already that
could be extended: https://www.emacswiki.org/emacs/EmacsMailingLists.

And I concur with Ahmed in that other reply to your mail: Emacs
development could need some more "social network" aspects, IMO.  Not
only to follow a particular developer, but also to know her or him a
bit better.  That would take out that priest-in-a-temple feeling a
bit, I guess.  Drew Adams, though not an Emacs maintainer, has a nice
page on the EmacsWiki, for example:
https://www.emacswiki.org/emacs/DrewAdams.

emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > Exactly.  TBH I still have to assemble courage to post here.  All these
>   > top dogs with their super-dry yet elaborate communication style are
>   > surely, um, intimidating.
>
> That is not a good thing.  Maybe we can continue on the path of the Kind
> Communication Guidelines (https://gnu.org/philosophy/kind-communication.html)
> to make emacs-devel less intimidating.
>
> Would you like to start accumulating a list of examples that do,
> or did in the past, feel intimidating to you?  We could learn ommething
> from that.

I can share some subjective experience:

Sometimes, the replies to proposals/reports have a tone that is
seemingly rejecting compromises. There are two aspects to this
impression:

1. Maintainers often say "no" to certain things (like code refactoring
   that does not lead to any clear improvement) because they know from
   their extensive experience that some ideas are "non-starters".
   However, they do not elaborate much why one or another thing is not
   acceptable.

   Not elaborating is actually perfectly understandable - it would be
   annoying to repeat the same thing many times and would also waste the
   maintainer's valuable time that could be spent for something more
   productive.

   Though some kind of FAQ might be useful to lead people to more
   detailed explanations. Pointing "this has been discussed many times
   in the past" feels intimidating as it is not always clear how to find
   the previous conclusions of "discussed many times" in the large
   volume of emacs-devel archives.

2. The previous point feels even worse when there is miscommunication
   and the rigid "no" (or other assertions) is coming from
   misunderstanding each other.

   For example, https://yhetil.org/emacs-devel/83czffzo73.fsf@gnu.org/
   thread was quite hard to manage, partially because of such
   mis-communication. It took a few, sometimes heated, exchanges until
   we figured out the misunderstanding in
   https://yhetil.org/emacs-devel/87v8szrfz6.fsf@localhost/

3. Sometimes, replies to certain feature request feel like a show
   stopper not because the feature itself is not acceptable, but because
   the specific implementation is not deemed good. A recent example is
   https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65451#26, where I
   somehow _felt_ like my proposal cannot be accepted at all. Which was
   not true, as an alternative implementation of the same feature was
   more as rigidly rejected. Maybe it is just me, but it was quite
   emotionally difficult to keep the discussion going and constructive.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Jens Schmidt <jschmidt4gnu@vodafonemail.de>, emacs-devel@gnu.org,
>  manuel.uberti@inventati.org
> Date: Sun, 03 Sep 2023 08:32:16 +0000
> 
> Richard Stallman <rms@gnu.org> writes:
> 
> >   > Exactly.  TBH I still have to assemble courage to post here.  All these
> >   > top dogs with their super-dry yet elaborate communication style are
> >   > surely, um, intimidating.
> >
> > That is not a good thing.  Maybe we can continue on the path of the Kind
> > Communication Guidelines (https://gnu.org/philosophy/kind-communication.html)
> > to make emacs-devel less intimidating.
> >
> > Would you like to start accumulating a list of examples that do,
> > or did in the past, feel intimidating to you?  We could learn ommething
> > from that.
> 
> I can share some subjective experience:

Thanks, but I think this kind of discussion should be moved to
emacs-tangents.  It is not really relevant to Emacs development, and I
find discussing people's styles of posting here not appropriate for
this list, unless the style is completely unacceptable (in which case
we usually immediately ask the poster on the list to drop the
attitude, and no discussions should be necessary anyway).

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Richard Stallman]

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

  > Thanks, but I think this kind of discussion should be moved to
  > emacs-tangents.

I agree -- I will do that.

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

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Richard Stallman]

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

  > 1. Maintainers often say "no" to certain things (like code refactoring
  >    that does not lead to any clear improvement) because they know from
  >    their extensive experience that some ideas are "non-starters".
  >    However, they do not elaborate much why one or another thing is not
  >    acceptable.

  >    Not elaborating is actually perfectly understandable - it would be
  >    annoying to repeat the same thing many times and would also waste the
  >    maintainer's valuable time that could be spent for something more
  >    productive.

I think I can understand why this feels painful -- but what concretely could
we ask the maintainers to do which would be better overall?

When you say "maintainers", do you mean the Emacs maintainers
(currently Eli, Stefan and I)?  Or does it mean the people who develop
whichever file you're proposing a change to?

  > 3. Sometimes, replies to certain feature request feel like a show
  >    stopper not because the feature itself is not acceptable, but because
  >    the specific implementation is not deemed good.

Would it be halp if the people who respond make an effort to
distinguish between their comment about the the behavior tat could be
changed, and their comments about the specific method of implementing
that change?  We might be able to get better at that, since I expect
everyone will agree it is good to do that if one can.

I'll reply to #2 privately.

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

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Emanuel Berg]

Richard Stallman wrote:

>> 1. Maintainers often say "no" to certain things (like code
>>    refactoring that does not lead to any clear improvement)
>>    because they know from their extensive experience that
>>    some ideas are "non-starters". However, they do not
>>    elaborate much why one or another thing is
>>    not acceptable.
>>
>>    Not elaborating is actually perfectly understandable -
>>    it would be annoying to repeat the same thing many times
>>    and would also waste the maintainer's valuable time that
>>    could be spent for something more productive.
>
> I think I can understand why this feels painful -- but what
> concretely could we ask the maintainers to do which would be
> better overall?

gnu.emacs.devel FAQ!

I. BAD IDEAS AND WHY THEY ARE BAD

1. Idea: Drop Elisp, instead use SBCL for Emacs

Argument:

  SBCL is faster and has parallelism for modern multicores.
  We would be able to use everything the SBCL community has
  developed. For the supposed Lisp editor, we would have the
  most relentless and cruel Lisp on Earth, instead of the
  half-goofy Elisp which some people think is just used to set
  a bunch of options.

Why it is STILL a bad idea:

  Elisp is now also very fast with native-compilation and it
  is likely it will get even faster as that technology is
  quite new, and is being actively developed. Elisp is also
  much more portable than SBCL. The SBCL speed advantage and
  parallelism relies on specific constructs the programmer has
  to add explicitly in the code. So all our Joe Hacker's Elisp
  wouldn't benefit from that in its current state. Not to
  mention all our Joe Hacker's Elisp would have to be
  re-written and adopted into SBCL. To re-write Emacs so that
  its Lisp would be SBCL and not Elisp would be an insanely
  big undertaking with a very unclear image what the result
  would be. Remember, one shouldn't burn down the house to
  kill the rats. Also, there are Emacs-like editors already
  that are based on CL. So we are not doing it, goddammit!

-- 
underground experts united
https://dataswamp.org/~incal

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Samuel Wales]

i thought nobody serious about emacs suggests rewriting existing elisp
but rather rebasing it?

On 9/4/23, Emanuel Berg <incal@dataswamp.org> wrote:
> Richard Stallman wrote:
>
>>> 1. Maintainers often say "no" to certain things (like code
>>>    refactoring that does not lead to any clear improvement)
>>>    because they know from their extensive experience that
>>>    some ideas are "non-starters". However, they do not
>>>    elaborate much why one or another thing is
>>>    not acceptable.
>>>
>>>    Not elaborating is actually perfectly understandable -
>>>    it would be annoying to repeat the same thing many times
>>>    and would also waste the maintainer's valuable time that
>>>    could be spent for something more productive.
>>
>> I think I can understand why this feels painful -- but what
>> concretely could we ask the maintainers to do which would be
>> better overall?
>
> gnu.emacs.devel FAQ!
>
> I. BAD IDEAS AND WHY THEY ARE BAD
>
> 1. Idea: Drop Elisp, instead use SBCL for Emacs
>
> Argument:
>
>   SBCL is faster and has parallelism for modern multicores.
>   We would be able to use everything the SBCL community has
>   developed. For the supposed Lisp editor, we would have the
>   most relentless and cruel Lisp on Earth, instead of the
>   half-goofy Elisp which some people think is just used to set
>   a bunch of options.
>
> Why it is STILL a bad idea:
>
>   Elisp is now also very fast with native-compilation and it
>   is likely it will get even faster as that technology is
>   quite new, and is being actively developed. Elisp is also
>   much more portable than SBCL. The SBCL speed advantage and
>   parallelism relies on specific constructs the programmer has
>   to add explicitly in the code. So all our Joe Hacker's Elisp
>   wouldn't benefit from that in its current state. Not to
>   mention all our Joe Hacker's Elisp would have to be
>   re-written and adopted into SBCL. To re-write Emacs so that
>   its Lisp would be SBCL and not Elisp would be an insanely
>   big undertaking with a very unclear image what the result
>   would be. Remember, one shouldn't burn down the house to
>   kill the rats. Also, there are Emacs-like editors already
>   that are based on CL. So we are not doing it, goddammit!
>
> --
> underground experts united
> https://dataswamp.org/~incal
>
>
>


-- 
The Kafka Pandemic

A blog about science, health, human rights, and misopathy:
https://thekafkapandemic.blogspot.com

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Emanuel Berg]

Samuel Wales wrote:

> i thought nobody serious about emacs suggests rewriting
> existing elisp but rather rebasing it?

The FAQ fails to address that question, but you can always add
it yourself.

-- 
underground experts united
https://dataswamp.org/~incal

Re: emacs-devel/debbugs communication (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Ihor Radchenko]

Richard Stallman <rms@gnu.org> writes:

>   > 1. Maintainers often say "no" to certain things (like code refactoring
>   >    that does not lead to any clear improvement) because they know from
>   >    their extensive experience that some ideas are "non-starters".
>   >    However, they do not elaborate much why one or another thing is not
>   >    acceptable.
>
>   >    Not elaborating is actually perfectly understandable - it would be
>   >    annoying to repeat the same thing many times and would also waste the
>   >    maintainer's valuable time that could be spent for something more
>   >    productive.
>
> I think I can understand why this feels painful -- but what concretely could
> we ask the maintainers to do which would be better overall?

I have two possibilities in mind:

1. For the common questions/misconceptions that keep appearing, there
   might be a dedicated FAQ answer that can be quickly linked to.
   For example, in Org mode we often point new contributors who did not
   follow our patch conventions to
   https://orgmode.org/worg/org-contribute.html#first-patch or quickly
   link to an explanation why ancient Emacs versions are not supported:
   https://orgmode.org/worg/org-maintenance.html#emacs-compatibility or
   explain our general maintenance principles in
   https://bzg.fr/en/the-software-maintainers-pledge/

2. Do not treat all the users the same:

   - The users submitting bug report/email the very first time (or
     generally having just a handful of emails on the list) may be
     greeted with more welcoming style, with detailed explanations.
     Especially if such a user is proposing something that has to be
     rejected.
     
   - Users that do not seem to be familiar with specialized Elisp or
     Emacs terminology may require different reply style compared to
     devs, especially Elisp devs.

> When you say "maintainers", do you mean the Emacs maintainers
> (currently Eli, Stefan and I)?  Or does it mean the people who develop
> whichever file you're proposing a change to?

I meant more than you three - whoever is replying to a
proposal/suggestion with very confident tone implying good knowledge of
the topic. Such people are usually Emacs maintainers, built-in Elisp library
maintainers, and sometimes just random people who happen to sound
knowledgeable. (I know that such random people often have nothing to do
with Emacs team, but there is no easy way to distinguish them from real
maintainers when reading long threads; for example see
https://yhetil.org/emacs-devel/E1qXkGM-0005IS-PJ@fencepost.gnu.org/)

>   > 3. Sometimes, replies to certain feature request feel like a show
>   >    stopper not because the feature itself is not acceptable, but because
>   >    the specific implementation is not deemed good.
>
> Would it be halp if the people who respond make an effort to
> distinguish between their comment about the the behavior tat could be
> changed, and their comments about the specific method of implementing
> that change?  We might be able to get better at that, since I expect
> everyone will agree it is good to do that if one can.

It would indeed help.

Another possibility is following the style often used in technical
conferences: (1) Always acknowledge what is good about
presentation/idea; (2) Go ahead with questions/critique.
That first part is often very trivial - it will not directly lead to
improving the presented work/idea, but it really helps to not sound like
"I only have questions/critique about your work. Nothing else, nothing
good.".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Monthy emacs-devel digest, similar to "This month in Org" (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Ihor Radchenko]

Philip Kaludercic <philipk@posteo.net> writes:

> There comes a point where people have to accept that mailing lists
> What I think the Org project does well is the "This month in Org" line
> of posts, that help highlight contributions from newcomers and
> familiarise those familiar with a mailing list with the procedures going
> on here.

This is actually quite an effort. AFAIK, the author had difficulties
allocating time to write more posts for TMiO.

Also, for reference, we are talking about
https://blog.tecosaur.com/tmio/2022-05-31-folding.html

> ... I have mentioned the idea of a ELPA
> newsletter somewhere around here once, but upon reflection, it seems
> like a TMIO-like idea should be implemented to the entire
> core-development, not just the ELPAs.  Would anyone here be interested
> in working on something like that?

A somewhat relevant effort is by Sacha Chua:
https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/

It is less detailed (just an outline), but I find it pretty useful.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: TMiO (was: "Re: Monthy emacs-devel digest, similar to "This month in Org")

[Timothy]

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

Hi Ihor,

> This is actually quite an effort. AFAIK, the author had difficulties
> allocating time to write more posts for TMiO.
>
> Also, for reference, we are talking about
> <https://blog.tecosaur.com/tmio/2022-05-31-folding.html>

Each post took several hours to do, despite how short they were. The major
difficulty is in making sure that I’ve read as much as I can in that month, and
trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
people out) which requires looking at the ML + git log since the last TMiO.

For what it’s worth, once the org-latex-preview branch gets merged, I plan on
doing another TMiO with the disclaimer that I may have missed out a bunch of
things in that edition.

Something else we could do is have some sort of “community draft” as is now
being done on the Julia discourse, which could help reduce the individual
workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>).

All the best,
Timothy

-- 
Timothy (‘tecosaur’/‘TEC’), Org mode contributor.
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/tec>.

Re: Monthy emacs-devel digest, similar to "This month in Org" (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[John Yates]

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

Writing new content (à la Linux Weekly News) is a massive effort.  I would
expect any attempt at such a product to peter out in short order.

A big, big +1 for Sacha's weekly Emacs News.  I find it just the right
level of detail.  It directs one to Emacs mail threads, upcoming events and
get togethers, blogs and Reddit posts, Youtube videos, etc.  And, IIRC, she
is even set up to accept contributions from others.  Let's support her.

/john


On Fri, Sep 1, 2023 at 6:14 AM Ihor Radchenko <yantar92@posteo.net> wrote:

> Philip Kaludercic <philipk@posteo.net> writes:
>
> > There comes a point where people have to accept that mailing lists
> > What I think the Org project does well is the "This month in Org" line
> > of posts, that help highlight contributions from newcomers and
> > familiarise those familiar with a mailing list with the procedures going
> > on here.
>
> This is actually quite an effort. AFAIK, the author had difficulties
> allocating time to write more posts for TMiO.
>
> Also, for reference, we are talking about
> https://blog.tecosaur.com/tmio/2022-05-31-folding.html
>
> > ... I have mentioned the idea of a ELPA
> > newsletter somewhere around here once, but upon reflection, it seems
> > like a TMIO-like idea should be implemented to the entire
> > core-development, not just the ELPAs.  Would anyone here be interested
> > in working on something like that?
>
> A somewhat relevant effort is by Sacha Chua:
> https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/
>
> It is less detailed (just an outline), but I find it pretty useful.
>
> --
> Ihor Radchenko // yantar92,
> Org mode contributor,
> Learn more about Org mode at <https://orgmode.org/>.
> Support Org development at <https://liberapay.com/org-mode>,
> or support my work at <https://liberapay.com/yantar92>
>
>

-- 
John Yates
505 Tremont St, #803
Boston, MA 02116

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

Re: Monthy emacs-devel digest, similar to "This month in Org" (was: New Package for NonGNU-ELPA: clojure-ts-mode)

[Sacha Chua]

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

Hi John, all!

You can Bcc or Cc me and I can look up the web link for the message/thread
so that I can include it in Emacs News. Bonus if you can include a one-line
summary if it's not obvious from the subject line or the body. :) For
example, Corwin recently Bcced me on the clang off tip, so I was able to
include that.

Andrés Ramírez has been sending me links to emacs-devel threads of
interest, which is much appreciated as y'all talk about so many interesting
things that I can't keep up on my phone given my limited computer time
(hence the top-posting on this email, sorry sorry sorry). I usually jump
around in the threads to see what's up or which message is good to link to.
Sometimes it's a little hard for me to summarize things in a line or two.

For emacs-devel, we've mostly been keeping an eye out for:
- help wanted
- braindumps on how parts of Emacs work or weird things people might need
to know about different platforms
- progress on various parts (tree-sitter modes, etc.)
- proposals that could use a variety of perspectives, etc.
- the occasional glimpse of the vast breadth and depth in Emacs (supporting
obsolete systems, odd edge cases, etc.)
- very busy or long threads

I tend to skip threads that are very specific or are quickly resolved, and
I try to not embarrass people when they're having a hard time getting along
in public.

Emacs News takes me about an hour to do all in all, which is mostly
grouping/deduplicating and categorizing links, and skimming videos or
captions when available. (I try to not link to lots of those lower-effort
StackOverflow readalouds...) Could be something worth replicating on a
weekly or monthly scale for someone more immersed in emacs-devel.

Sacha

On Fri, Sept 1, 2023, 09:20 John Yates <john@yates-sheets.org> wrote:

> Writing new content (à la Linux Weekly News) is a massive effort.  I
> would expect any attempt at such a product to peter out in short order.
>
> A big, big +1 for Sacha's weekly Emacs News.  I find it just the right
> level of detail.  It directs one to Emacs mail threads, upcoming events and
> get togethers, blogs and Reddit posts, Youtube videos, etc.  And, IIRC, she
> is even set up to accept contributions from others.  Let's support her.
>
> /john
>

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

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Philip Kaludercic]

Ihor Radchenko <yantar92@posteo.net> writes:

> Philip Kaludercic <philipk@posteo.net> writes:
>
>> There comes a point where people have to accept that mailing lists
>> What I think the Org project does well is the "This month in Org" line
>> of posts, that help highlight contributions from newcomers and
>> familiarise those familiar with a mailing list with the procedures going
>> on here.
>
> This is actually quite an effort. AFAIK, the author had difficulties
> allocating time to write more posts for TMiO.
>
> Also, for reference, we are talking about
> https://blog.tecosaur.com/tmio/2022-05-31-folding.html

TMiO might be too detailed and reliant on a single person, which might
be part of the problem in keeping it rolling.  I cannot evaluate that,
because I didn't follow the project in too much detail.

My initial plan (see https://amodernist.com/texts/elpa-zine.html) was
just to focus on ELPA-related development, such as new packages or
updates, since this is what most users are probably also interested in.
An idea that was discussed, and that might be emphasises in greater
detail could be to have a sort of "builtin-board" for announcements of
more important news or help requests from core ELPA development.

I think it is obvious, that this kind of a thing would have to be a
collaborative effort.  While it only requires a single or just a few
people to compile this kind of a post/newsletter, 

>> ... I have mentioned the idea of a ELPA
>> newsletter somewhere around here once, but upon reflection, it seems
>> like a TMIO-like idea should be implemented to the entire
>> core-development, not just the ELPAs.  Would anyone here be interested
>> in working on something like that?
>
> A somewhat relevant effort is by Sacha Chua:
> https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/
>
> It is less detailed (just an outline), but I find it pretty useful.

Crucially it is incomplete, when it comes to core development.  There
are frequently longer discussions and bugs that never get mentioned on
the newsletter, even though they *should* be highlighted *and* explained
for an average user, especially if their feedback is what is needed.

On the other hand, the newsletter is as complete as it gets wrt all the
other news (I am under the impression that it summarises every
blog-post, reddit-submission, video, etc. published on the topic of
Emacs over the last week), which is not what I am interested in.

Timothy <orgmode@tec.tecosaur.net> writes:

> Hi Ihor,
>
>> This is actually quite an effort. AFAIK, the author had difficulties
>> allocating time to write more posts for TMiO.
>>
>> Also, for reference, we are talking about
>> <https://blog.tecosaur.com/tmio/2022-05-31-folding.html>
>
> Each post took several hours to do, despite how short they were. The major
> difficulty is in making sure that I’ve read as much as I can in that month, and
> trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
> people out) which requires looking at the ML + git log since the last TMiO.
>
> For what it’s worth, once the org-latex-preview branch gets merged, I plan on
> doing another TMiO with the disclaimer that I may have missed out a bunch of
> things in that edition.
>
> Something else we could do is have some sort of “community draft” as is now
> being done on the Julia discourse, which could help reduce the individual
> workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>).

I am not sure what this means, does one person create a summary of what
has been going on and others comment on it before it is published on a
proper blog?

> All the best,
> Timothy

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

> Writing new content (à la Linux Weekly News) is a massive effort.  I would
> expect any attempt at such a product to peter out in short order.
>
> A big, big +1 for Sacha's weekly Emacs News.  I find it just the right
> level of detail.  It directs one to Emacs mail threads, upcoming events and
> get togethers, blogs and Reddit posts, Youtube videos, etc.  And, IIRC, she
> is even set up to accept contributions from others.  Let's support her.

I am not proposing an alternative toe Emacs News in any sense.  What I
am trying to convince people in joining me bootstrap is a medium that is
published less frequently, goes into more detail on core-development and
ELPA news and ideally wouldn't be written by a single person, but
feature more guest posts.

> /john

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Fu Yuan]

>> 
>>> There comes a point where people have to accept that mailing lists
>>> What I think the Org project does well is the "This month in Org" line
>>> of posts, that help highlight contributions from newcomers and
>>> familiarise those familiar with a mailing list with the procedures going
>>> on here.
>> 
>> This is actually quite an effort. AFAIK, the author had difficulties
>> allocating time to write more posts for TMiO.
>> 
>> Also, for reference, we are talking about
>> https://blog.tecosaur.com/tmio/2022-05-31-folding.html
> 
> TMiO might be too detailed and reliant on a single person, which might
> be part of the problem in keeping it rolling.  I cannot evaluate that,
> because I didn't follow the project in too much detail.
> 
> My initial plan (see https://amodernist.com/texts/elpa-zine.html) was
> just to focus on ELPA-related development, such as new packages or
> updates, since this is what most users are probably also interested in.
> An idea that was discussed, and that might be emphasises in greater
> detail could be to have a sort of "builtin-board" for announcements of
> more important news or help requests from core ELPA development.
> 
> I think it is obvious, that this kind of a thing would have to be a
> collaborative effort.  While it only requires a single or just a few
> people to compile this kind of a post/newsletter, 

That would be valuable for Emacs development. For example, sometimes I wish there is an official channel in which I can post progress of tree-sitter functionalities, and ask for help for adding certain features, and conclusion of general tree-sitter discussions and direction forward. I think other features/submodules could benefit the same.


>>> ... I have mentioned the idea of a ELPA
>>> newsletter somewhere around here once, but upon reflection, it seems
>>> like a TMIO-like idea should be implemented to the entire
>>> core-development, not just the ELPAs.  Would anyone here be interested
>>> in working on something like that?
>> 
>> A somewhat relevant effort is by Sacha Chua:
>> https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/
>> 
>> It is less detailed (just an outline), but I find it pretty useful.
> 
> Crucially it is incomplete, when it comes to core development.  There
> are frequently longer discussions and bugs that never get mentioned on
> the newsletter, even though they *should* be highlighted *and* explained
> for an average user, especially if their feedback is what is needed.
> 
> On the other hand, the newsletter is as complete as it gets wrt all the
> other news (I am under the impression that it summarises every
> blog-post, reddit-submission, video, etc. published on the topic of
> Emacs over the last week), which is not what I am interested in.
> 
> Timothy <orgmode@tec.tecosaur.net> writes:
> 
>> Hi Ihor,
>> 
>>> This is actually quite an effort. AFAIK, the author had difficulties
>>> allocating time to write more posts for TMiO.
>>> 
>>> Also, for reference, we are talking about
>>> <https://blog.tecosaur.com/tmio/2022-05-31-folding.html>
>> 
>> Each post took several hours to do, despite how short they were. The major
>> difficulty is in making sure that I’ve read as much as I can in that month, and
>> trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
>> people out) which requires looking at the ML + git log since the last TMiO.
>> 
>> For what it’s worth, once the org-latex-preview branch gets merged, I plan on
>> doing another TMiO with the disclaimer that I may have missed out a bunch of
>> things in that edition.
>> 
>> Something else we could do is have some sort of “community draft” as is now
>> being done on the Julia discourse, which could help reduce the individual
>> workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>).
> 
> I am not sure what this means, does one person create a summary of what
> has been going on and others comment on it before it is published on a
> proper blog?
> 
>> All the best,
>> Timothy
> 
> John Yates <john@yates-sheets.org> writes:
> 
>> Writing new content (à la Linux Weekly News) is a massive effort.  I would
>> expect any attempt at such a product to peter out in short order.
>> 
>> A big, big +1 for Sacha's weekly Emacs News.  I find it just the right
>> level of detail.  It directs one to Emacs mail threads, upcoming events and
>> get togethers, blogs and Reddit posts, Youtube videos, etc.  And, IIRC, she
>> is even set up to accept contributions from others.  Let's support her.
> 
> I am not proposing an alternative toe Emacs News in any sense.  What I
> am trying to convince people in joining me bootstrap is a medium that is
> published less frequently, goes into more detail on core-development and
> ELPA news and ideally wouldn't be written by a single person, but
> feature more guest posts.
> 
>> /john
> 

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Ihor Radchenko]

Fu Yuan <casouri@gmail.com> writes:

>> I think it is obvious, that this kind of a thing would have to be a
>> collaborative effort.  While it only requires a single or just a few
>> people to compile this kind of a post/newsletter, 
>
> That would be valuable for Emacs development. For example, sometimes I wish there is an official channel in which I can post progress of tree-sitter functionalities, and ask for help for adding certain features, and conclusion of general tree-sitter discussions and direction forward. I think other features/submodules could benefit the same.

For the specific cases you mentioned, Org mode uses (well... WIP) Woof!
The idea is to tag certain email threads, so that they appear in a
dedicated RSS/web page. For example, see POLLs in
https://tracker.orgmode.org/requests. We have similar thing for
Announcements/News.

I even managed to bridge the announcements in Woof! to Matrix channels
at some point.

Then, users can either subscribe via RSS directory or someone curating
the digest may use such tagged email threads as a source.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Philip Kaludercic]

Here is a demonstration of how this kind of a medium could look like:

     https://amodernist.com/eaez/

This is just a mockup, but it seems like something that can be
reasonably maintained as long as I continue to regularly follow the
mailing list and track new additions to ELPA.

Philip Kaludercic <philipk@posteo.net> writes:

> Ihor Radchenko <yantar92@posteo.net> writes:
>
>> Philip Kaludercic <philipk@posteo.net> writes:
>>
>>> There comes a point where people have to accept that mailing lists
>>> What I think the Org project does well is the "This month in Org" line
>>> of posts, that help highlight contributions from newcomers and
>>> familiarise those familiar with a mailing list with the procedures going
>>> on here.
>>
>> This is actually quite an effort. AFAIK, the author had difficulties
>> allocating time to write more posts for TMiO.
>>
>> Also, for reference, we are talking about
>> https://blog.tecosaur.com/tmio/2022-05-31-folding.html
>
> TMiO might be too detailed and reliant on a single person, which might
> be part of the problem in keeping it rolling.  I cannot evaluate that,
> because I didn't follow the project in too much detail.
>
> My initial plan (see https://amodernist.com/texts/elpa-zine.html) was
> just to focus on ELPA-related development, such as new packages or
> updates, since this is what most users are probably also interested in.
> An idea that was discussed, and that might be emphasises in greater
> detail could be to have a sort of "builtin-board" for announcements of
> more important news or help requests from core ELPA development.
>
> I think it is obvious, that this kind of a thing would have to be a
> collaborative effort.  While it only requires a single or just a few
> people to compile this kind of a post/newsletter, 
>
>>> ... I have mentioned the idea of a ELPA
>>> newsletter somewhere around here once, but upon reflection, it seems
>>> like a TMIO-like idea should be implemented to the entire
>>> core-development, not just the ELPAs.  Would anyone here be interested
>>> in working on something like that?
>>
>> A somewhat relevant effort is by Sacha Chua:
>> https://sachachua.com/blog/2023/08/2023-08-28-emacs-news/
>>
>> It is less detailed (just an outline), but I find it pretty useful.
>
> Crucially it is incomplete, when it comes to core development.  There
> are frequently longer discussions and bugs that never get mentioned on
> the newsletter, even though they *should* be highlighted *and* explained
> for an average user, especially if their feedback is what is needed.
>
> On the other hand, the newsletter is as complete as it gets wrt all the
> other news (I am under the impression that it summarises every
> blog-post, reddit-submission, video, etc. published on the topic of
> Emacs over the last week), which is not what I am interested in.
>
> Timothy <orgmode@tec.tecosaur.net> writes:
>
>> Hi Ihor,
>>
>>> This is actually quite an effort. AFAIK, the author had difficulties
>>> allocating time to write more posts for TMiO.
>>>
>>> Also, for reference, we are talking about
>>> <https://blog.tecosaur.com/tmio/2022-05-31-folding.html>
>>
>> Each post took several hours to do, despite how short they were. The major
>> difficulty is in making sure that I’ve read as much as I can in that month, and
>> trying to feel like I’ve treated most contributions “fairly” (i.e. not missing
>> people out) which requires looking at the ML + git log since the last TMiO.
>>
>> For what it’s worth, once the org-latex-preview branch gets merged, I plan on
>> doing another TMiO with the disclaimer that I may have missed out a bunch of
>> things in that edition.
>>
>> Something else we could do is have some sort of “community draft” as is now
>> being done on the Julia discourse, which could help reduce the individual
>> workload (ref: <https://discourse.julialang.org/t/this-month-in-julia-world-2023-08/103242>).
>
> I am not sure what this means, does one person create a summary of what
> has been going on and others comment on it before it is published on a
> proper blog?
>
>> All the best,
>> Timothy
>
> John Yates <john@yates-sheets.org> writes:
>
>> Writing new content (à la Linux Weekly News) is a massive effort.  I would
>> expect any attempt at such a product to peter out in short order.
>>
>> A big, big +1 for Sacha's weekly Emacs News.  I find it just the right
>> level of detail.  It directs one to Emacs mail threads, upcoming events and
>> get togethers, blogs and Reddit posts, Youtube videos, etc.  And, IIRC, she
>> is even set up to accept contributions from others.  Let's support her.
>
> I am not proposing an alternative toe Emacs News in any sense.  What I
> am trying to convince people in joining me bootstrap is a medium that is
> published less frequently, goes into more detail on core-development and
> ELPA news and ideally wouldn't be written by a single person, but
> feature more guest posts.
>
>> /john

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Yuan Fu]

> On Sep 2, 2023, at 12:17 PM, Philip Kaludercic <philipk@posteo.net> wrote:
> 
> 
> Here is a demonstration of how this kind of a medium could look like:
> 
>     https://amodernist.com/eaez/
> 
> This is just a mockup, but it seems like something that can be
> reasonably maintained as long as I continue to regularly follow the
> mailing list and track new additions to ELPA.

I like it. I can send you some progress report on tree-sitter (not unlike what I sent to emacs-devel) and some package/faeture ideas, if you decide to soft-launch this. 

Yuan

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Philip Kaludercic]

Yuan Fu <casouri@gmail.com> writes:

>> On Sep 2, 2023, at 12:17 PM, Philip Kaludercic <philipk@posteo.net> wrote:
>> 
>> 
>> Here is a demonstration of how this kind of a medium could look like:
>> 
>>     https://amodernist.com/eaez/
>> 
>> This is just a mockup, but it seems like something that can be
>> reasonably maintained as long as I continue to regularly follow the
>> mailing list and track new additions to ELPA.
>
> I like it. I can send you some progress report on tree-sitter (not
> unlike what I sent to emacs-devel) and some package/faeture ideas, if
> you decide to soft-launch this.

That would be great.  I hope to have enough material to publish a proper
edition at the month.

> Yuan

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Ihor Radchenko]

Philip Kaludercic <philipk@posteo.net> writes:

>>> Here is a demonstration of how this kind of a medium could look like:
>>> 
>>>     https://amodernist.com/eaez/
>>> 
>>> This is just a mockup, but it seems like something that can be
>>> reasonably maintained as long as I continue to regularly follow the
>>> mailing list and track new additions to ELPA.
>>
>> I like it. I can send you some progress report on tree-sitter (not
>> unlike what I sent to emacs-devel) and some package/faeture ideas, if
>> you decide to soft-launch this.
>
> That would be great.  I hope to have enough material to publish a proper
> edition at the month.

+1. Looks nice.

You may also consider announcing that you are gathering a material in a
dedicated emacs-devel thread. Then, users can reply with proposals.
Or maintainers may ping you in the threads that should be brought to
wider audience (like help requests).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Emanuel Berg]

Ihor Radchenko wrote:

> You may also consider announcing that you are gathering
> a material in a dedicated emacs-devel thread. Then, users
> can reply with proposals. Or maintainers may ping you in the
> threads that should be brought to wider audience (like help
> requests).

If people read Linux Magazine they might remember in each
issue there was a summary of the discussions on LKML (which
supposedly has 10 000+ posts _a week_), the article was
usually 2-3 pages with no pictures, and it was mostly or
almost impossible to understand for anyone on the outside, yet
it was probably the most interesting piece in the
whole magazine.

Maybe we can have something like that, and combine it with the
Emacs News?

So the first article can start with this very post, "It all
started, this week on gnu.emacs.devel, with fond memories from
reading Linux Magazine at the public library, with an empty
stomach and a hunger for knowledge ..."

-- 
underground experts united
https://dataswamp.org/~incal

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: Yuan Fu <casouri@gmail.com>, emacs-devel@gnu.org
> Date: Sun, 03 Sep 2023 08:03:38 +0000
> 
> > That would be great.  I hope to have enough material to publish a proper
> > edition at the month.
> 
> +1. Looks nice.
> 
> You may also consider announcing that you are gathering a material in a
> dedicated emacs-devel thread. Then, users can reply with proposals.
> Or maintainers may ping you in the threads that should be brought to
> wider audience (like help requests).

I'm not sure I understand the details of this.  Where would this
digest be published?  I hope not on emacs-devel itself -- we have more
than enough volume of traffic here.  Emacs News gets posted to
emacs-tangents, so I think that should be the preferred forum for this
digest as well.

Apologies if I misunderstood something.

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> You may also consider announcing that you are gathering a material in a
>> dedicated emacs-devel thread. Then, users can reply with proposals.
>> Or maintainers may ping you in the threads that should be brought to
>> wider audience (like help requests).
>
> I'm not sure I understand the details of this.  Where would this
> digest be published?

https://amodernist.com/eaez/

> ... I hope not on emacs-devel itself -- we have more
> than enough volume of traffic here.  Emacs News gets posted to
> emacs-tangents, so I think that should be the preferred forum for this
> digest as well.

I proposed to drop some kind of monthly thread here, on emacs-devel, in
case if you or other contributors want to encourage feedback or ask for
help from more users.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: philipk@posteo.net, casouri@gmail.com, emacs-devel@gnu.org
> Date: Sun, 03 Sep 2023 08:53:46 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> You may also consider announcing that you are gathering a material in a
> >> dedicated emacs-devel thread. Then, users can reply with proposals.
> >> Or maintainers may ping you in the threads that should be brought to
> >> wider audience (like help requests).
> >
> > I'm not sure I understand the details of this.  Where would this
> > digest be published?
> 
> https://amodernist.com/eaez/

If by that you mean the digest will be there, it's fine with me.

> > ... I hope not on emacs-devel itself -- we have more
> > than enough volume of traffic here.  Emacs News gets posted to
> > emacs-tangents, so I think that should be the preferred forum for this
> > digest as well.
> 
> I proposed to drop some kind of monthly thread here, on emacs-devel, in
> case if you or other contributors want to encourage feedback or ask for
> help from more users.

Not sure I understand: if we want to ask for help, we just post the
request.  There's no need for any monthly thread to post such
requests.

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> I proposed to drop some kind of monthly thread here, on emacs-devel, in
>> case if you or other contributors want to encourage feedback or ask for
>> help from more users.
>
> Not sure I understand: if we want to ask for help, we just post the
> request.  There's no need for any monthly thread to post such
> requests.

How can people who are not actively reading emacs-devel notice such
requests? For example,
https://yhetil.org/emacs-devel/5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com/
does not clearly indicate in the subject that it is asking for ideas. In
other cases, just one of the messages deep inside threads may ask for
feedback, which is even harder to notice.

If the help requests are collected into a digest, it will be much easier
to follow for casual readers (the majority).

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: philipk@posteo.net, casouri@gmail.com, emacs-devel@gnu.org
> Date: Sun, 03 Sep 2023 09:16:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I proposed to drop some kind of monthly thread here, on emacs-devel, in
> >> case if you or other contributors want to encourage feedback or ask for
> >> help from more users.
> >
> > Not sure I understand: if we want to ask for help, we just post the
> > request.  There's no need for any monthly thread to post such
> > requests.
> 
> How can people who are not actively reading emacs-devel notice such
> requests?

But you also suggest to do so in a special thread on emacs-devel, so
how is that different?

> For example,
> https://yhetil.org/emacs-devel/5E7F2A94-4377-45C0-8541-7F59F3B54BA1@gmail.com/
> does not clearly indicate in the subject that it is asking for ideas. In
> other cases, just one of the messages deep inside threads may ask for
> feedback, which is even harder to notice.
> 
> If the help requests are collected into a digest, it will be much easier
> to follow for casual readers (the majority).

Sounds like a misunderstanding: I wasn't objecting to have that in a
digest, I was only talking about a monthly thread one emacs-devel.

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> writes:

>> How can people who are not actively reading emacs-devel notice such
>> requests?

(scratching my head why I wrote it this way...)

> But you also suggest to do so in a special thread on emacs-devel, so
> how is that different?

What I meant is that requests scattered across all threads might go
unnoticed, even if someone is collecting such requests for the discussed
digest.

If Emacs devs instead put the most important requests into a dedicated
thread, it would be much easier to see them and put into the digest.

Another option might be changing email subject to [HELP] ... or
[POLL] ... (that's what we usually do in Org mailing list)

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: philipk@posteo.net, casouri@gmail.com, emacs-devel@gnu.org
> Date: Wed, 06 Sep 2023 11:13:39 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But you also suggest to do so in a special thread on emacs-devel, so
> > how is that different?
> 
> What I meant is that requests scattered across all threads might go
> unnoticed, even if someone is collecting such requests for the discussed
> digest.
> 
> If Emacs devs instead put the most important requests into a dedicated
> thread, it would be much easier to see them and put into the digest.
> 
> Another option might be changing email subject to [HELP] ... or
> [POLL] ... (that's what we usually do in Org mailing list)

Ah, okay, makes sense.

We also have the Keywords: header (we use it when announcing Emacs
releases).

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Philip Kaludercic]

Ihor Radchenko <yantar92@posteo.net> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> You may also consider announcing that you are gathering a material in a
>>> dedicated emacs-devel thread. Then, users can reply with proposals.
>>> Or maintainers may ping you in the threads that should be brought to
>>> wider audience (like help requests).
>>
>> I'm not sure I understand the details of this.  Where would this
>> digest be published?
>
> https://amodernist.com/eaez/
>
>> ... I hope not on emacs-devel itself -- we have more
>> than enough volume of traffic here.  Emacs News gets posted to
>> emacs-tangents, so I think that should be the preferred forum for this
>> digest as well.
>
> I proposed to drop some kind of monthly thread here, on emacs-devel, in
> case if you or other contributors want to encourage feedback or ask for
> help from more users.

I have created a separated mailing list here, to avoid noise over here:
https://lists.sr.ht/~pkal/elpa-zine.

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Emanuel Berg]

Philip Kaludercic wrote:

> I have created a separated mailing list here, to avoid noise
> over here: https://lists.sr.ht/~pkal/elpa-zine.

Awesome, see if you can register it with Gmane for
Emacs Gnus afficionados!

-- 
underground experts united
https://dataswamp.org/~incal

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Eshel Yaron]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: Yuan Fu <casouri@gmail.com>, emacs-devel@gnu.org
>> Date: Sun, 03 Sep 2023 08:03:38 +0000
>>
>> > That would be great.  I hope to have enough material to publish a proper
>> > edition at the month.
>>
>> +1. Looks nice.
>>
>> You may also consider announcing that you are gathering a material in a
>> dedicated emacs-devel thread. Then, users can reply with proposals.
>> Or maintainers may ping you in the threads that should be brought to
>> wider audience (like help requests).
>
> I'm not sure I understand the details of this.  Where would this
> digest be published?  I hope not on emacs-devel itself -- we have more
> than enough volume of traffic here.  Emacs News gets posted to
> emacs-tangents, so I think that should be the preferred forum for this
> digest as well.
>
> Apologies if I misunderstood something.

IIUC, what Ihor suggested was that Philip sends an announcement about
gathering materials to emacs-devel, inviting people to bring up
interesting discussions/developments for inclusion in the digest.  The
Git Rev News people do something similar, they send a "Draft of Git Rev
News edition N" to the Git mailing list to let people know there's a new
edition no the way.  Here's the "Draft of Git Rev News edition 82"
message, for example:

https://lore.kernel.org/all/CAP8UFD1W+y6SYHA_EUEwAo3cWE=DmJLGxG54McW9cNtSr3AUAQ@mail.gmail.com/T/

The monthly Emacs digest itself would be published elsewhere, off
emacs-devel, IIUC.

Re: Monthy emacs-devel digest, similar to "This month in Org"

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: Yuan Fu <casouri@gmail.com>, emacs-devel@gnu.org
>> Date: Sun, 03 Sep 2023 08:03:38 +0000
>> 
>> > That would be great.  I hope to have enough material to publish a proper
>> > edition at the month.
>> 
>> +1. Looks nice.
>> 
>> You may also consider announcing that you are gathering a material in a
>> dedicated emacs-devel thread. Then, users can reply with proposals.
>> Or maintainers may ping you in the threads that should be brought to
>> wider audience (like help requests).
>
> I'm not sure I understand the details of this.  Where would this
> digest be published?  I hope not on emacs-devel itself -- we have more
> than enough volume of traffic here.  

I'll be publishing it for now on my personal site, perhaps I might move
it to some other location, but I'd not post it here, don't worry.  The
target audience are precisely people who don't follow the mailing list.

>                                      Emacs News gets posted to
> emacs-tangents, so I think that should be the preferred forum for this
> digest as well.
>
> Apologies if I misunderstood something.

No problem.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Dmitry Gutov]

On 31/08/2023 14:21, Ihor Radchenko wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> - 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).
> What about using something other than forge for discussions?
> On Org ML, we have recently discussed an idea to have Discourse as the
> means for users to interact with the mailing list via web UI:
> https://list.orgmode.org/orgmode/87edvxnnqw.fsf@localhost/

Note that we weren't discussing any move away from mailing lists such as 
emacs-devel, help-emacs, etc. Only changing the source of bug-gnu-emacs 
and emacs-diffs.

Changing everything at once would be much too difficult. And gitlab 
doesn't have anything corresponding to github's "Discussions" anyway.

> Discourse has free licence, can be self-hosted, and has mailing list
> integration.

While it is a compelling option, I think it's going to be a very hard 
sell for this project.

In any case, I'd recommend postponing discussing that until after the 
force/bugtracker change happens. That alone might be difficult enough.

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Ihor Radchenko]

Dmitry Gutov <dmitry@gutov.dev> writes:

>> Discourse has free licence, can be self-hosted, and has mailing list
>> integration.
>
> While it is a compelling option, I think it's going to be a very hard 
> sell for this project.
>
> In any case, I'd recommend postponing discussing that until after the 
> force/bugtracker change happens. That alone might be difficult enough.

Fair point. Pairing mailing list functionality without bug tracking
seems easier in terms of requirements, but, on the other hand, moving to
alternative bug tracking system appears to have more overall interest.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Richard Stallman]

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

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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?

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Eli Zaretskii]

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

Re: New Package for NonGNU-ELPA: clojure-ts-mode

[Philip Kaludercic]

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.