Clojure mode

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

[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

[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

[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

[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

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

[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

[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

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

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

[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

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

[Ryan Tate]

rms 26 Aug 2023:

> If we install a command called clojure-mode in the core Emacs, that will in a sense be the preferred one.

This is plainly a freedom 0 violation, intentionally thwarting a user’s wish to install a particular piece of software through the raw exercise of situational, incidental power never intentionally granted for this purpose. 

The work of bbatsov and others has created the reputation and meaning of “clojure-mode.” To simply steal the fruits of that labor, and to trick users, through you situational power to bundle is abusive and wrong. It mirrors the behavior of some of the most avaricious venture-capital funded startups (even if the reasoning is nominally ideological rather than capitalist). 

As a longtime user of (and onetime patch contributor to) emacs, and as an active user of clojure mode and CIDER, I find it disappointing this is even being considered. Build a version of the mode under another license if you wish but get your own name rather than stealing one.

Re: Clojure mode

[Eli Zaretskii]

> From: Ryan Tate <ryantate@ryantate.com>
> Date: Sat, 9 Sep 2023 15:39:53 -0400
> 
> rms 26 Aug 2023:
> 
> > If we install a command called clojure-mode in the core Emacs, that will in a sense be the preferred one.
> 
> This is plainly a freedom 0 violation, intentionally thwarting a user’s wish to install a particular piece of software through the raw exercise of situational, incidental power never intentionally granted for this purpose. 

Bringing up ideas cannot possibly violate any freedoms, so please
don't exaggerate.

> As a longtime user of (and onetime patch contributor to) emacs, and as an active user of clojure mode and CIDER, I find it disappointing this is even being considered. Build a version of the mode under another license if you wish but get your own name rather than stealing one.

You are in effect reviving an old thread that was a tempest in a
teapot almost from the beginning, as soon as the developers of
clojure-mode explicitly said they were not interested in donating
their package to Emacs.  (I think it was since then revealed that this
decision was at least in part based on incorrect and/or outdated
assumptions and impressions, but the decision still stands, although
we certainly hope it will be reconsidered.)  Moreover, you revive this
old thread with harsh and unkind words, reprimanding us for bringing
up ideas(!) whose only intent is to make Emacs better.  Please in the
future be kinder, and please remember that clojure-mode uses the power
and flexibility of Emacs developed and brought to you by those same
people whom you accuse here in crimes they didn't commit ("stealing
the fruits of labor" etc.).

Please in the future use kinder, more polite words when expressing
opinions here, TIA.

Re: Clojure mode

[Ryan Tate]

> On Sep 10, 2023, at 1:14 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>  Moreover, you revive this
> old thread with harsh and unkind words, reprimanding us for bringing
> up ideas(!) whose only intent is to make Emacs better.

It was an idea to steal the name of a project, explicitly and in the words of the creator of emacs expressway for the purpose of gaining popularity for your own version. You can’t bring up an idea — an idea to steal and trick — in public and then get mad when someone criticizes the idea. Well, I suppose you can actually, but I find it baffling to do so and then say people are mean for criticizing it. 


> Please in the future use kinder, more polite words when expressing
> opinions here, TIA.

Did anyone here consider the feelings of bbatsov or Clojure users when proposing to trick us into installing a gnu package instead of the original? Given the appalling orbat least _aggressive_ nature of what was proposed, you’re being a bit thin skinned. 

All that said, I am very grateful for emacs, and among the ways I have tried to show this is by contributing patches (well, one) and money to fsf. 🙏 thank you all for actions other than ones I wrote about 

Re: Clojure mode

[Eli Zaretskii]

> From: Ryan Tate <ryantate@ryantate.com>
> Date: Sun, 10 Sep 2023 02:07:13 -0400
> Cc: emacs-devel@gnu.org
> 
> > On Sep 10, 2023, at 1:14 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> >  Moreover, you revive this
> > old thread with harsh and unkind words, reprimanding us for bringing
> > up ideas(!) whose only intent is to make Emacs better.
> 
> It was an idea to steal the name of a project

You are again exaggerating, and you are again accusing people in
crimes they didn't commit.  No stealing is involved here, nor could be
involved.

> > Please in the future use kinder, more polite words when expressing
> > opinions here, TIA.
> 
> Did anyone here consider the feelings of bbatsov or Clojure users when proposing to trick us into installing a gnu package instead of the original?

No one proposed that.  You are misreading the suggestions in this
thread.

> Given the appalling orbat least _aggressive_ nature of what was proposed, you’re being a bit thin skinned. 

Once again, please don't use harsh words that we don't deserve.  You
are violating the acceptable behavior here, and you are doing this
after being asked not to do so.

> All that said, I am very grateful for emacs, and among the ways I have tried to show this is by contributing patches (well, one) and money to fsf. 🙏 thank you all for actions other than ones I wrote about 

You are welcome, but please tone down your posts about this.

Re: Clojure mode

[Ryan Tate]

> On Sep 10, 2023, at 2:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
> You are again exaggerating, and you are again accusing people in
> crimes they didn't commit.  No stealing is involved here, nor could be
> involved.
> 

You continue to minimize what was proposed. 

> 
> No one proposed that.  You are misreading the suggestions in this
> thread.

 …and deny what was said…


> Once again, please don't use harsh words that we don't deserve.  You
> are violating the acceptable behavior here, and you are doing this
> after being asked not to do so.
> 

It’s not ok to behave the way your founder has and then punish people for calling it out. I’m not particularly active on this list, and I won’t personally suffer much if you block me, but my language throughout this has been measured and it speaks poorly of fsf’s values for you to bully me for speaking out respectfully. 

>> 
> 
> You are welcome, but please tone down your posts about this.

I stand by what I’ve written. Reflect and do better! Have a good weekend. 

Re: Clojure mode

[Eli Zaretskii]

> From: Ryan Tate <ryantate@ryantate.com>
> Date: Sun, 10 Sep 2023 03:13:30 -0400
> Cc: emacs-devel@gnu.org
> 
> > On Sep 10, 2023, at 2:57 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> > 
> > You are again exaggerating, and you are again accusing people in
> > crimes they didn't commit.  No stealing is involved here, nor could be
> > involved.
> 
> You continue to minimize what was proposed. 

I'm not.  Especially since I'm one of the people who decide what will
actually happen.

> > No one proposed that.  You are misreading the suggestions in this
> > thread.
> 
>  …and deny what was said…

No, I don't.

> I stand by what I’ve written.

Too bad.

Re: Clojure mode

[Barry Fishman]

On 2023-09-10 03:13:30 -04, Ryan Tate wrote:
> It’s not ok to behave the way your founder has and then punish people
> for calling it out. I’m not particularly active on this list, and I
> won’t personally suffer much if you block me, but my language
> throughout this has been measured and it speaks poorly of fsf’s values
> for you to bully me for speaking out respectfully.
>
>>> 
>> 
>> You are welcome, but please tone down your posts about this.
>
> I stand by what I’ve written. Reflect and do better! Have a good
> weekend.

I find it remarkable the someone can claim ethical rights to a symbol
name in an Emacs name-space solely because they used it first in a
useful package.  Especially such a name as closure-mode which is the
obvious name for a Closure language mode.

You seem to claim that somehow the Emacs developers are now ethically
forbidden to make changes that they feel provide improvements in a
project they have taken the responsibility to maintain, because
someone on the internet has chosen to add an unsolicited extension, and
make it available.

Personally, as primarily a Emacs user, I find it inconvenient to have my
own additions and selected extensions cause Emacs to break for me,
due to some change made in Emacs or a package I download and use.

I may even complain about it.  But the idea that I had some standing
as far as having my rights violated seems absurd.

May newer projects have name-spaces, and have some registration process
for users or projects defining their own unique name-spaces in which
they can add their modules.  Often that is a DNS registration they own.
My Closure mode would be org.ecubist:closure-mode. Things could then be
shorten in their code by using some import/export language facility.

In Emacs there seems to be a practice of prefixing a common term in a
symbol with some likely unique prefix such as their initials and a
slash.  My own local Closure mode I might call bf/closure-mode. 
At least then, if there is a conflict (with somebody who's initials are
also "BF"), I could find the code to be changed with a regex.

Either way, it seems to be reasonable to expect some name change
discussion when a mode is formally added into Emacs.  And the
initial choice of an obvious name for some externally distributed
package brings with it an expectation of some future conflict.  And in
that conflict the defense that you used the symbol first would not be
very persuasive.

-- 
Barry Fishman