bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#63595: 30.0.50; ERC 5.6: Add buffer-list and nick-list modules


From: J.P.
Subject: bug#63595: 30.0.50; ERC 5.6: Add buffer-list and nick-list modules
Date: Thu, 31 Aug 2023 06:30:43 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

This feature introduced a couple auxiliary modules to serve as higher
level wrappers around newer functionality that was awkwardly bolted onto
the existing libraries erc-status-sidebar and erc-speedbar. One of the
stated aims of this bug's initial proposal was to unify the UI for this
flavor of transitory, command-focused module [1]. However, anyone paying
close enough attention will have noticed I've already faltered in this
regard.

Look at the minor-mode toggle `erc-bufbar-mode' and notice that, when
disabling, it tears down the mode completely, destroying all assets. To
make it easy to show and hide its window without alternately shutting
down and starting anew with every other toggle, I turned to contextually
overloading the existing commands `erc-status-sidebar-toggle' and
friends to behave specially when `erc-bufbar-mode' is active [2].

Contrast this with the approach taken for `erc-nickbar-mode', whose
namesake command is of the all-in-one, kitchen-sink variety. Toggling
off merely hides its window and preserves the speedbar session (its
hidden frame, buffer, etc.). To actually kill it off completely, you
invoke the toggle with a negative prefix argument.

Obviously, these must be reconciled somehow, or one must be made to
mimic the other. I'm leaning toward changing `nickbar' by adding a
second command to toggle it without shutting it down, and then having
the main minor-mode toggle always do a full shutdown. This probably
aligns more with prevailing expectations and traditional Emacs semantics
that assume a nil `erc-nickbar-mode' variable indicates not only a
logical disabled activation state but that the mode is completely
destroyed.

Therefore, unless anyone has any better ideas, I'll provide a patch
shortly that does something to this effect.

Thanks.


[1] To recap, the trend in recent years has been to downplay the use of
    a module's minor-mode toggle as a viable entry point for enabling
    its functionality. Rather, there's been a focus on emphasizing
    membership in `erc-modules' as the preferred means of doing so. The
    reasons are manifold but ultimately rooted in attaining more
    predictable behavior and tighter inter-module interop across the
    board. However, this paradigm necessarily couples a module's
    activation state to the lifetime of an IRC session, which doesn't
    always make sense. Some modules, by their very nature, are
    intrinsically interactive and ephemeral. IOW, they're minor-modes
    first and modules second.

[2] Note the traditional library namespace prefix, which probably
    hampers discoverability for users of the module. We could alias the
    transitory toggles (at least) to reflect the new module names, but
    that may just confuse things further because the new options would
    all continue to sport library prefixes.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]