Re: Upcoming merge of adaptive-wrap

[Stephen Berman]

Sorry for not responding to your message from last August 10, which I
have just found again; FWIW I have these excuses for my negligence:
First, I was on vacation at the time and didn't see the message till
around two weeks later.  Second, you wrote in that message:

> Stefan, what do you say to this?  Since the package in ELPA, migrating
> it into Emacs should not pose any legal difficulties, so the only
> prerequisites are suitable entries in NEWS and the documentation,
> correct?

>From this I thought you were addressing Stefan Monnier, who is nominally
the co-author of the package (but actually is responsible for the most
important part of the implementation).  Third, I didn't know (or had
forgotten) that I'm still listed as maintainer of the package, a role
that I've not wanted to have for a long time.  In fact, in a private
exchange in June 2020 as followup to bug#41810, Stefan asked Kévin Le
Gouguec if he would like to assume the maintainership, though AFAIK
neither that question nor the bug report have been resolved; I've added
both to the Cc:.

In any case, I have no objection to moving adaptive-wrap from GNU ELPA
to Emacs core; but whatever the outcome, I would like to be removed as
maintainer.

Thanks.

Steve Berman

On Thu, 25 Jan 2024 09:39:47 +0800 Po Lu <luangruo@yahoo.com> wrote:

> Several months ago I tried to contact the maintainer of adaptive-wrap
> regarding the inclusion of his package into Emacs proper, who did not
> respond over all the months that have since passed.  (In general I was
> met with stony silence.  It's funny how pandemonium erupts when a minor
> proposal to introduce _new_ code appears, but the same people wash their
> hands of minor chores required for the code to remain useful.)  It's a
> fair bet that the package maintainer is not actively engaged in its
> development anymore, so if I hear no serious objections in the next few
> days I will write the documentation and merge this invaluable feature
> into master.
>
> I think placing the package on ELPA was unwise and would not have taken
> place but for our obsession with moving things to ELPA.  Minor features
> will never justify the hassle of browsing through the package list,
> downloading them from the Internet, and updating them with each new
> release of Emacs that obsoletes this or that feature.  For the future,
> could we please adopt at least the following two criteria for installing
> packages in ELPA rather than Emacs?  They're not very precise but better
> than nothing.
>
>   - The package is of sufficient size to be worthy of Internet
>     installation, and provides features in demand high enough that users
>     proactively research and install them.
>
>   - The package maintainer desires that it be distributed over ELPA.
>
> Even those proprietary text editors developed behind closed doors do not
> relegate useful text editing features to their extension repositories.
> Users are forced to distribute small enhancements there, because the
> developers of such text editors are not receptive to users acting on
> their own initiatives.  We are not so conceited, and should make the
> most of this advantage of ours.