all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: JD Smith <jdtsmith@gmail.com>
To: Po Lu <luangruo@yahoo.com>, Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Moving packages out of core to ELPA
Date: Sun, 18 Feb 2024 09:03:05 -0500	[thread overview]
Message-ID: <C469994B-C60A-4098-BB56-1E2BC0E34208@gmail.com> (raw)
In-Reply-To: <87il2lx4uh.fsf@yahoo.com>

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


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

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

  reply	other threads:[~2024-02-18 14:03 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-17 14:40 Moving packages out of core to ELPA JD Smith
2024-02-17 15:51 ` Eli Zaretskii
2024-02-17 16:22   ` JD Smith
2024-02-17 16:51     ` Eli Zaretskii
2024-02-17 17:08       ` JD Smith
2024-02-17 17:29         ` Eli Zaretskii
2024-02-17 18:52           ` JD Smith
2024-02-17 19:20             ` Eli Zaretskii
2024-02-17 20:56               ` [External] : " Drew Adams
2024-02-17 21:16               ` JD Smith
2024-02-18  6:28                 ` Eli Zaretskii
2024-02-18 12:57                   ` JD Smith
2024-02-18 13:46                     ` Po Lu
2024-02-18 14:03                       ` JD Smith [this message]
2024-02-18 14:08                         ` Po Lu
2024-02-18 14:17                           ` JD Smith
2024-02-18 14:17                         ` Eli Zaretskii
2024-02-18 14:19                           ` JD Smith
2024-02-18 14:22                         ` Po Lu
2024-02-17 17:42         ` [External] : " Drew Adams
2024-02-17 18:21           ` JD Smith
2024-02-17 18:32             ` Eli Zaretskii
2024-02-17 19:01               ` JD Smith
2024-02-17 20:50               ` Drew Adams
2024-02-18  1:55         ` Po Lu
2024-02-18  2:27           ` JD Smith
2024-02-18  3:47             ` Po Lu
2024-02-18  1:42 ` Po Lu
2024-02-18  2:14   ` JD Smith
2024-02-18  3:39     ` Po Lu
2024-02-18  7:25       ` Po Lu
2024-02-18 12:39       ` JD Smith
2024-02-18 13:08         ` Eli Zaretskii
2024-02-18 13:15         ` Po Lu
2024-02-18  7:14     ` Eli Zaretskii
2024-02-18 12:19       ` Dmitry Gutov
2024-02-18 13:06         ` Eli Zaretskii
2024-02-18 13:27           ` JD Smith
2024-02-18 13:06         ` Po Lu
2024-02-18 13:13           ` Dmitry Gutov
2024-02-18 13:51             ` Po Lu
2024-02-18 14:19               ` Dmitry Gutov
2024-02-18 14:26                 ` Po Lu
2024-02-18 14:38                   ` Dmitry Gutov
2024-02-19 18:09           ` Stefan Kangas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=C469994B-C60A-4098-BB56-1E2BC0E34208@gmail.com \
    --to=jdtsmith@gmail.com \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=luangruo@yahoo.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.