Adding Flycheck to NonGNU ELPA

Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

Hey everyone,

Just wanted to ask if there's any interested in adding Flycheck (https://www.flycheck.org/en/latest/), a popular alternative to Flymake, to NonGNU ELPA?

You can find the codebase here https://github.com/flycheck/flycheck
There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot

I'm not sure what's the stance of adding alternatives to built-in packages in general, but I think providing some alternatives to the end users is not a bad thing overall.


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

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

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

> Hey everyone,
>
> Just wanted to ask if there's any interested in adding Flycheck
> (https://www.flycheck.org/en/latest/), a popular alternative to
> Flymake, to NonGNU ELPA?
>
> You can find the codebase here https://github.com/flycheck/flycheck
> There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>
> I'm not sure what's the stance of adding alternatives to built-in
> packages in general, but I think providing some alternatives to the
> end users is not a bad thing overall.

My main question is what advantage Flycheck has over Flymake.  I
understand it has a database of tools built-in, but considering that
more and more people rely on LSP for the information (and Eglot supports
Flymake OOTB), I don't know how valuable this is.  In addition to that,
there are projects like

https://github.com/mohkale/flymake-collection
https://github.com/purcell/flymake-flycheck

that could help bridge the gap.

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

There is a detailed comparison here https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html but many of the differences are probably not important to many people. You might remember that before Flycheck, Flymake was in a state of disarray and abandoment for years, so I'm pretty sure Flycheck making it almost obsolete back then was the trigger for some modernization around Emacs 26.1. And the contributors to Flycheck and Flymake were always pretty different - part of the reason Sebastien (the original author of Flycheck) quit Emacs were some attacks he was getting on emacs-devel. 

Many people are so off-put by the discourse there, that they want to have as little as possible with it. And that's the real value of alternative packages IMO - they allow us to harvest the energy of all contributors. 

Btw, flymake-flycheck was created only because Joao wouldn't agree to provide Flycheck support in Eglot (I know this from the author of flymake-flycheck). The whole situation with Elgot was a classic example of the hostility in Emacs towards packages some maintainers dislike... (https://github.com/joaotavora/eglot/issues/42)

> but considering that
> more and more people rely on LSP for the information (and Eglot supports
> Flymake OOTB), I don't know how valuable this is.

Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users flycheck by default for its error diagnostics. I'm not a big LSP user, though, and often prefer the simplicity of just shelling out to whatever lint tools I need. 

You probably know that Flycheck is one of the most download packages on MELPA, so it has plenty of happy users. I'm one of them and that's why I took over the maintenance of the project. I felt that NonGNU ELPA existed to make it easier for popular stuff to be installed by users, but it seems to me MELPA won't be going away any time soon. 

On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > Hey everyone,
> >
> > Just wanted to ask if there's any interested in adding Flycheck
> > (https://www.flycheck.org/en/latest/), a popular alternative to
> > Flymake, to NonGNU ELPA?
> >
> > You can find the codebase here https://github.com/flycheck/flycheck
> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
> >
> > I'm not sure what's the stance of adding alternatives to built-in
> > packages in general, but I think providing some alternatives to the
> > end users is not a bad thing overall.
> 
> My main question is what advantage Flycheck has over Flymake.  I
> understand it has a database of tools built-in, but considering that
> more and more people rely on LSP for the information (and Eglot supports
> Flymake OOTB), I don't know how valuable this is.  In addition to that,
> there are projects like
> 
> https://github.com/mohkale/flymake-collection
> https://github.com/purcell/flymake-flycheck
> 
> that could help bridge the gap.
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Eli Zaretskii]

> Date: Mon, 19 Feb 2024 20:08:15 +0200
> From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> Cc: "Emacs Devel" <emacs-devel@gnu.org>
> 
> Btw, flymake-flycheck was created only because Joao wouldn't agree to provide Flycheck support in Eglot (I
> know this from the author of flymake-flycheck). The whole situation with Elgot was a classic example of the
> hostility in Emacs towards packages some maintainers dislike...
> (https://github.com/joaotavora/eglot/issues/42)

To set the record straight: that issue is from 2018, full 4 years
before Eglot was added to Emacs.  So I don't see how any incident from
back then could be considered "a classic example of hostility in
Emacs".

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

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

> There is a detailed comparison here
> https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html

From what I see, this comparison is outdated and somewhat one-sided.
Flymake has error explanations, and categories like "Automatic syntax
checking" seem disingenuous if the complaint is that there is not a
flymake-global-mode.  (It would have probably taken less time to write a
`define-globalized-minor-mode', than the time to write this point...)

> but many of the differences are probably not important to many
> people. You might remember that before Flycheck, Flymake was in a
> state of disarray and abandoment for years, so I'm pretty sure
> Flycheck making it almost obsolete back then was the trigger for some
> modernization around Emacs 26.1. 

Could you explain how this relates to the current state of Flymake
vs. Flycheck?  The fact that Flymake caught up, and in my eyes
deprecated Flycheck, seems like a success story.

>                                  And the contributors to Flycheck and
> Flymake were always pretty different - part of the reason Sebastien
> (the original author of Flycheck) quit Emacs were some attacks he was
> getting on emacs-devel.

For the sake of a constructive discussion, please don't make claims like
these without any further references.  Provocations like these, from
anyone, only make discussions like these more difficult.

> Many people are so off-put by the discourse there, that they want to
> have as little as possible with it. And that's the real value of
> alternative packages IMO - they allow us to harvest the energy of all
> contributors.

I don't think this is the problem you are making it out to be, and even
if it were, one could have a package like flymake-collection added to
NonGNU ELPA.

> Btw, flymake-flycheck was created only because Joao wouldn't agree to
> provide Flycheck support in Eglot (I know this from the author of
> flymake-flycheck). The whole situation with Elgot was a classic
> example of the hostility in Emacs towards packages some maintainers
> dislike... (https://github.com/joaotavora/eglot/issues/42)

I don't know how you infer, but again, it would be nice to keep the
discussion here on-topic instead of bringing up old drama between
GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.

>> but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is.
>
> Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
> flycheck by default for its error diagnostics. I'm not a big LSP user,
> though, and often prefer the simplicity of just shelling out to
> whatever lint tools I need.

The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
problem in this case.

> You probably know that Flycheck is one of the most download packages
> on MELPA, so it has plenty of happy users. 

I do not follow MELPA development or statistics, but from what I recall
these are just accumulated downloads over all versions, right?  If so,
then the information we get from this fact is rather low.

(BTW. if we are to implement this feature for ELPA, then we should pay
attention to avoid this mistake, and only display the download counts
over some fixed time interval, e.g. the information currently available
in the access logs.)

>                                            
>                                            I'm one of them and that's
> why I took over the maintenance of the project. I felt that NonGNU
> ELPA existed to make it easier for popular stuff to be installed by
> users, but it seems to me MELPA won't be going away any time soon.

NonGNU ELPA is not only a means of making more useful packages readily
available to users OOTB (without having to search online blogs and fora
for code snippets that enable third-party archives and install dozens of
weirdly named packages replicating built-in functionality), but also a
chance to clean up the package landscape, and prune away some
experiments from the 2010s.  As you say, people will continue
maintaining third-party repositories that accept every brittle little
scripts anyone writes (I speak here from experience and personal
suffering), but I think it is a feature that ELPA has a more curated
policy.  I for my really try my best to raise the bar of package
submissions, and while it is not always easy, I hope that this helps
make the system more robust for everyone.  So once more, please do not
assume malice in these discussions, I don't think anyone here hates one
another or intentionally wants to hinder them personally.  It takes
effort to take others seriously, but it is worth undertaking if we want
to make Emacs better.

To this end, I repeat my question: What _technical functionality_ does
Flycheck _currently_ provide that Flymake does not?  A different way of
putting it is what architectural advantages does Flycheck exemplify over
Flymake, that give it an inherent edge?  If there aren't too many
differences, I think the cost of confusion (Flymake and Flycheck are
names that are easy to confuse) and of inducing choice-fatigue among new
users is not something we should ignore.

> On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> > Hey everyone,
>> >
>> > Just wanted to ask if there's any interested in adding Flycheck
>> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> > Flymake, to NonGNU ELPA?
>> >
>> > You can find the codebase here https://github.com/flycheck/flycheck
>> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>> >
>> > I'm not sure what's the stance of adding alternatives to built-in
>> > packages in general, but I think providing some alternatives to the
>> > end users is not a bad thing overall.
>> 
>> My main question is what advantage Flycheck has over Flymake.  I
>> understand it has a database of tools built-in, but considering that
>> more and more people rely on LSP for the information (and Eglot supports
>> Flymake OOTB), I don't know how valuable this is.  In addition to that,
>> there are projects like
>> 
>> https://github.com/mohkale/flymake-collection
>> https://github.com/purcell/flymake-flycheck
>> 
>> that could help bridge the gap.
>> 
>> 

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

> For the sake of a constructive discussion, please don't make claims like
> these without any further references.  Provocations like these, from
> anyone, only make discussions like these more difficult.

Oh, damn - I mixed a private thread with Philip and the message I had sent here. (I had reached out to him before posting here, as I was hoping to avoid a public thread on the topic) :double-facepalm: Anyways, that's on me.

> I do not follow MELPA development or statistics, but from what I recall
> these are just accumulated downloads over all versions, right?  If so,
> then the information we get from this fact is rather low.

Fair enough. Still, you don't get to #4 in the all-time rankings on past usage alone. I'm sorry that I can't provide better usage metrics to support my case. 

> Could you explain how this relates to the current state of Flymake
> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
> deprecated Flycheck, seems like a success story.

I'm afraid I don't have the time to do a detailed research on the current state of Flymake. I haven't written the comparison page myself and I agree some points there are small/subjective. I'm not sure how you came to the conclusion that Flycheck got deprecated, though. Any analysis that I would do would be subjective of course, from mine perspective and from yours, so I think it wouldn't change anything.  

To be clear I don't want to argue which project is better and what are the merits of Flycheck over Flymake, if any. If it's so big of a deal to have packages that duplicate core functionality in the official repos - fine.

> As you say, people will continue
> maintaining third-party repositories that accept every brittle little
> scripts anyone writes (I speak here from experience and personal
> suffering), but I think it is a feature that ELPA has a more curated
> policy.  I for my really try my best to raise the bar of package
> submissions, and while it is not always easy, I hope that this helps
> make the system more robust for everyone. 

I get your point about quality, but here we're not talking about some random package of questionable provenance. You can inspect the codebase yourself if you want, but (subjectively speaking) has fairly clean codebase, lots of unit tests, and very detailed documentation. (and a sizeable, if hard to measure user-base) Flymake's docs (https://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html) are pretty basic compared to Flycheck's so I feel you're applying double standards here. 

Anyways, I had a feeling I'd regret asking for the inclusion of Flycheck. I'll take is that my answer is "No".

I really don't want to turn this into some heated debate, so we can just wrap up here. 

On Mon, Feb 19, 2024, at 8:53 PM, Philip Kaludercic wrote:
> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> 
> > There is a detailed comparison here
> > https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html
> 
> From what I see, this comparison is outdated and somewhat one-sided.
> Flymake has error explanations, and categories like "Automatic syntax
> checking" seem disingenuous if the complaint is that there is not a
> flymake-global-mode.  (It would have probably taken less time to write a
> `define-globalized-minor-mode', than the time to write this point...)
> 
> > but many of the differences are probably not important to many
> > people. You might remember that before Flycheck, Flymake was in a
> > state of disarray and abandoment for years, so I'm pretty sure
> > Flycheck making it almost obsolete back then was the trigger for some
> > modernization around Emacs 26.1. 
> 
> Could you explain how this relates to the current state of Flymake
> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
> deprecated Flycheck, seems like a success story.
> 
> >                                  And the contributors to Flycheck and
> > Flymake were always pretty different - part of the reason Sebastien
> > (the original author of Flycheck) quit Emacs were some attacks he was
> > getting on emacs-devel.
> 
> For the sake of a constructive discussion, please don't make claims like
> these without any further references.  Provocations like these, from
> anyone, only make discussions like these more difficult.
> 
> > Many people are so off-put by the discourse there, that they want to
> > have as little as possible with it. And that's the real value of
> > alternative packages IMO - they allow us to harvest the energy of all
> > contributors.
> 
> I don't think this is the problem you are making it out to be, and even
> if it were, one could have a package like flymake-collection added to
> NonGNU ELPA.
> 
> > Btw, flymake-flycheck was created only because Joao wouldn't agree to
> > provide Flycheck support in Eglot (I know this from the author of
> > flymake-flycheck). The whole situation with Elgot was a classic
> > example of the hostility in Emacs towards packages some maintainers
> > dislike... (https://github.com/joaotavora/eglot/issues/42)
> 
> I don't know how you infer, but again, it would be nice to keep the
> discussion here on-topic instead of bringing up old drama between
> GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.
> 
> >> but considering that
> >> more and more people rely on LSP for the information (and Eglot supports
> >> Flymake OOTB), I don't know how valuable this is.
> >
> > Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
> > flycheck by default for its error diagnostics. I'm not a big LSP user,
> > though, and often prefer the simplicity of just shelling out to
> > whatever lint tools I need.
> 
> The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
> problem in this case.
> 
> > You probably know that Flycheck is one of the most download packages
> > on MELPA, so it has plenty of happy users. 
> 
> I do not follow MELPA development or statistics, but from what I recall
> these are just accumulated downloads over all versions, right?  If so,
> then the information we get from this fact is rather low.
> 
> (BTW. if we are to implement this feature for ELPA, then we should pay
> attention to avoid this mistake, and only display the download counts
> over some fixed time interval, e.g. the information currently available
> in the access logs.)
> 
> >                                            
> >                                            I'm one of them and that's
> > why I took over the maintenance of the project. I felt that NonGNU
> > ELPA existed to make it easier for popular stuff to be installed by
> > users, but it seems to me MELPA won't be going away any time soon.
> 
> NonGNU ELPA is not only a means of making more useful packages readily
> available to users OOTB (without having to search online blogs and fora
> for code snippets that enable third-party archives and install dozens of
> weirdly named packages replicating built-in functionality), but also a
> chance to clean up the package landscape, and prune away some
> experiments from the 2010s.  As you say, people will continue
> maintaining third-party repositories that accept every brittle little
> scripts anyone writes (I speak here from experience and personal
> suffering), but I think it is a feature that ELPA has a more curated
> policy.  I for my really try my best to raise the bar of package
> submissions, and while it is not always easy, I hope that this helps
> make the system more robust for everyone.  So once more, please do not
> assume malice in these discussions, I don't think anyone here hates one
> another or intentionally wants to hinder them personally.  It takes
> effort to take others seriously, but it is worth undertaking if we want
> to make Emacs better.
> 
> To this end, I repeat my question: What _technical functionality_ does
> Flycheck _currently_ provide that Flymake does not?  A different way of
> putting it is what architectural advantages does Flycheck exemplify over
> Flymake, that give it an inherent edge?  If there aren't too many
> differences, I think the cost of confusion (Flymake and Flycheck are
> names that are easy to confuse) and of inducing choice-fatigue among new
> users is not something we should ignore.
> 
> > On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
> >> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> >> 
> >> > Hey everyone,
> >> >
> >> > Just wanted to ask if there's any interested in adding Flycheck
> >> > (https://www.flycheck.org/en/latest/), a popular alternative to
> >> > Flymake, to NonGNU ELPA?
> >> >
> >> > You can find the codebase here https://github.com/flycheck/flycheck
> >> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
> >> >
> >> > I'm not sure what's the stance of adding alternatives to built-in
> >> > packages in general, but I think providing some alternatives to the
> >> > end users is not a bad thing overall.
> >> 
> >> My main question is what advantage Flycheck has over Flymake.  I
> >> understand it has a database of tools built-in, but considering that
> >> more and more people rely on LSP for the information (and Eglot supports
> >> Flymake OOTB), I don't know how valuable this is.  In addition to that,
> >> there are projects like
> >> 
> >> https://github.com/mohkale/flymake-collection
> >> https://github.com/purcell/flymake-flycheck
> >> 
> >> that could help bridge the gap.
> >> 
> >> 
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

Ops, this was meant to be a private message to Philip as we were speaking about this matter earlier. My bad! (2 threads with more or less the same title)

On Mon, Feb 19, 2024, at 8:48 PM, Eli Zaretskii wrote:
> > Date: Mon, 19 Feb 2024 20:08:15 +0200
> > From: "Bozhidar Batsov" <bozhidar@batsov.dev>
> > Cc: "Emacs Devel" <emacs-devel@gnu.org>
> > 
> > Btw, flymake-flycheck was created only because Joao wouldn't agree to provide Flycheck support in Eglot (I
> > know this from the author of flymake-flycheck). The whole situation with Elgot was a classic example of the
> > hostility in Emacs towards packages some maintainers dislike...
> > (https://github.com/joaotavora/eglot/issues/42)
> 
> To set the record straight: that issue is from 2018, full 4 years
> before Eglot was added to Emacs.  So I don't see how any incident from
> back then could be considered "a classic example of hostility in
> Emacs".
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 19/02/2024 20:53, Philip Kaludercic wrote:
> To this end, I repeat my question: What_technical functionality_  does
> Flycheck_currently_  provide that Flymake does not?  A different way of
> putting it is what architectural advantages does Flycheck exemplify over
> Flymake, that give it an inherent edge?  If there aren't too many
> differences, I think the cost of confusion (Flymake and Flycheck are
> names that are easy to confuse) and of inducing choice-fatigue among new
> users is not something we should ignore.

I'm fairly sure the main answer is "lots of built-in checkers", much 
more than flymake still has now.

It also has a minor mode map, to invoke the errors buffer or jump 
between the errors. Though the latter is easy-ish to port over.

On the subject of choice fatigue, would we hesitate to include lsp-mode 
in NonGNU ELPA, now that Eglot is in the core? I feel that would be the 
wrong move.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 19/02/2024 20:08, Bozhidar Batsov wrote:
> And the contributors to Flycheck and Flymake were always pretty 
> different - part of the reason Sebastien (the original author of 
> Flycheck) quit Emacs were some attacks he was getting on emacs-devel.

Speaking of attacks, I don't remember anything significant.

Sebastian's decision to shut the project down was quite a surprise at 
the time.

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

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

>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references.  Provocations like these, from
>> anyone, only make discussions like these more difficult.
>
> Oh, damn - I mixed a private thread with Philip and the message I had
> sent here. (I had reached out to him before posting here, as I was
> hoping to avoid a public thread on the topic) :double-facepalm:
> Anyways, that's on me.

No worries.  I prefer public conversations anyway, saves me from the
burden of archiving for myself ;)

>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right?  If so,
>> then the information we get from this fact is rather low.
>
> Fair enough. Still, you don't get to #4 in the all-time rankings on
> past usage alone. I'm sorry that I can't provide better usage metrics
> to support my case.

I get what you mean, but what is really missing is growth statistics,
specifically w.r.t. new, manual installations.  MELPA also inflates for
packages that commit a lot, since they have more "releases", hence more
updates, and hence finally more downloads.  We can certainly conclude
that it is a package that people payed attention to, but I just want to
avoid inferring too much from that.

>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>
> I'm afraid I don't have the time to do a detailed research on the
> current state of Flymake. I haven't written the comparison page myself
> and I agree some points there are small/subjective. I'm not sure how
> you came to the conclusion that Flycheck got deprecated, though. 

Sorry, "deprecated" should have been in quotes;  perhaps "superseded"
would be the more appropriate term.  My point is just that there was a
time where Flycheck had advantages, in a certain milieu, but I think
that period is over and that is good.

>                                                                  Any
> analysis that I would do would be subjective of course, from mine
> perspective and from yours, so I think it wouldn't change anything.
>
> To be clear I don't want to argue which project is better and what are
> the merits of Flycheck over Flymake, if any. If it's so big of a deal
> to have packages that duplicate core functionality in the official
> repos - fine.

I'd qualify this as "duplicate existing functionality provided via ELPA,
without providing a characteristic advantage".  The fact that Flymake is
built-in is an important, but secondary point.

>> As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy.  I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone. 
>
> I get your point about quality, but here we're not talking about some
> random package of questionable provenance. You can inspect the
> codebase yourself if you want, but (subjectively speaking) has fairly
> clean codebase, lots of unit tests, and very detailed
> documentation. (and a sizeable, if hard to measure user-base)
> Flymake's docs
> (https://www.gnu.org/software/emacs/manual/html_node/emacs/Flymake.html)
> are pretty basic compared to Flycheck's so I feel you're applying
> double standards here.

(I really can't write) My above comment was on MELPA in general,
specifically deriving from my first few years of using Emacs before
getting into development (~2014-2020) -- a position I would argue that
most core developers /and/ MELPA contributors have not experienced --
and the issues and misconceptions I had to overcome.  While I cannot
recall any specific breakage related to Flycheck, the mentality of
having to install everything from MELPA, without properly studying the
documentation or understanding the potential synergy that Emacs can
provide, did keep me back for a long time, and as I regularly observe,
hinders others from advancing as well.  But that is a topic for another
thread, that should probably take place on some other mailing list...

> Anyways, I had a feeling I'd regret asking for the inclusion of Flycheck. I'll take is that my answer is "No".
>
> I really don't want to turn this into some heated debate, so we can just wrap up here. 

OK, thank you anyway for the idea.

> On Mon, Feb 19, 2024, at 8:53 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> > There is a detailed comparison here
>> > https://www.flycheck.org/en/latest/user/flycheck-versus-flymake.html
>> 
>> From what I see, this comparison is outdated and somewhat one-sided.
>> Flymake has error explanations, and categories like "Automatic syntax
>> checking" seem disingenuous if the complaint is that there is not a
>> flymake-global-mode.  (It would have probably taken less time to write a
>> `define-globalized-minor-mode', than the time to write this point...)
>> 
>> > but many of the differences are probably not important to many
>> > people. You might remember that before Flycheck, Flymake was in a
>> > state of disarray and abandoment for years, so I'm pretty sure
>> > Flycheck making it almost obsolete back then was the trigger for some
>> > modernization around Emacs 26.1. 
>> 
>> Could you explain how this relates to the current state of Flymake
>> vs. Flycheck?  The fact that Flymake caught up, and in my eyes
>> deprecated Flycheck, seems like a success story.
>> 
>> >                                  And the contributors to Flycheck and
>> > Flymake were always pretty different - part of the reason Sebastien
>> > (the original author of Flycheck) quit Emacs were some attacks he was
>> > getting on emacs-devel.
>> 
>> For the sake of a constructive discussion, please don't make claims like
>> these without any further references.  Provocations like these, from
>> anyone, only make discussions like these more difficult.
>> 
>> > Many people are so off-put by the discourse there, that they want to
>> > have as little as possible with it. And that's the real value of
>> > alternative packages IMO - they allow us to harvest the energy of all
>> > contributors.
>> 
>> I don't think this is the problem you are making it out to be, and even
>> if it were, one could have a package like flymake-collection added to
>> NonGNU ELPA.
>> 
>> > Btw, flymake-flycheck was created only because Joao wouldn't agree to
>> > provide Flycheck support in Eglot (I know this from the author of
>> > flymake-flycheck). The whole situation with Elgot was a classic
>> > example of the hostility in Emacs towards packages some maintainers
>> > dislike... (https://github.com/joaotavora/eglot/issues/42)
>> 
>> I don't know how you infer, but again, it would be nice to keep the
>> discussion here on-topic instead of bringing up old drama between
>> GNU-adjacent/core development and MELPA/GitHub/anti-GNU people.
>> 
>> >> but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is.
>> >
>> > Btw, Eglot is not the only LSP client for Emacs. :-) lsp-mode users
>> > flycheck by default for its error diagnostics. I'm not a big LSP user,
>> > though, and often prefer the simplicity of just shelling out to
>> > whatever lint tools I need.
>> 
>> The "lsp-mode" is not part of NonGNU ELPA, so I don't think that is a
>> problem in this case.
>> 
>> > You probably know that Flycheck is one of the most download packages
>> > on MELPA, so it has plenty of happy users. 
>> 
>> I do not follow MELPA development or statistics, but from what I recall
>> these are just accumulated downloads over all versions, right?  If so,
>> then the information we get from this fact is rather low.
>> 
>> (BTW. if we are to implement this feature for ELPA, then we should pay
>> attention to avoid this mistake, and only display the download counts
>> over some fixed time interval, e.g. the information currently available
>> in the access logs.)
>> 
>> >                                            
>> >                                            I'm one of them and that's
>> > why I took over the maintenance of the project. I felt that NonGNU
>> > ELPA existed to make it easier for popular stuff to be installed by
>> > users, but it seems to me MELPA won't be going away any time soon.
>> 
>> NonGNU ELPA is not only a means of making more useful packages readily
>> available to users OOTB (without having to search online blogs and fora
>> for code snippets that enable third-party archives and install dozens of
>> weirdly named packages replicating built-in functionality), but also a
>> chance to clean up the package landscape, and prune away some
>> experiments from the 2010s.  As you say, people will continue
>> maintaining third-party repositories that accept every brittle little
>> scripts anyone writes (I speak here from experience and personal
>> suffering), but I think it is a feature that ELPA has a more curated
>> policy.  I for my really try my best to raise the bar of package
>> submissions, and while it is not always easy, I hope that this helps
>> make the system more robust for everyone.  So once more, please do not
>> assume malice in these discussions, I don't think anyone here hates one
>> another or intentionally wants to hinder them personally.  It takes
>> effort to take others seriously, but it is worth undertaking if we want
>> to make Emacs better.
>> 
>> To this end, I repeat my question: What _technical functionality_ does
>> Flycheck _currently_ provide that Flymake does not?  A different way of
>> putting it is what architectural advantages does Flycheck exemplify over
>> Flymake, that give it an inherent edge?  If there aren't too many
>> differences, I think the cost of confusion (Flymake and Flycheck are
>> names that are easy to confuse) and of inducing choice-fatigue among new
>> users is not something we should ignore.
>> 
>> > On Mon, Feb 19, 2024, at 7:44 PM, Philip Kaludercic wrote:
>> >> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> >> 
>> >> > Hey everyone,
>> >> >
>> >> > Just wanted to ask if there's any interested in adding Flycheck
>> >> > (https://www.flycheck.org/en/latest/), a popular alternative to
>> >> > Flymake, to NonGNU ELPA?
>> >> >
>> >> > You can find the codebase here https://github.com/flycheck/flycheck
>> >> > There's also some integration with Eglot https://github.com/flycheck/flycheck-eglot
>> >> >
>> >> > I'm not sure what's the stance of adding alternatives to built-in
>> >> > packages in general, but I think providing some alternatives to the
>> >> > end users is not a bad thing overall.
>> >> 
>> >> My main question is what advantage Flycheck has over Flymake.  I
>> >> understand it has a database of tools built-in, but considering that
>> >> more and more people rely on LSP for the information (and Eglot supports
>> >> Flymake OOTB), I don't know how valuable this is.  In addition to that,
>> >> there are projects like
>> >> 
>> >> https://github.com/mohkale/flymake-collection
>> >> https://github.com/purcell/flymake-flycheck
>> >> 
>> >> that could help bridge the gap.
>> >> 
>> >> 
>> 
>> 

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

My memory is fuzzy as well, but I recall some sparks here https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html I also vaguely recall that he didn't like the vibe of a part of the Emacs community and this was a factor in his ultimate decision to quit Emacs. It's a pity - for me he was a really great Elisp hacker and package maintainer. 

On Mon, Feb 19, 2024, at 9:33 PM, Dmitry Gutov wrote:
> On 19/02/2024 20:08, Bozhidar Batsov wrote:
> > And the contributors to Flycheck and Flymake were always pretty 
> > different - part of the reason Sebastien (the original author of 
> > Flycheck) quit Emacs were some attacks he was getting on emacs-devel.
> 
> Speaking of attacks, I don't remember anything significant.
> 
> Sebastian's decision to shut the project down was quite a surprise at 
> the time.
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Dominik Schrempf]

Coming back to the topic --- A user story: I am an =lsp-mode= user, just
because it is more feature rich than =eglot=. In particular,
=lsp-ui-sideline= does a great job in displaying errors on the side of
buffers. I can only use this feature with =flycheck=. When using
=flymake=, the only way to display error messages is the minibuffer.
(There might and will be hacks that I am not aware of). Since many
compilation errors involve long messages, this is too crowded for my
taste.

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

> My memory is fuzzy as well, but I recall some sparks here
> https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html I also
> vaguely recall that he didn't like the vibe of a part of the Emacs community and
> this was a factor in his ultimate decision to quit Emacs. It's a pity - for me
> he was a really great Elisp hacker and package maintainer.
>
> On Mon, Feb 19, 2024, at 9:33 PM, Dmitry Gutov wrote:
>
>     On 19/02/2024 20:08, Bozhidar Batsov wrote:
>     > And the contributors to Flycheck and Flymake were always pretty
>     > different - part of the reason Sebastien (the original author of
>     > Flycheck) quit Emacs were some attacks he was getting on emacs-devel.
>
>     Speaking of attacks, I don't remember anything significant.
>
>     Sebastian's decision to shut the project down was quite a surprise at
>     the time.

Re: Adding Flycheck to NonGNU ELPA

[joakim]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 19/02/2024 20:53, Philip Kaludercic wrote:
>> To this end, I repeat my question: What_technical functionality_  does
>> Flycheck_currently_  provide that Flymake does not?  A different way of
>> putting it is what architectural advantages does Flycheck exemplify over
>> Flymake, that give it an inherent edge?  If there aren't too many
>> differences, I think the cost of confusion (Flymake and Flycheck are
>> names that are easy to confuse) and of inducing choice-fatigue among new
>> users is not something we should ignore.
>
> I'm fairly sure the main answer is "lots of built-in checkers", much
> more than flymake still has now.
>
> It also has a minor mode map, to invoke the errors buffer or jump
> between the errors. Though the latter is easy-ish to port over.
>
> On the subject of choice fatigue, would we hesitate to include
> lsp-mode in NonGNU ELPA, now that Eglot is in the core? I feel that
> would be the wrong move.

My 2 ören is that it is normal for there to exist several different
Emacs packages that provide similar functionality, and this goes for
more or less any functionality you can think of.

In my case I like to try all the different alternatives at once, so I
write some code to be able to switch between the alternatives on the
fly, until I feel I like one of the alternatives more than the others.

I did this for the gazillion of completion options out there until I
wound up with Vertico, and for the different fancy Modelines until I
just reverted to the OOTB modeline. 

Its not really easy to write such feature switching code reliably
however. Sometimes you wind up in the tedium of rebooting Emacs. (not
too bad though, this Emacs has 80 day uptime)

Maybe having more alternatives in Elpa/Melpa would actually lead to more
code re-use between the alternatives? That would be nice but I guess
history indicates otherwise.

PS

Heres an example of the ugly code I wrote, I used the "daf" prefix for
"dumb alternatives framework". Again, super ugly, but it kinda
illustrates that its not super obvious how to change between similar implementations.

      (defun daf-ivy ()
        "Switch to ivy."
        (interactive)
        (helm-mode -1)
        (ivy-mode 1)
        (counsel-mode 1)

        (counsel-projectile-mode)

        (global-set-key (kbd "M-x") 'counsel-M-x)
        (global-set-key (kbd "C-x C-f") 'counsel-find-file)
        (global-set-key (kbd "M-s M-s") 'swiper)
        (global-set-key (kbd "M-y")     'counsel-yank-pop)
        (global-set-key (kbd "C-x b") 'ivy-switch-buffer)
        (setq read-file-name-function 'read-file-name-default)
        (all-the-icons-ivy-setup)
        )

      ;; use flex matching in ivy. its cool!
      ;; but maybe swiper should have another valuse
      ;; (setq ivy-re-builders-alist
      ;;       '((t . ivy--regex-fuzzy)))

      ;;also u can change the re-builder on the fly
      (setq ivy-re-builders-alist
            '((swiper . ivy--regex-plus)
            (t . ivy--regex-plus)
              (fuzzy      . ivy--regex-fuzzy)))

      (setq ivy-initial-inputs-alist nil)


      (defun daf-helm ()
        "Switch to helm."
        (interactive)
        (ivy-mode -1)
        (helm-mode 1)

        (global-set-key (kbd "M-x") 'helm-M-x)
        (global-set-key (kbd "C-x C-f") 'helm-find-files)
        (global-set-key (kbd "M-s M-s") 'helm-swoop)
        (global-set-key (kbd "M-y")     'helm-show-kill-ring)
        (global-set-key (kbd "C-x b") 'helm-mini)
        ;;(setq read-file-name-function 'read-file-name-default);; for helm?



-- 
Joakim Verona
joakim@verona.se

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 19/02/2024 21:47, Bozhidar Batsov wrote:
> My memory is fuzzy as well, but I recall some sparks here 
> https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html 
> <https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html> I 
> also vaguely recall that he didn't like the vibe of a part of the Emacs 
> community and this was a factor in his ultimate decision to quit Emacs. 
> It's a pity - for me he was a really great Elisp hacker and package 
> maintainer.

But I'm not seeing the "attacks" here still. If the discussion is tense 
after he both states Flycheck's strict superiority and his firm decision 
never to contribute to Emacs, well, that's kind of expected.

But not to the extent that could explain the phrasing in his subsequent 
blog post (now long removed). I was puzzled; he never responded to my 
comments then. And yes, he's pretty great hacker, so it's all quite sad.

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

I think there's no point in discussing this on the mailing list, as it's off off-topic (and the topic seems mostly closed). 

On Tue, Feb 20, 2024, at 1:21 AM, Dmitry Gutov wrote:
> On 19/02/2024 21:47, Bozhidar Batsov wrote:
> > My memory is fuzzy as well, but I recall some sparks here 
> > https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html 
> > <https://lists.gnu.org/archive/html/emacs-devel/2013-12/msg00552.html> I 
> > also vaguely recall that he didn't like the vibe of a part of the Emacs 
> > community and this was a factor in his ultimate decision to quit Emacs. 
> > It's a pity - for me he was a really great Elisp hacker and package 
> > maintainer.
> 
> But I'm not seeing the "attacks" here still. If the discussion is tense 
> after he both states Flycheck's strict superiority and his firm decision 
> never to contribute to Emacs, well, that's kind of expected.
> 
> But not to the extent that could explain the phrasing in his subsequent 
> blog post (now long removed). I was puzzled; he never responded to my 
> comments then. And yes, he's pretty great hacker, so it's all quite sad.
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

joakim@verona.se writes:


[...]

> Maybe having more alternatives in Elpa/Melpa would actually lead to more
> code re-use between the alternatives? That would be nice but I guess
> history indicates otherwise.

I am afraid that this is not the case, instead of leads to more glue
code having to be written.  If we want to be more efficient, we should
focus on promoting generic interfaces (Xref, Imenu, Flymake, ...) and
writing back-end implementations.  As an added bonus, we improve the
consistency of the user experience.

If Flycheck were to use the same interface as Flymake, then the
situation would be better, as it would only be a different UI with
perhaps some other priorities.

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 19/02/2024 21:52, Philip Kaludercic wrote:
>> Dmitry Gutov <dmitry@gutov.dev> writes:
>> 
>>> On 19/02/2024 20:53, Philip Kaludercic wrote:
>>>> To this end, I repeat my question: What_technical functionality_  does
>>>> Flycheck_currently_  provide that Flymake does not?  A different way of
>>>> putting it is what architectural advantages does Flycheck exemplify over
>>>> Flymake, that give it an inherent edge?  If there aren't too many
>>>> differences, I think the cost of confusion (Flymake and Flycheck are
>>>> names that are easy to confuse) and of inducing choice-fatigue among new
>>>> users is not something we should ignore.
>>>
>>> I'm fairly sure the main answer is "lots of built-in checkers", much
>>> more than flymake still has now.
>> Do you think that adding "flymake-collection" to NonGNU ELPA could
>> help
>> improve the situation sufficiently?  See also
>> https://github.com/mohkale/flymake-collection/issues/2.
>
> It might be an improvement, but AFAIK Flycheck still has an order of a
> magnitude more checkers.
>
> Offhand,
> https://github.com/mohkale/flymake-collection/tree/release/src/checkers
> doesn't include anything for Rust or Golang.
>
> And Flycheck has several for both.

This appears to be true, but this is not an inherent advantage, just the
fact that people have invested effort into it.  It seems to be that a
significant reason is that Flycheck has a convenient language for
defining checkers, something that IIUC flymake-collection is also
working on.  Giving this basis, we could look into perhaps even
automatically translating the Checker specifications, which would help
further "obsolete" Flycheck, given that this is apparently the only real
"advantage" it provides (which again, is not architectural, just the
accumulated labour over the last decade).

>>> It also has a minor mode map, to invoke the errors buffer or jump
>>> between the errors. Though the latter is easy-ish to port over.
>> I agree, that that is an annoyance.  I have personally bound
>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
>> respectively, but it would be nice if we could find some keys to bind
>> these commands to.
>
> Same.

I'll look into submitting a bug report to propose such a change.

>>> On the subject of choice fatigue, would we hesitate to include
>>> lsp-mode in NonGNU ELPA, now that Eglot is in the core? I feel that
>>> would be the wrong move.
>> FWIW I would argue against it.  Setting aside issues of
>> dependencies, it
>> is my impression that the "lsp-mode" tries to superficially convert
>> Emacs into some VSCode like experience, introducing a lot of transient
>> information that cannot be operated on normally, popup windows that
>> cannot be selected/persisted/searched or otherwise re-creating UI
>> features that already exist in Emacs.
>
> Are we going to police UIs now?

I wouldn't put it that way, but as mentioned above I do think that
pushing towards a consistent UI that aligns with Emacs strengths
(text-based, buffers in windows, ...) is worth the effort, even if some
projects have to change or die in the process.  E.g. a positive example:
I added support for the "dumb-jump" to use Xref instead of
re-implementing the UI with custom commands and popups.  People appear
to use that now.

> Let's remove Helm from NonGNU, then: its UI paradigm is also different
> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
> ELPA, just because.

While I am not a fan of Helm, it was initially added to provide popular
packages that a number of people appeared to want to use.  Luckily these
packages fall into the category of providing the front-end of a shared
interface (completing-read; and that not without issues, because they
tend to abuse completing-read's text expansion idea by focusing on
narrowing and selecting).  And yes, there are packages that have hard
dependencies on Helm, but usually when people submit these kinds of
packages, we at least mention the idea of trying to generalise them, so
that the front- and back-end can be disentangled from one another.

> lsp-mode is not just eye candy anyway.
>
> Just as I've discovered last week (I'm not a heavy user of either), it
> has a handy test runner integration and more reliable errors reporting
> (for syntax, etc). And that's with Flymake.
>
> Also, it's average latency for completion was lower in my benchmarking
> not too long ago. Though that's probably the fault of Eglot's
> expensive pretty-printing in logging.
>
> And the popup windows are easily turned off.

I know that there are differences, and I hope that the situation
improves, but to mention another negative that probably disqualifies
adding the package just on its own: `lsp-install-server'.  The command
can download arbitrary executable files as servers and runs them
locally.  From what I see there is no reference to any software licenses
or where to find the source code.  To be fair, this is partially due to
the mentality that Microsoft had when writing VSCode (remember that a
number of the most popular extensions and servers written by Microsoft
are explicitly non-free software that must be used together with the
official signed release of VSCode), which the "lsp-mode" developers
appears to accept uncritically.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 20/02/2024 13:48, Philip Kaludercic wrote:

> If Flycheck were to use the same interface as Flymake, then the
> situation would be better, as it would only be a different UI with
> perhaps some other priorities.

Flycheck uses macros to define checkers and output parsers. Perhaps one 
day those could expand to Flymake's functional interface under the 
covers, but for that to happen, it would help a lot if we were more 
welcoming.

>> It might be an improvement, but AFAIK Flycheck still has an order of a
>> magnitude more checkers.
>>
>> Offhand,
>> https://github.com/mohkale/flymake-collection/tree/release/src/checkers
>> doesn't include anything for Rust or Golang.
>>
>> And Flycheck has several for both.
> 
> This appears to be true, but this is not an inherent advantage, just the
> fact that people have invested effort into it.  It seems to be that a
> significant reason is that Flycheck has a convenient language for
> defining checkers, something that IIUC flymake-collection is also
> working on.  Giving this basis, we could look into perhaps even
> automatically translating the Checker specifications, which would help
> further "obsolete" Flycheck, given that this is apparently the only real
> "advantage" it provides (which again, is not architectural, just the
> accumulated labour over the last decade).

Nobody stops people from working on Flymake, improving the documentation 
and developer experience, and the list of built-in checkers.

In fact, I'm pretty sure this will happen faster with healthy 
competition in sight.

>>>> It also has a minor mode map, to invoke the errors buffer or jump
>>>> between the errors. Though the latter is easy-ish to port over.
>>> I agree, that that is an annoyance.  I have personally bound
>>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
>>> respectively, but it would be nice if we could find some keys to bind
>>> these commands to.
>>
>> Same.
> 
> I'll look into submitting a bug report to propose such a change.

Very good.

> I wouldn't put it that way, but as mentioned above I do think that
> pushing towards a consistent UI that aligns with Emacs strengths
> (text-based, buffers in windows, ...) is worth the effort, even if some
> projects have to change or die in the process.  E.g. a positive example:
> I added support for the "dumb-jump" to use Xref instead of
> re-implementing the UI with custom commands and popups.  People appear
> to use that now.

Note that when Xref was introduced, there were no existing protocols out 
there, in third-party packages or not, that could be used for the same 
purpose (abstraction over code navigation sources).

A counter-example is Projectile, which predated project.el, and which we 
included in NonGNU ELPA to no particular detriment.

>> Let's remove Helm from NonGNU, then: its UI paradigm is also different
>> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
>> ELPA, just because.
> 
> While I am not a fan of Helm, it was initially added to provide popular
> packages that a number of people appeared to want to use.  Luckily these
> packages fall into the category of providing the front-end of a shared
> interface (completing-read; and that not without issues, because they
> tend to abuse completing-read's text expansion idea by focusing on
> narrowing and selecting).

Yes, Helm provides some support for completing-read, but it also has its 
own specific API which is bigger and more tailored for its UI, and is 
the reason there are Helm-specific plugins.

> And yes, there are packages that have hard
> dependencies on Helm, but usually when people submit these kinds of
> packages, we at least mention the idea of trying to generalise them, so
> that the front- and back-end can be disentangled from one another.

We can both accept Flycheck and suggest the maintainers work toward 
someday having a compatible API, at least on the functional level.

> I know that there are differences, and I hope that the situation
> improves, but to mention another negative that probably disqualifies
> adding the package just on its own: `lsp-install-server'.  The command
> can download arbitrary executable files as servers and runs them
> locally.

curl can download arbitrary executable files, and it's still free 
software. The question is which urls are pre-configured.

If we come to consider the inclusion of lsp-mode seriously (meaning, 
there would be some interest from the maintainers), I'm happy to discuss 
requesting that whatever proprietary servers are configured in (I think 
there is 1 proprietary option for PHP among the total 4 available, not 
sure what else) are split off into separate packages that we don't publish.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 20/02/2024 22:04, Dmitry Gutov wrote:
> On 20/02/2024 13:48, Philip Kaludercic wrote:
> 
>> If Flycheck were to use the same interface as Flymake, then the
>> situation would be better, as it would only be a different UI with
>> perhaps some other priorities.
> 
> Flycheck uses macros to define checkers and output parsers. Perhaps one 
> day those could expand to Flymake's functional interface under the 
> covers, but for that to happen, it would help a lot if we were more 
> welcoming.

So, unless unless there is a strong objection from one of Emacs's head 
maintainers, I think I will commence Flycheck's addition to NonGNU in 
the next few days.

Re: Adding Flycheck to NonGNU ELPA

[Stefan Monnier]

> So, unless unless there is a strong objection from one of Emacs's head
> maintainers, I think I will commence Flycheck's addition to NonGNU in the
> next few days.

That would be very welcome, thanks.


        Stefan

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 20/02/2024 13:48, Philip Kaludercic wrote:
>
>> If Flycheck were to use the same interface as Flymake, then the
>> situation would be better, as it would only be a different UI with
>> perhaps some other priorities.
>
> Flycheck uses macros to define checkers and output parsers. Perhaps
> one day those could expand to Flymake's functional interface under the
> covers, but for that to happen, it would help a lot if we were more
> welcoming.

That is what flymake-collection is supposedly working on.

>>> It might be an improvement, but AFAIK Flycheck still has an order of a
>>> magnitude more checkers.
>>>
>>> Offhand,
>>> https://github.com/mohkale/flymake-collection/tree/release/src/checkers
>>> doesn't include anything for Rust or Golang.
>>>
>>> And Flycheck has several for both.
>> This appears to be true, but this is not an inherent advantage, just
>> the
>> fact that people have invested effort into it.  It seems to be that a
>> significant reason is that Flycheck has a convenient language for
>> defining checkers, something that IIUC flymake-collection is also
>> working on.  Giving this basis, we could look into perhaps even
>> automatically translating the Checker specifications, which would help
>> further "obsolete" Flycheck, given that this is apparently the only real
>> "advantage" it provides (which again, is not architectural, just the
>> accumulated labour over the last decade).
>
> Nobody stops people from working on Flymake, improving the
> documentation and developer experience, and the list of built-in
> checkers.
>
> In fact, I'm pretty sure this will happen faster with healthy
> competition in sight.

No, but effort is wasted on developing incompatible backends.  If
Flycheck could take a similar route like Company in recommending to
develop against the default/built-in interface (CAPF and Flymake
respectively), then I really wouldn't mind having a second UI, but
considering the misinformation that Flycheck still promote, I don't see
any interest from their side to converge to a common denominator.

>>>>> It also has a minor mode map, to invoke the errors buffer or jump
>>>>> between the errors. Though the latter is easy-ish to port over.
>>>> I agree, that that is an annoyance.  I have personally bound
>>>> `flymake-goto-next-error' and `flymake-goto-prev-error' to M-n and M-p
>>>> respectively, but it would be nice if we could find some keys to bind
>>>> these commands to.
>>>
>>> Same.
>> I'll look into submitting a bug report to propose such a change.
>
> Very good.
>
>> I wouldn't put it that way, but as mentioned above I do think that
>> pushing towards a consistent UI that aligns with Emacs strengths
>> (text-based, buffers in windows, ...) is worth the effort, even if some
>> projects have to change or die in the process.  E.g. a positive example:
>> I added support for the "dumb-jump" to use Xref instead of
>> re-implementing the UI with custom commands and popups.  People appear
>> to use that now.
>
> Note that when Xref was introduced, there were no existing protocols
> out there, in third-party packages or not, that could be used for the
> same purpose (abstraction over code navigation sources).

True, but that only made it easier.  If there had been some MELPA
package called "jumpy" of whatever, then some packages would support
xref, the others "jumpy", others again would have to try and support
both.  People would constantly be asking "what is the difference between
xref and jumpy", and others again wouldn't notice xref at all because
they assume that every feature in Emacs has to be installed via some
external package.

This also reminds me of another point: Xref, Flymake, CAPF, ... are all
interfaces, that don't have to bring with them implementations for all
kinds of languages.  That is the job of a major mode, and it is a lot
more reasonable for a major mode to implement this interface, if
provided by a core package, than if they had to use an third-party
package that is not even part of GNU ELPA.

> A counter-example is Projectile, which predated project.el, and which
> we included in NonGNU ELPA to no particular detriment.

FWIW I think having "Projectile" is a mistake as well (I didn't want to
voice the position at the time, because people were still belittling
NonGNU ELPA at the time), but at least the effect is not that
significant since it appears that not that many Projectile-based
packages?

>>> Let's remove Helm from NonGNU, then: its UI paradigm is also different
>>> from the core Emacs, and IMHO it's rather ugly. And swiper/ivy from
>>> ELPA, just because.
>> While I am not a fan of Helm, it was initially added to provide
>> popular
>> packages that a number of people appeared to want to use.  Luckily these
>> packages fall into the category of providing the front-end of a shared
>> interface (completing-read; and that not without issues, because they
>> tend to abuse completing-read's text expansion idea by focusing on
>> narrowing and selecting).
>
> Yes, Helm provides some support for completing-read, but it also has
> its own specific API which is bigger and more tailored for its UI, and
> is the reason there are Helm-specific plugins.

I know, having this kind of a parallel society of functionality is sad,
but as I said, it is a consequence of the way `completing-read' is used
and misunderstood.

Communicating with the package developers of these selection frameworks
to create a new interface would be an interesting task.

>> And yes, there are packages that have hard
>> dependencies on Helm, but usually when people submit these kinds of
>> packages, we at least mention the idea of trying to generalise them, so
>> that the front- and back-end can be disentangled from one another.
>
> We can both accept Flycheck and suggest the maintainers work toward
> someday having a compatible API, at least on the functional level.

I'd say that should be the sine qua non.  If I could decide, Flycheck
should be reduced to a UI, their interface should be deprecated and the
backends translated to Flymake.  That would have the best long-term
consequences for users.  But adding Flycheck just like that will
certainly just perpetuate the unnecessary schism and confusion.

>> I know that there are differences, and I hope that the situation
>> improves, but to mention another negative that probably disqualifies
>> adding the package just on its own: `lsp-install-server'.  The command
>> can download arbitrary executable files as servers and runs them
>> locally.
>
> curl can download arbitrary executable files, and it's still free
> software. The question is which urls are pre-configured.

The objection is not that lsp-mode is not free software, it is that it
doesn't respect their users by downloading arbitrary binaries from the
net and running them on their own machines, even if all the servers were
free (which I don't know, I haven't checked all of them).

> If we come to consider the inclusion of lsp-mode seriously (meaning,
> there would be some interest from the maintainers), I'm happy to
> discuss requesting that whatever proprietary servers are configured in
> (I think there is 1 proprietary option for PHP among the total 4
> available, not sure what else) are split off into separate packages
> that we don't publish.

My impression of the lsp-mode maintainers is that they have no interest
in collaborating with core development.

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 20/02/2024 22:04, Dmitry Gutov wrote:
>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>> 
>>> If Flycheck were to use the same interface as Flymake, then the
>>> situation would be better, as it would only be a different UI with
>>> perhaps some other priorities.
>> Flycheck uses macros to define checkers and output parsers. Perhaps
>> one day those could expand to Flymake's functional interface under
>> the covers, but for that to happen, it would help a lot if we were
>> more welcoming.
>
> So, unless unless there is a strong objection from one of Emacs's head
> maintainers, I think I will commence Flycheck's addition to NonGNU in
> the next few days.

Before taking this step, can we please discuss the possibility of
creating a uniform interface?  As mentioned in my previous message, this
is the crux of my complaint, and I don't even know what Bozhidar
position on the matter is.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 21/02/2024 19:01, Philip Kaludercic wrote:
> Dmitry Gutov<dmitry@gutov.dev>  writes:
> 
>> On 20/02/2024 22:04, Dmitry Gutov wrote:
>>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>>>
>>>> If Flycheck were to use the same interface as Flymake, then the
>>>> situation would be better, as it would only be a different UI with
>>>> perhaps some other priorities.
>>> Flycheck uses macros to define checkers and output parsers. Perhaps
>>> one day those could expand to Flymake's functional interface under
>>> the covers, but for that to happen, it would help a lot if we were
>>> more welcoming.
>> So, unless unless there is a strong objection from one of Emacs's head
>> maintainers, I think I will commence Flycheck's addition to NonGNU in
>> the next few days.
> Before taking this step, can we please discuss the possibility of
> creating a uniform interface?  As mentioned in my previous message, this
> is the crux of my complaint, and I don't even know what Bozhidar
> position on the matter is.

We've discussed it. Such possibility exists.

If we're going to make the implementation of it as a prerequisite for 
merging, however, I imagine that's just not going to happen. Flycheck's 
contributors will go back to their own bubble, and we'll stay in ours.

Those are my expectations both from experience, and from the current 
mood of the people involved.

Re: Adding Flycheck to NonGNU ELPA

[Stefan Monnier]

> Before taking this step, can we please discuss the possibility of
> creating a uniform interface?

That's orthogonal.


        Stefan

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 21/02/2024 19:01, Philip Kaludercic wrote:
>> Dmitry Gutov<dmitry@gutov.dev>  writes:
>> 
>>> On 20/02/2024 22:04, Dmitry Gutov wrote:
>>>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>>>>
>>>>> If Flycheck were to use the same interface as Flymake, then the
>>>>> situation would be better, as it would only be a different UI with
>>>>> perhaps some other priorities.
>>>> Flycheck uses macros to define checkers and output parsers. Perhaps
>>>> one day those could expand to Flymake's functional interface under
>>>> the covers, but for that to happen, it would help a lot if we were
>>>> more welcoming.
>>> So, unless unless there is a strong objection from one of Emacs's head
>>> maintainers, I think I will commence Flycheck's addition to NonGNU in
>>> the next few days.
>> Before taking this step, can we please discuss the possibility of
>> creating a uniform interface?  As mentioned in my previous message,
>> this
>> is the crux of my complaint, and I don't even know what Bozhidar
>> position on the matter is.
>
> We've discussed it. Such possibility exists.

Who is we?

> If we're going to make the implementation of it as a prerequisite for
> merging, however, I imagine that's just not going to
> happen. Flycheck's contributors will go back to their own bubble, and
> we'll stay in ours.

As you might guess, I don't consider this a problem.

> Those are my expectations both from experience, and from the current
> mood of the people involved.

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

>> Before taking this step, can we please discuss the possibility of
>> creating a uniform interface?
>
> That's orthogonal.

Not if the Flycheck maintainers have no interest, or are even opposed to
it.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 21/02/2024 20:05, Philip Kaludercic wrote:

>> We've discussed it. Such possibility exists.
> 
> Who is we?

People in this thread. Mostly in public, and just a tiny bit in private.

>> If we're going to make the implementation of it as a prerequisite for
>> merging, however, I imagine that's just not going to
>> happen. Flycheck's contributors will go back to their own bubble, and
>> we'll stay in ours.
> 
> As you might guess, I don't consider this a problem.

I'm sorry to hear that.

>>> Before taking this step, can we please discuss the possibility of
>>> creating a uniform interface?
>>
>> That's orthogonal.
> 
> Not if the Flycheck maintainers have no interest, or are even opposed to
> it.

Let's attract them with honey, shouldn't we?

Re: Adding Flycheck to NonGNU ELPA

[Stefan Monnier]

>>> Before taking this step, can we please discuss the possibility of
>>> creating a uniform interface?
>> That's orthogonal.
> Not if the Flycheck maintainers have no interest, or are even opposed to
> it.

Of course it's orthogonal.

Flycheck is a package that's well-written, popular, well-maintained, and
that respects the users's freedom, so there's no reason not to include
it in NonGNU ELPA, regardless if it comes with some bridge for Flymake.

But I'll grant you that it's not 100% orthogonal: If we want to get
a uniform interface between the two, the first thing to do would be to
encourage cooperation rather than to put up barriers, so including it in
NonGNU ELPA could help.


        Stefan

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 21/02/2024 19:00, Philip Kaludercic wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> On 20/02/2024 13:48, Philip Kaludercic wrote:
>>
>>> If Flycheck were to use the same interface as Flymake, then the
>>> situation would be better, as it would only be a different UI with
>>> perhaps some other priorities.
>>
>> Flycheck uses macros to define checkers and output parsers. Perhaps
>> one day those could expand to Flymake's functional interface under the
>> covers, but for that to happen, it would help a lot if we were more
>> welcoming.
> 
> That is what flymake-collection is supposedly working on.

Should I point out that Flycheck's staying out of built-in ELPA sources 
still didn't help Flymake grow a comparable library of checkers during 
the years that passed?

Mohsin's efforts are commendable, but I don't think either will take 
away from another. Because anyway, when writing a checker the hard[er] 
part is determining which commands to use and with which arguments, 
rather than the code that does it (which is normally fairly similar 
between checkers). Porting them over in either direction is easy enough.

> No, but effort is wasted on developing incompatible backends.  If
> Flycheck could take a similar route like Company in recommending to
> develop against the default/built-in interface (CAPF and Flymake
> respectively), then I really wouldn't mind having a second UI, but
> considering the misinformation that Flycheck still promote, I don't see
> any interest from their side to converge to a common denominator.

If there is wrong information in their public documentation or 
statements, we definitely should ask them to issue corrections.

>> Note that when Xref was introduced, there were no existing protocols
>> out there, in third-party packages or not, that could be used for the
>> same purpose (abstraction over code navigation sources).
> 
> True, but that only made it easier.  If there had been some MELPA
> package called "jumpy" of whatever, then some packages would support
> xref, the others "jumpy", others again would have to try and support
> both.  People would constantly be asking "what is the difference between
> xref and jumpy", and others again wouldn't notice xref at all because
> they assume that every feature in Emacs has to be installed via some
> external package.

Yes, people indeed ask questions. Just like they asked about the 
difference between lsp-mode and eglot, and still continue to do so. That 
did spur better competition for a time, with both sides playing catchup 
in different aspects.

I don't see how anybody is going to stop asking about Flycheck vs 
Flymake--they're still doing it now. And Flycheck has much better 
visibility in the community anyway.

> This also reminds me of another point: Xref, Flymake, CAPF, ... are all
> interfaces, that don't have to bring with them implementations for all
> kinds of languages.  That is the job of a major mode, and it is a lot
> more reasonable for a major mode to implement this interface, if
> provided by a core package, than if they had to use an third-party
> package that is not even part of GNU ELPA.

It's a good argument which would have probably worked better if the 
difference in development speed and release frequency between core Emacs 
and 3rd party packages weren't so big.

But we can still use it to encourage potential contributors to take up 
the effort.

One of the handy bits that Flycheck has, though, it the provision of 
several checkers for many of the languages. And (I think?) and interface 
the switch between them. That might not fit the major-mode-hook model so 
neatly; with Flymake, we usually limit ourselves to automatic detection 
and failover.

>>> I know that there are differences, and I hope that the situation
>>> improves, but to mention another negative that probably disqualifies
>>> adding the package just on its own: `lsp-install-server'.  The command
>>> can download arbitrary executable files as servers and runs them
>>> locally.
>>
>> curl can download arbitrary executable files, and it's still free
>> software. The question is which urls are pre-configured.
> 
> The objection is not that lsp-mode is not free software, it is that it
> doesn't respect their users by downloading arbitrary binaries from the
> net and running them on their own machines, even if all the servers were
> free (which I don't know, I haven't checked all of them).

I'm pretty sure it only does that when asked. And if said software is 
FLOSS, I don't see the problem--finding the sources is easy enough.

>> If we come to consider the inclusion of lsp-mode seriously (meaning,
>> there would be some interest from the maintainers), I'm happy to
>> discuss requesting that whatever proprietary servers are configured in
>> (I think there is 1 proprietary option for PHP among the total 4
>> available, not sure what else) are split off into separate packages
>> that we don't publish.
> 
> My impression of the lsp-mode maintainers is that they have no interest
> in collaborating with core development.

Not at the moment, and there are pretty obvious factors playing into it. 
But we should leave that door open.

Re: Adding Flycheck to NonGNU ELPA

[Stefan Kangas]

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

> Flycheck is a package that's well-written, popular, well-maintained, and
> that respects the users's freedom, so there's no reason not to include
> it in NonGNU ELPA, regardless if it comes with some bridge for Flymake.

Agreed.

> But I'll grant you that it's not 100% orthogonal: If we want to get
> a uniform interface between the two, the first thing to do would be to
> encourage cooperation rather than to put up barriers, so including it in
> NonGNU ELPA could help.

Yup.  Historical kerfuffles notwithstanding, more collaboration and
interoperability can only help, whether or not that means that the
friendly competition[1] between flymake and flycheck remains or not.

One idea would be to change flymake so that it can support flycheck
backends natively, without needing any third-party packages.  That would
already go a long way to decrease the differences between the two
packages.  I'd definitely encourage work on that.

Another thing is that we could use a good built-in macro to define
flymake backends.

Perhaps Steve Purcell (added to CC) could be convinced to contribute his
excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
This would kill two (or more) birds with one stone, and also remove some
of the gripes that some users have with flymake.

Footnotes:
[1]  If it hasn't always been friendly in the past, there's no reason not
     to work on making sure it's friendly going forward.

[2]  https://github.com/purcell/flymake-flycheck

[3]  https://github.com/purcell/flymake-easy

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

I also think we're discussing some orthogonal issues here. Let's take things one step at a time - I'm open to discussing whatever concerns some people have about Flycheck and some form of collaboration with Flymake (e.g. common standard for checker definitions) down the road. 

Thanks to Dmitry and Stefan for supporting the inclusion of Flycheck to NonGNU ELPA!  

On Wed, Feb 21, 2024, at 7:19 PM, Dmitry Gutov wrote:
> On 21/02/2024 19:00, Philip Kaludercic wrote:
> > Dmitry Gutov <dmitry@gutov.dev> writes:
> > 
> >> On 20/02/2024 13:48, Philip Kaludercic wrote:
> >>
> >>> If Flycheck were to use the same interface as Flymake, then the
> >>> situation would be better, as it would only be a different UI with
> >>> perhaps some other priorities.
> >>
> >> Flycheck uses macros to define checkers and output parsers. Perhaps
> >> one day those could expand to Flymake's functional interface under the
> >> covers, but for that to happen, it would help a lot if we were more
> >> welcoming.
> > 
> > That is what flymake-collection is supposedly working on.
> 
> Should I point out that Flycheck's staying out of built-in ELPA sources 
> still didn't help Flymake grow a comparable library of checkers during 
> the years that passed?
> 
> Mohsin's efforts are commendable, but I don't think either will take 
> away from another. Because anyway, when writing a checker the hard[er] 
> part is determining which commands to use and with which arguments, 
> rather than the code that does it (which is normally fairly similar 
> between checkers). Porting them over in either direction is easy enough.
> 
> > No, but effort is wasted on developing incompatible backends.  If
> > Flycheck could take a similar route like Company in recommending to
> > develop against the default/built-in interface (CAPF and Flymake
> > respectively), then I really wouldn't mind having a second UI, but
> > considering the misinformation that Flycheck still promote, I don't see
> > any interest from their side to converge to a common denominator.
> 
> If there is wrong information in their public documentation or 
> statements, we definitely should ask them to issue corrections.
> 
> >> Note that when Xref was introduced, there were no existing protocols
> >> out there, in third-party packages or not, that could be used for the
> >> same purpose (abstraction over code navigation sources).
> > 
> > True, but that only made it easier.  If there had been some MELPA
> > package called "jumpy" of whatever, then some packages would support
> > xref, the others "jumpy", others again would have to try and support
> > both.  People would constantly be asking "what is the difference between
> > xref and jumpy", and others again wouldn't notice xref at all because
> > they assume that every feature in Emacs has to be installed via some
> > external package.
> 
> Yes, people indeed ask questions. Just like they asked about the 
> difference between lsp-mode and eglot, and still continue to do so. That 
> did spur better competition for a time, with both sides playing catchup 
> in different aspects.
> 
> I don't see how anybody is going to stop asking about Flycheck vs 
> Flymake--they're still doing it now. And Flycheck has much better 
> visibility in the community anyway.
> 
> > This also reminds me of another point: Xref, Flymake, CAPF, ... are all
> > interfaces, that don't have to bring with them implementations for all
> > kinds of languages.  That is the job of a major mode, and it is a lot
> > more reasonable for a major mode to implement this interface, if
> > provided by a core package, than if they had to use an third-party
> > package that is not even part of GNU ELPA.
> 
> It's a good argument which would have probably worked better if the 
> difference in development speed and release frequency between core Emacs 
> and 3rd party packages weren't so big.
> 
> But we can still use it to encourage potential contributors to take up 
> the effort.
> 
> One of the handy bits that Flycheck has, though, it the provision of 
> several checkers for many of the languages. And (I think?) and interface 
> the switch between them. That might not fit the major-mode-hook model so 
> neatly; with Flymake, we usually limit ourselves to automatic detection 
> and failover.
> 
> >>> I know that there are differences, and I hope that the situation
> >>> improves, but to mention another negative that probably disqualifies
> >>> adding the package just on its own: `lsp-install-server'.  The command
> >>> can download arbitrary executable files as servers and runs them
> >>> locally.
> >>
> >> curl can download arbitrary executable files, and it's still free
> >> software. The question is which urls are pre-configured.
> > 
> > The objection is not that lsp-mode is not free software, it is that it
> > doesn't respect their users by downloading arbitrary binaries from the
> > net and running them on their own machines, even if all the servers were
> > free (which I don't know, I haven't checked all of them).
> 
> I'm pretty sure it only does that when asked. And if said software is 
> FLOSS, I don't see the problem--finding the sources is easy enough.
> 
> >> If we come to consider the inclusion of lsp-mode seriously (meaning,
> >> there would be some interest from the maintainers), I'm happy to
> >> discuss requesting that whatever proprietary servers are configured in
> >> (I think there is 1 proprietary option for PHP among the total 4
> >> available, not sure what else) are split off into separate packages
> >> that we don't publish.
> > 
> > My impression of the lsp-mode maintainers is that they have no interest
> > in collaborating with core development.
> 
> Not at the moment, and there are pretty obvious factors playing into it. 
> But we should leave that door open.
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

> One idea would be to change flymake so that it can support flycheck
> backends natively, without needing any third-party packages.  That would
> already go a long way to decrease the differences between the two
> packages.  I'd definitely encourage work on that.
> 
> Another thing is that we could use a good built-in macro to define
> flymake backends.
> 
> Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
> This would kill two (or more) birds with one stone, and also remove some
> of the gripes that some users have with flymake.

Pretty reasonable ideas IMO. 

> Yup.  Historical kerfuffles notwithstanding, more collaboration and
> interoperability can only help, whether or not that means that the
> friendly competition[1] between flymake and flycheck remains or not.

No argument from me. 

On Wed, Feb 21, 2024, at 10:19 PM, Stefan Kangas wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> > Flycheck is a package that's well-written, popular, well-maintained, and
> > that respects the users's freedom, so there's no reason not to include
> > it in NonGNU ELPA, regardless if it comes with some bridge for Flymake.
> 
> Agreed.
> 
> > But I'll grant you that it's not 100% orthogonal: If we want to get
> > a uniform interface between the two, the first thing to do would be to
> > encourage cooperation rather than to put up barriers, so including it in
> > NonGNU ELPA could help.
> 
> Yup.  Historical kerfuffles notwithstanding, more collaboration and
> interoperability can only help, whether or not that means that the
> friendly competition[1] between flymake and flycheck remains or not.
> 
> One idea would be to change flymake so that it can support flycheck
> backends natively, without needing any third-party packages.  That would
> already go a long way to decrease the differences between the two
> packages.  I'd definitely encourage work on that.
> 
> Another thing is that we could use a good built-in macro to define
> flymake backends.
> 
> Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
> This would kill two (or more) birds with one stone, and also remove some
> of the gripes that some users have with flymake.
> 
> Footnotes:
> [1]  If it hasn't always been friendly in the past, there's no reason not
>      to work on making sure it's friendly going forward.
> 
> [2]  https://github.com/purcell/flymake-flycheck
> 
> [3]  https://github.com/purcell/flymake-easy
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Stefan Monnier]

> Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> excellent flymake-flycheck[2] and flymake-easy[3] packages to core?

We could start by adding them to GNU ELPA.

Adding things in core can make things more complicated (e.g. if development
keeps happening outside of core, synchronization between the two can't
be fully automatic, and if we want to release ELPA packages from core,
it requires extra care when working in core to try and avoid adding
dependencies by accident, like I did recently with `map.el`).


        Stefan

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 21/02/2024 23:19, Stefan Kangas wrote:

> Another thing is that we could use a good built-in macro to define
> flymake backends.
> 
> Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
> This would kill two (or more) birds with one stone, and also remove some
> of the gripes that some users have with flymake.

There doesn't seem much point in having flymake-flycheck in the core 
when flycheck is still required to use most of its backends (they're 
part of the package). It also depends on flycheck at runtime anyway.

flymake-easy has another problem: IIUC it hasn't been updated for 10 
years, and as such only uses the obsolete Flymake protocol (one we keep 
in flymake-proc.el for compatibility). It also employs defadvice.

Back to flymake-flycheck, I wonder if it would be a better idea to have 
it as part of the flycheck package itself (fewer things to install and 
enable separately). But then it's not obvious at which point the 
checkers should be made available to flymake. If that happens when 
flycheck-mode is enabled, that would be too late: at that point the user 
has seemingly indicated that they want to use flycheck as UI as well.

> [2]  https://github.com/purcell/flymake-flycheck
> 
> [3]  https://github.com/purcell/flymake-easy

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

I can look at the options here at a later point. I haven't had much time to think about the future, given that I've assumed the Flycheck maintenance relatively soon. My short-term focus is harvesting some low-hanging fruit (like the package inclusion on NonGNU ELPA).

Compiling a reasonable long-term vision for the future (including some form of built-in interop with Flymake) will take some time and I think it'd better to discuss this separately.

> On 21/02/2024 23:19, Stefan Kangas wrote:
> 
> > Another thing is that we could use a good built-in macro to define
> > flymake backends.
> > 
> > Perhaps Steve Purcell (added to CC) could be convinced to contribute his
> > excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
> > This would kill two (or more) birds with one stone, and also remove some
> > of the gripes that some users have with flymake.
> 
> There doesn't seem much point in having flymake-flycheck in the core 
> when flycheck is still required to use most of its backends (they're 
> part of the package). It also depends on flycheck at runtime anyway.
> 
> flymake-easy has another problem: IIUC it hasn't been updated for 10 
> years, and as such only uses the obsolete Flymake protocol (one we keep 
> in flymake-proc.el for compatibility). It also employs defadvice.
> 
> Back to flymake-flycheck, I wonder if it would be a better idea to have 
> it as part of the flycheck package itself (fewer things to install and 
> enable separately). But then it's not obvious at which point the 
> checkers should be made available to flymake. If that happens when 
> flycheck-mode is enabled, that would be too late: at that point the user 
> has seemingly indicated that they want to use flycheck as UI as well.
> 
> > [2]  https://github.com/purcell/flymake-flycheck
> > 
> > [3]  https://github.com/purcell/flymake-easy
> 
> 
> 

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

Re: Adding Flycheck to NonGNU ELPA

[Thierry Volpiatto]

Philip Kaludercic <philipk@posteo.net> writes:

>> Let's remove Helm from NonGNU, then: its UI paradigm is also different
>> from the core Emacs, and IMHO it's rather ugly.

[Not sure who wrote this] but anyway,

saying a package is ugly just because it provides a different UI than
Emacs is unfair at best.  Helm is and is still one of the best
completion package (but not only) around here and I made a lot of work
for this, so please be respectful of my work or provide constructive critics.

>> And swiper/ivy from ELPA, just because.

Same here, a very good package and there is a lot of work behind this, so...

> While I am not a fan of Helm, it was initially added to provide popular
> packages that a number of people appeared to want to use.  Luckily these
> packages fall into the category of providing the front-end of a shared
> interface (completing-read; and that not without issues, because they
> tend to abuse completing-read's text expansion idea by focusing on
> narrowing and selecting).  And yes, there are packages that have hard
> dependencies on Helm, but usually when people submit these kinds of
> packages, we at least mention the idea of trying to generalise them, so
> that the front- and back-end can be disentangled from one another.

Helm is providing a full support on Emacs completion mechanism
(completing-read, completion-in-region etc...), Emacs
styles included.

-- 
Thierry

Re: Adding Flycheck to NonGNU ELPA

[Po Lu]

Philip Kaludercic <philipk@posteo.net> writes:

> I wouldn't put it that way, but as mentioned above I do think that
> pushing towards a consistent UI that aligns with Emacs strengths
> (text-based, buffers in windows, ...) is worth the effort, even if some
> projects have to change or die in the process.  E.g. a positive example:
> I added support for the "dumb-jump" to use Xref instead of
> re-implementing the UI with custom commands and popups.  People appear
> to use that now.

These are all valid considerations with packages destined for Emacs, but
our standards for NonGNU ELPA should be drastically the opposite, and
much more accommodating.  So long as a package works and doesn't
infringe on the GNU project's basic non-negotiable requirements, there's
little reason to delay uploading packages to allow time for implementing
adjustments we propose.

Re: Adding Flycheck to NonGNU ELPA

[Stefan Kangas]

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

>> Perhaps Steve Purcell (added to CC) could be convinced to contribute his
>> excellent flymake-flycheck[2] and flymake-easy[3] packages to core?
>
> We could start by adding them to GNU ELPA.
>
> Adding things in core can make things more complicated (e.g. if development
> keeps happening outside of core, synchronization between the two can't
> be fully automatic, and if we want to release ELPA packages from core,
> it requires extra care when working in core to try and avoid adding
> dependencies by accident, like I did recently with `map.el`).

No objections here.

Re: Adding Flycheck to NonGNU ELPA

[Steve Purcell]

> On 22 Feb 2024, at 03:16, Dmitry Gutov <dmitry@gutov.dev> wrote:
> 
> flymake-easy has another problem: IIUC it hasn't been updated for 10 years, and as such only uses the obsolete Flymake protocol (one we keep in flymake-proc.el for compatibility). It also employs defadvice.


The defadvice issue is easily fixed, but in general I can’t tell if the package is defunct or would still be useful for people if it had a refresh. I suspect the latter.

Re: Adding Flycheck to NonGNU ELPA

[Steve Purcell]

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



> On 22 Feb 2024, at 07:15, Bozhidar Batsov <bozhidar@batsov.dev> wrote:
> 
> I can look at the options here at a later point. I haven't had much time to think about the future, given that I've assumed the Flycheck maintenance relatively soon. My short-term focus is harvesting some low-hanging fruit (like the package inclusion on NonGNU ELPA).
> 
> Compiling a reasonable long-term vision for the future (including some form of built-in interop with Flymake) will take some time and I think it'd better to discuss this separately.


Agree, happy to be pulled into any discussions if it helps.

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

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 22/02/2024 09:15, Bozhidar Batsov wrote:
> 
> Compiling a reasonable long-term vision for the future (including some 
> form of built-in interop with Flymake) will take some time and I think 
> it'd better to discuss this separately.

Naturally.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 22/02/2024 10:41, Thierry Volpiatto wrote:
> Philip Kaludercic <philipk@posteo.net> writes:
> 
>>> Let's remove Helm from NonGNU, then: its UI paradigm is also different
>>> from the core Emacs, and IMHO it's rather ugly.
> 
> [Not sure who wrote this] but anyway,
> 
> saying a package is ugly just because it provides a different UI than
> Emacs is unfair at best.  Helm is and is still one of the best
> completion package (but not only) around here and I made a lot of work
> for this, so please be respectful of my work or provide constructive critics.

Sorry, that was my message, but it was sent in private, and it was 
mostly hyperbole aimed to make a point. I didn't intend for it to be 
answered in public.

>>> And swiper/ivy from ELPA, just because.
> 
> Same here, a very good package and there is a lot of work behind this, so...

Ditto.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 22/02/2024 12:14, Steve Purcell wrote:
> 
>> On 22 Feb 2024, at 03:16, Dmitry Gutov<dmitry@gutov.dev>  wrote:
>>
>> flymake-easy has another problem: IIUC it hasn't been updated for 10 years, and as such only uses the obsolete Flymake protocol (one we keep in flymake-proc.el for compatibility). It also employs defadvice.
> 
> The defadvice issue is easily fixed, but in general I can’t tell if the package is defunct or would still be useful for people if it had a refresh. I suspect the latter.

I think there is demand for it, but code-wise, it might need a full rewrite.

It also might make sense to contribute the improved helper to flymake.el 
directly, rather than have it as an external package - then the built-in 
modes could also use it.

Because what I have to do at the moment, is copy ruby-flymake--helper 
with minor variations to use for each backend, and that's not ideal.

Meanwhile the users of flymake-easy who target older versions of Flymake 
(including the current release) could continue to use the existing 
version, since the obsolete API is still supported (I think), just not 
quite recommended.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 21/02/2024 17:02, Stefan Monnier wrote:
>> So, unless unless there is a strong objection from one of Emacs's head
>> maintainers, I think I will commence Flycheck's addition to NonGNU in the
>> next few days.
> That would be very welcome, thanks.

All right, I've made the push: 
https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/

It should build sometime within 24 hours.

Bozhidar, see the recipe in the diff, if any exclusions should be added, 
the syntax is there (and also in the file's commentary at the top).

What could be also added, is a way to build the manual to be included 
with the package. I'm not sure how easy that would be to do, though, 
with your current documentation setup.

Re: Adding Flycheck to NonGNU ELPA

[Philip Kaludercic]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 21/02/2024 17:02, Stefan Monnier wrote:
>>> So, unless unless there is a strong objection from one of Emacs's head
>>> maintainers, I think I will commence Flycheck's addition to NonGNU in the
>>> next few days.
>> That would be very welcome, thanks.
>
> All right, I've made the push:
> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/

Here is a more permanent link for posterity:

https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=7c06709972291413f18b750248b141293415cd42

>
> It should build sometime within 24 hours.
>
> Bozhidar, see the recipe in the diff, if any exclusions should be
> added, the syntax is there (and also in the file's commentary at the
> top).

Ideally this information shouldn't be tracked in nongnu.git, but in an
.elpaignore file within the repository.

> What could be also added, is a way to build the manual to be included
> with the package. I'm not sure how easy that would be to do, though,
> with your current documentation setup.

It appears they use sphinx, which can generate TeXinfo output[0], though
I personally would recommend looking into translating the documentation
into a more standard format like Org or directly to TeXinfo.

[0] https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-texinfo-output

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 22/02/2024 18:57, Philip Kaludercic wrote:
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
>> On 21/02/2024 17:02, Stefan Monnier wrote:
>>>> So, unless unless there is a strong objection from one of Emacs's head
>>>> maintainers, I think I will commence Flycheck's addition to NonGNU in the
>>>> next few days.
>>> That would be very welcome, thanks.
>>
>> All right, I've made the push:
>> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/
> 
> Here is a more permanent link for posterity:
> 
> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=7c06709972291413f18b750248b141293415cd42

Thank you.

>>
>> It should build sometime within 24 hours.
>>
>> Bozhidar, see the recipe in the diff, if any exclusions should be
>> added, the syntax is there (and also in the file's commentary at the
>> top).
> 
> Ideally this information shouldn't be tracked in nongnu.git, but in an
> .elpaignore file within the repository.

That's a good point. It would be even better if MELPA supported 
.elpaignore too, but either way, adjusting ignores through this file is 
usually easier for an external package's maintainer.

>> What could be also added, is a way to build the manual to be included
>> with the package. I'm not sure how easy that would be to do, though,
>> with your current documentation setup.
> 
> It appears they use sphinx, which can generate TeXinfo output[0], though
> I personally would recommend looking into translating the documentation
> into a more standard format like Org or directly to TeXinfo.
> 
> [0] https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-texinfo-output

Last I read, they decided against TeXinfo due to what format an average 
contributor would find easier to use. But anyway, it's up to Bozhidar now.

Re: Adding Flycheck to NonGNU ELPA

[Bozhidar Batsov]

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

Thanks for the updates!

Regarding the docs - I was thinking of converting them to something like AsciiDoc or org-mode, but that'd require me to find a new way to host them as ReadTheDocs supports only RST and Markdown. That's why I've put this item on the backburner for now. I try to find some time to look into the various conversion option (or generating TexInfo from the current docs). 

On Thu, Feb 22, 2024, at 6:10 PM, Dmitry Gutov wrote:
> On 22/02/2024 18:57, Philip Kaludercic wrote:
> > Dmitry Gutov <dmitry@gutov.dev> writes:
> > 
> >> On 21/02/2024 17:02, Stefan Monnier wrote:
> >>>> So, unless unless there is a strong objection from one of Emacs's head
> >>>> maintainers, I think I will commence Flycheck's addition to NonGNU in the
> >>>> next few days.
> >>> That would be very welcome, thanks.
> >>
> >> All right, I've made the push:
> >> https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/
> > 
> > Here is a more permanent link for posterity:
> > 
> > https://git.savannah.gnu.org/cgit/emacs/nongnu.git/commit/?id=7c06709972291413f18b750248b141293415cd42
> 
> Thank you.
> 
> >>
> >> It should build sometime within 24 hours.
> >>
> >> Bozhidar, see the recipe in the diff, if any exclusions should be
> >> added, the syntax is there (and also in the file's commentary at the
> >> top).
> > 
> > Ideally this information shouldn't be tracked in nongnu.git, but in an
> > .elpaignore file within the repository.
> 
> That's a good point. It would be even better if MELPA supported 
> .elpaignore too, but either way, adjusting ignores through this file is 
> usually easier for an external package's maintainer.
> 
> >> What could be also added, is a way to build the manual to be included
> >> with the package. I'm not sure how easy that would be to do, though,
> >> with your current documentation setup.
> > 
> > It appears they use sphinx, which can generate TeXinfo output[0], though
> > I personally would recommend looking into translating the documentation
> > into a more standard format like Org or directly to TeXinfo.
> > 
> > [0] https://www.sphinx-doc.org/en/master/usage/configuration.html#options-for-texinfo-output
> 
> Last I read, they decided against TeXinfo due to what format an average 
> contributor would find easier to use. But anyway, it's up to Bozhidar now.
> 
> 

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

Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Spencer Baugh]

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:
> Thanks for the updates!
>
> Regarding the docs - I was thinking of converting them to something like AsciiDoc or org-mode, but that'd require me to find a new
> way to host them as ReadTheDocs supports only RST and Markdown. That's why I've put this item on the backburner for now. I try
> to find some time to look into the various conversion option (or generating TexInfo from the current docs). 

Hm, maybe the web interface for GNU and NonGNU ELPA should support
hosting web-rendered Texinfo manuals?  That would make it easier to
evaluate packages without installing them, and also solve Flycheck's
documentation hosting issue.

Since this would require ELPA to build the Texinfo manuals, perhaps we
could also use this to make a package-view-docs command (or something)
in Emacs which will fetch and view the manual for a package that is not
yet installed.

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Philip Kaludercic]

Spencer Baugh <sbaugh@janestreet.com> writes:

> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> Thanks for the updates!
>>
>> Regarding the docs - I was thinking of converting them to something like AsciiDoc or org-mode, but that'd require me to find a new
>> way to host them as ReadTheDocs supports only RST and Markdown. That's why I've put this item on the backburner for now. I try
>> to find some time to look into the various conversion option (or generating TexInfo from the current docs). 
>
> Hm, maybe the web interface for GNU and NonGNU ELPA should support
> hosting web-rendered Texinfo manuals?  That would make it easier to
> evaluate packages without installing them, and also solve Flycheck's
> documentation hosting issue.

It does, e.g. Compat directs directly to elpa.gnu.org:
https://elpa.gnu.org/packages/doc/compat/compat.html

> Since this would require ELPA to build the Texinfo manuals, 

It just renders them in HTML, I don't know of any .info files being
available outside of the tarballs.

>                                                             
>                                                             perhaps we
> could also use this to make a package-view-docs command (or something)
> in Emacs which will fetch and view the manual for a package that is not
> yet installed.

Something similar I had in mind was a variation on package-install that
wouldn't persist the installation, and instead of extracting the files
into .../elpa/, would store them in a /tmp/ sub-directory.  That would
go further than what you are describing, but would make trying out a
package easier.

Re: Adding Flycheck to NonGNU ELPA

[Spencer Baugh]

Dmitry Gutov <dmitry@gutov.dev> writes:
> On 22/02/2024 12:14, Steve Purcell wrote:
>> 
>>> On 22 Feb 2024, at 03:16, Dmitry Gutov<dmitry@gutov.dev>  wrote:
>>>
>>> flymake-easy has another problem: IIUC it hasn't been updated for 10 years, and as such only uses the obsolete Flymake protocol (one we keep in flymake-proc.el for compatibility). It also employs defadvice.
>> The defadvice issue is easily fixed, but in general I can’t tell if
>> the package is defunct or would still be useful for people if it had
>> a refresh. I suspect the latter.
>
> I think there is demand for it, but code-wise, it might need a full rewrite.
>
> It also might make sense to contribute the improved helper to
> flymake.el directly, rather than have it as an external package - then
> the built-in modes could also use it.
>
> Because what I have to do at the moment, is copy ruby-flymake--helper
> with minor variations to use for each backend, and that's not ideal.
>
> Meanwhile the users of flymake-easy who target older versions of
> Flymake (including the current release) could continue to use the
> existing version, since the obsolete API is still supported (I think),
> just not quite recommended.

From looking at ruby-flymake--helper, maybe it would be best to have a
new helper for working with processes.  It looks like
ruby-flymake--helper just wants to:

1. Send the current buffer text to a process.
2. When the process exits cleanly, call a callback with all the
process's output.

It seems like we could add a helper that supports that.  Then
ruby-flymake--helper would disappear in favor of some
process-run-and-call function.

Or... IMO, even better than a helper would be using Elisp threads for
this.  Then there's no need for any callback stuff.  Really, threads are
a natural fit for flymake, since flymake already provides a UI which can
display data computed asynchronously by threads, and that's IMO the
hardest part of using threads.

Re: Adding Flycheck to NonGNU ELPA

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: Steve Purcell <steve@sanityinc.com>,  Stefan Kangas
>  <stefankangas@gmail.com>,  Stefan Monnier <monnier@iro.umontreal.ca>,
>  Philip Kaludercic <philipk@posteo.net>,  joakim@verona.se,  Bozhidar
>  Batsov <bozhidar@batsov.dev>,  Emacs Devel <emacs-devel@gnu.org>
> Date: Fri, 23 Feb 2024 11:20:00 -0500
> 
> Or... IMO, even better than a helper would be using Elisp threads for
> this.  Then there's no need for any callback stuff.

Caveat: if the callback needs to display something, you could still
have a problem with threads.

> Really, threads are a natural fit for flymake, since flymake already
> provides a UI which can display data computed asynchronously by
> threads, and that's IMO the hardest part of using threads.

Emacs Lisp threads are not really asynchronous.

Re: Adding Flycheck to NonGNU ELPA

[Dmitry Gutov]

On 23/02/2024 18:20, Spencer Baugh wrote:

>  From looking at ruby-flymake--helper, maybe it would be best to have a
> new helper for working with processes.  It looks like
> ruby-flymake--helper just wants to:
> 
> 1. Send the current buffer text to a process.
> 2. When the process exits cleanly, call a callback with all the
> process's output.
> 
> It seems like we could add a helper that supports that.  Then
> ruby-flymake--helper would disappear in favor of some
> process-run-and-call function.

Some kind of helper that covers the existing variations is indeed what I 
was thinking of. Though maybe (additionally) a macro version with a 
terse syntax would appeal to some, too.

> Or... IMO, even better than a helper would be using Elisp threads for
> this.  Then there's no need for any callback stuff.  Really, threads are
> a natural fit for flymake, since flymake already provides a UI which can
> display data computed asynchronously by threads, and that's IMO the
> hardest part of using threads.

I'm not sure about Lisp threads for this particular purpose because they 
carry their own complexity (flakier error handling, for example), and 
the asynchrony requirement is solved by the current callback-based 
interface. I think threads can bring more value where you would be able 
to write code in a sequential fashion, while having it executed 
asynchronously (unrelatedly, one of the subjects you touched on in 
bug#69188). But maybe I'm wrong, you're welcome to show otherwise, maybe 
with a code example.

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Adam Porter]

> Something similar I had in mind was a variation on package-install that
> wouldn't persist the installation, and instead of extracting the files
> into .../elpa/, would store them in a /tmp/ sub-directory.  That would
> go further than what you are describing, but would make trying out a
> package easier.

FYI, that exists in the form of the `try' package available on MELPA. 
It works well.  Maybe it could be added to GNU ELPA.  Or maybe a 
`package-try' command could be added to package.el.

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Philip Kaludercic]

Adam Porter <adam@alphapapa.net> writes:

>> Something similar I had in mind was a variation on package-install that
>> wouldn't persist the installation, and instead of extracting the files
>> into .../elpa/, would store them in a /tmp/ sub-directory.  That would
>> go further than what you are describing, but would make trying out a
>> package easier.
>
> FYI, that exists in the form of the `try' package available on
> MELPA.

I am surprised to hear that someone had to write a package for that,
when the basic functionality can be provided by

--8<---------------cut here---------------start------------->8---
(defun package-install-temporarily (pkg)
  (interactive
   (progn
     (package--archives-initialize)
     (list (intern (completing-read "Try: " package-archive-contents)))))
  (let ((package-user-dir (make-temp-file "package-tmp" t nil)))
    (package-install pkg t)))
--8<---------------cut here---------------end--------------->8---

(and if we extracted the interactive part from package-install, then it
would be even shorter).  Another idea would be to provide a generic
temporary package prefix command or minor mode.

>        It works well.  Maybe it could be added to GNU ELPA.  Or maybe
> a `package-try' command could be added to package.el.

That name is a bit short, and it is not clear what is meant.  Try to
install a package, try to find a package, etc.

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Stefan Monnier]

> It does, e.g. Compat directs directly to elpa.gnu.org:
> https://elpa.gnu.org/packages/doc/compat/compat.html

BTW, any help setting up some CSS styling there would be welcome
(probably following the CSS styling used for Texinfo docs on on
www.gnu.org).


        Stefan

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Philip Kaludercic]

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

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

>> It does, e.g. Compat directs directly to elpa.gnu.org:
>> https://elpa.gnu.org/packages/doc/compat/compat.html
>
> BTW, any help setting up some CSS styling there would be welcome
> (probably following the CSS styling used for Texinfo docs on on
> www.gnu.org).

Do we need more than this:


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

diff --git a/elpa-admin.el b/elpa-admin.el
index e1e0d2dd1e..f45c8586a0 100644
--- a/elpa-admin.el
+++ b/elpa-admin.el
@@ -43,6 +43,7 @@
 (defvar elpaa--name "NonGNU")
 (defvar elpaa--gitrepo "emacs/nongnu.git")
 (defvar elpaa--url "https://elpa.gnu.org/nongnu/")
+(defvar elpaa--css-url "https://www.gnu.org/software/emacs/manual.css")
 
 (defvar elpaa--branch-prefix "elpa/")
 (defvar elpaa--release-branch-prefix "elpa-release/")
@@ -2471,7 +2472,7 @@ directory; one of archive, archive-devel."
 	 (html-file (expand-file-name destname html-dir))
 	 (html-xref-file
 	  (expand-file-name destname (file-name-directory html-dir))))
-    (elpaa--makeinfo docfile html-file '("--html"))
+    (elpaa--makeinfo docfile html-file (list "--html" (format "--css-ref=%s" elpaa--css-url)))
     ;; FIXME: Use `push' in Emacs≥28
     (plist-put (cdr pkg-spec)
                :internal--html-docs

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


-- 
Philip Kaludercic

Re: Docs on ELPA (was Re: Adding Flycheck to NonGNU ELPA)

[Corwin Brust]

On Sat, Feb 24, 2024 at 2:04 AM Philip Kaludercic <philipk@posteo.net> wrote:
>
>
> That name is a bit short, and it is not clear what is meant.  Try to
> install a package, try to find a package, etc.
>

If this need only be a function, perhaps "package-preview" would be more clear.