> On Feb 18, 2024, at 8:46 AM, Po Lu <luangruo@yahoo.com> wrote:
> 
> JD Smith <jdtsmith@gmail.com> writes:
> 
>> Maybe I should be more specific here: I don't think the cost/benefit
>> favors having it in the core ready to fire up when any .pro file is
>> loaded (since there are other unrelated flavors with that file type in
>> the wild, e.g. Qt config files, which confuses people)
> 
> That's easily resolved, if we judge that this is an issue.
> 
>> or having the IDLWAVE manual appear at the top level of M-x info (as
>> nice as a manual it is, and as hard as I worked on it lo those many
>> years ago).
> 
> Likewise.  But if I may digress a little, why should it be ever a
> problem that an index or directory contain information of marginal
> interest, when that is the rationale for maintaining such a directory to
> begin with?  And why is IDLWAVE more of a problem than the remainder of
> our eclectic corpus of manuals, many of which are to the average user no
> more relevant than is IDLWAVE?  To be found in the card catalog of any
> library are the answers to both these questions, as the Info directory's
> role is quite comparable to theirs.

This is the slippery slope I alluded to, and it is a credible argument.  To explore its boundaries, let's consider a scenario in which the IDL language were well and truly dead.  No existing licensed interpreter capable of running IDL code existed any longer on any system (licenses expire).  Would maintaining this package in the core be worth it at that point?  If not, this indicates that the costs are indeed non-zero.

>> hand.  A small package that is effectively invisible and never loads
>> unless the user summons it has fewer costs in this way of looking at
>> it.
> 
> This description could also apply to IDLWAVE as it stands in core.

I wonder if all agree on that point?  Consider:

git log --pretty="format:%an" lisp/progmodes/idlw*.el doc/misc/idlwave.texi | perl -ne 'chomp; $a{$_}++; END{foreach $n (sort {@a{$b} <=> @a{$a}} keys %a) {printf("%30s\t%s\n",$n,"+" x $a{$n})}}'  

This reveals that an impressive 39 individual maintainers have had their hand in the code over the last 20 years, some with more than 80 commits.  Yes, many of these are find/replace typos or other "no additional cost" commits, but many are not.