Re: Automatic Suggestion of Packages

[Philip Kaludercic <philipk@posteo.net>]

Visuwesh <visuweshm@gmail.com> writes:

> [வெள்ளி நவம்பர் 08, 2024] Philip Kaludercic wrote:
>
>>>> [...]
>>>> Perhaps it makes sense to always present a message if the minor mode
>>>> is enabled, and add a separate option to enable the mode-line button?
>>>
>>> I would be happy with this (though I would turn the mode-line button on
>>> by default).
>>
>> The issue with enable-by-default in the current implementation is that
>> we would have to load package.el by default, which is currently avoided
>> to reduce the startup time (see `package-enable-at-startup').
>
> I see.
>
>>
>> We could extract the autosuggest logic into a separate file and suggest
>> loading that by default.
>>
>> We could also consider not using the mode line, but the menu bar to hint
>> at package suggestions, but that might be easy to miss especially if a
>> lot of people advise disabling the menu bar.
>
> That is a good idea too.
>
>>> BTW, I looked at the code to see what it does when there's multiple
>>> packages suggested for a single (e.g., racket: racket-mode and
>>> geiser-racket).  It seems to install and enable only the first
>>> suggestion: should we instead prompt the user about it?  But asking the
>>> user would defeat the purpose of the feature, which helps in assisting
>>> her in setting up her environment for her work.
>>
>> No the current implementation would just install everything.  Neither of
>> the two solutions are really ideal.  Perhaps we need to pop up a buffer
>> with clickable elements to present the package suggestions and propose
>> installing one of them?
>
> It would help the user decide between the packages if some kind of
> popularity metric is shown.  If they cannot decide between the options,
> they could at least pick the most popular one and go with that.  I think
> the current one shown in the GNU ELPA website should be sufficient for
> most cases.
> Although I dislike the idea myself personally, "last updated time" might
> be a good indication too.  [ I dislike it because stable packages don't
> need to get updated.  After all, they just work.  ]

AFAIK we don't currently expose the ranking information via some API,
but that might change in the future.  Last updated has advantages and
disadvantages that one should be weary of (a stable package might be
seldom updated and a newer package more frequently as it is trying to
become more mature).

The core of the problem to me seems that we have situations where a file
extensions might be used by multiple languages (as is currently the
situation with Perl and Prolog, both commonly using ".p").  Assuming
these were ELPA packages and not-built-in, we could try to combine the
data, e.g. if the interpreter and the file name agree, only the propose
Perl and not Prolog.  Yet it is probably the safest option to engage
human judgement and present the options, in a simple menu listing
package names, their summaries and a button to install the package.

Based on what I am imagining, the complementary issue that you
mention, "racket-mode" vs "geiser-racket" would pop up a buffer that
would look something this:

--8<---------------cut here---------------start------------->8---
There are multiple package suggestions based on the available
information:

 - "racket-mode"                                        [install]

     Racket editing, REPL, and more

   Suggested due to: file name matching \.rkt\', the interpreter
   matching "racket".

 - "geiser-racket"                                      [install]

     Support for Racket in Geiser

   Suggested due to: file name matching \.rkt\'
--8<---------------cut here---------------end--------------->8---

-- 
	Philip Kaludercic on siskin