Re: Upcoming merge of adaptive-wrap

[Kévin Le Gouguec]

Hi,

Stephen Berman <stephen.berman@gmx.net> writes:

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

Thanks for the reminder; my memory was that I had declined as politely
as I could, but re-reading my answer back then it was way too…  I'd say
"tongue-in-cheek", but it contained a character whose name actually
includes "STUCK-OUT TONGUE", so that does not sound right.

Jokes aside, I think my pattern of contribution to Emacs since then (or
lack thereof) confirms my unspoken concern at the time: I don't know
that I can give the time and attention maintainership deserves¹.
Certainly not in equal measure to the passion the OP has expressed for
this package.

(FWIW Po Lu, your message in August did not go unnoticed and has
remained "ticked" in my Gnus ever since, to watch for replies)

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

No strong opinion.  Thoughts though:

* Since adaptive-wrap implicitly relies on adaptive-fill-regexp, it's
  been on my mind that the mode could achieve better visual results if
  major modes "cooperated" and adjusted that variable, yet a lot of
  modes (e.g. read-only special modes) have no incentive to do so, since
  they are not expected to "hard-fill" text.

  E.g. adaptive-wrap in diff-mode currently looks inconsistent because
  ?- is part of adaptive-fill-regexp, but not ?+.  This makes removed
  lines wrapped with extra indent, but not added lines.  diff-mode could
  solve this by adding "+" to adaptive-fill-regexp, but why should it?
  No-one runs M-q on patches.

  All that to say: I've been wondering whether having adaptive-wrap in
  core would be a "good enough" incentive to push for such mode-specific
  tweaks to adaptive-fill-regexp; maybe it's neither necessary nor
  sufficient.

* Catching up on the rest of the thread: if the goal is discoverability,
  I think the most likely remedy long-term (NEWS will only help in the
  "short" term, until it is rotated into NEWS.30) will be pointers from
  visual-line-mode's documentation (docstring and/or manual).

  Here too, I can't firmly conclude that moving to core is necessary;
  can the documentation of core features like visual-line-mode reference
  features found in GNU ELPA, like adaptive-wrap?  If so, I would expect
  that to offer all the visibility this package needs; at least, not
  much less than it will get by being moved to core.

tl;dr Sure why not maybe I don't know?

Anyhoo.  Got a couple of pandemonium eruptions to catch up with 😊


¹ I have accrued a laundry list of things I would like to fix with
adaptive-wrap (account for face backgrounds from overlays; account for
face foregrounds from prefixes; heed any prefix's 'display property;
play nice with whitespace-mode) and have no patch to show for it.

I still use that package daily, but given my track record at scratching
my own itches I don't think *stewardship* should be on the table.