Re: bug#60936: 30.0.50; ERC >5.5: Add erc-fill style based on visual-line-mode

[J.P.]

Attached is some proposed follow-up work for this feature and also some
ancillary changes that I might spin off into a new bug.

The first patch adds a couple helpers that encapsulate some of the
tedium involved in warning about missing dependencies and persisting
state between sessions. The second is more trivial and provides a
feature that adds spacing between certain types of messages. This only
works on graphical displays and pairs well with the variable
`line-spacing' and the new `fill-wrap' module. The third patch is the
simplest but also the most consequential. It's meant to illustrate one
way of tackling the problem of late module activation due to missing
dependencies, which (to my knowledge) mainly concerns two use cases:

  1. A local module depends on a global one that hooks on
     `erc-mode-hook', meaning the dependent has no way of activating the
     dependency properly just by calling its minor-mode activation
     toggle alone (because `erc-mode-hook' won't run again).

  2. A user manually invokes a global module's minor mode toggle (in
     code or interactively) in an existing, established ERC session.
     Again we face the problem of whatever portion of the module's setup
     lives in `erc-mode-hook' not being invited to run.

Both would be non-issues if we suddenly decided to adopt a policy of
canceling activation when encountering unmet dependencies. But barring
that, what I'm proposing is finding some way to fully activate a
dependency by invoking its mode activation toggle alone, both in the
vicinity of `erc-connect-pre-hook' (1) and elsewhere, away from any
session-init-related happenings (2).

As things stand, dependents can't activate dependencies that are only
designed to work in subsequent sessions because they may render all
current sessions instantly unusable. These "foundational" dependencies,
like 'stamp' and 'button', typically add members to insert-related
hooks, like `erc-insert-pre-hook' but also add setup-related business to
`erc-mode-hook'. Predictably, the insert variety run as soon as the next
message arrives, even though they likely depend on setup performed by
the other type, which only run when ERC creates new buffers.

The second case (2) is rare by comparison because modules designed to be
activated in established sessions have a more dynamic, transitory focus,
such as turning on spell checking or managing a side window, and are
thus already outfitted with the necessary resilience. By contrast,
foundational modules tend to apply destructive operations to buffers and
thus can't be toggled without upsetting the user experience
significantly (which is why, I'm guessing, their authors didn't even
bother taking similar precautions since there's never been a sane use
case). However, there's recently been cause to create a global module of
type 2 that depends on the flimsier, more foundational type 1, hence my
mentioning this second type.

With all that in mind, here are two possible approaches to tackling
this problem (though others undoubtedly exist [1]):

  a. Simple context flags in `erc-open'

     One or more variables to be bound non-nil around various
     module-setup contexts, such as when running deferred
     `erc-mode-hook' members or during the initial call to
     `erc--update-modules'

     Pros:
       - modules can opt in to contexts on a granular level
       - implementations are straightforward and appear directly in
         module setup, guarded by these flag variables

     Cons:
       - slightly verbose boilerplate that's tricky to provide a
         convenience helper for given the variations involved with
         meeting the idempotency and resilience requirements of "run
         wherever, whenever"
       - dependents have no way of detecting whether a dependency is
         "context aware" and thus safe to run (unless documented)
         because these flags are purely optional

  b. Convenience helper + symbol property

     Modules opt in by marking functions added to `erc-mode-hook' with a
     symbol property, like so:

       (put 'erc-foo-setup 'erc-mode-hook 'erc-foo-mode)

     And when it comes time for dependents to activate such a
     dependency, they can avail themselves of a helper, which calls any
     marked `erc-mode-hook' member of interest in all ERC buffers.
  
     Pros:
       - dependent modules have a trusted means of detecting whether a
         dependency's toggle is safely runnable anywhere

     Cons:
       - dependent modules must use the helper to activate dependencies,
         meaning this approach does not obviate the need for special
         code in those modules supporting activation during established
         sessions (type 2, above), however it does take care of _their_
         dependencies, which is the main point
       - members added to `erc-mode-hook' by a participating dependency
         must still be made resilient manually

For no particular reason, I've gone with (a) in the attached patch set,
but am obviously amenable to suggestions.

Thanks.

[1] I'm pretty sure it's impractical to try solving this problem by
    going to extremes, such as by rewriting every `erc-mode-hook' member
    to be ultra cautious or, on the flip side, opting for something
    totally magical. By the latter, I mostly mean trying to cleverly
    modify `define-erc-module' to statically detect occurrences of forms
    like (add-hook 'erc-mode-hook #'foo) and arrange for them to run as
    in (a), above. This is likely not worth attempting because some
    modules subscribe to that hook indirectly. There's also the problem
    of making modules aware of the new paradigm, since they may well
    have code that's unfit to run in various contexts.

0001-5.6-Add-helper-for-restoring-local-session-vars-in-E.patch
Description: Text Data

0002-5.6-Optionally-add-spacing-between-ERC-messages.patch
Description: Text Data

0003-5.6-Make-some-ERC-module-toggles-more-resilient.patch
Description: Text Data