GNU bug report logs - #60933
30.0.50; ERC >5.5: Make buttonizing more extensible

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 60933 in the body.
You can then email your comments to 60933 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Wed, 18 Jan 2023 06:38:51 -0800

[Message part 1 (text/plain, inline)]

Tags: patch

ERC could really benefit from a more efficient, convenient, and flexible
means of modifying how words (mainly nicks) are buttonized in messages.

The approach being proposed here involves replacing the preferred type
of the third, "form" field in `erc-button-alist' entries. It's currently
an arbitrary "guard"-like sexp, which I'd like to deprecate in favor of
a function capable of rewriting the button itself. The deprecated form
would still be usable but would trigger a warning, going forward. A
special accommodation would be made for the constant t as well as for
special variables, whose values would be treated as booleans. This would
cover all existing default entries as currently used in client code.

The idea is for this new "rewriter" function to expect the bounds of the
button under consideration as input and to return something similar, or
nil, to indicate that the candidate ought to be skipped (as in not
buttonized). A separate variant with a different signature will be
required for nicknames since they're already treated specially. It'll be
passed additional arguments, such as `erc-server-user' and
`erc-channel-user' objects and a casemapped nickname, all of which are
already present in the caller's environment. Additionally, the values of
user options containing faces to be applied, such as
`erc-button-nickname-face' and `erc-button-face' will be free for the
changing, with all damage limited to the current button alone.

As an example of a possible application for this, I have included a
helper for displaying messages involving `substitute-command-keys'.
Other applications include button colorization and alternate display
text. Practical implementations of both are available on request.

The second patch contains the actual changes proposed above. The first
is only somewhat related but trivial enough to smuggle in with this set
(IMO). The last one I threw in on a whim. It adds additional flexibility
for third parties but will most likely be dropped or held back because
there's no immediate use for it in ERC's client code.

Thanks.


In GNU Emacs 30.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2023-01-17 built on localhost
Repository revision: 281f48f19ecad706a639d57cb937afb0b97eded7
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3'
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec epa derived epg rfc6068 epg-config
gnus-util text-property-search mm-decode mm-bodies mm-encode mail-parse
rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045
ietf-drums mm-util mail-prsvr mail-utils erc iso8601 time-date
auth-source cl-seq eieio eieio-core cl-macs password-cache json subr-x
map thingatpt pp format-spec cl-loaddefs cl-lib erc-backend erc-goodies
erc-networks byte-opt gv bytecomp byte-compile erc-common erc-compat
erc-loaddefs rmc iso-transl tooltip cconv eldoc paren electric uniquify
ediff-hook vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo move-toolbar gtk x-toolkit xinput2 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 64390 6319)
 (symbols 48 8639 0)
 (strings 32 23673 1623)
 (string-bytes 1 685926)
 (vectors 16 15259)
 (vector-slots 8 209777 7692)
 (floats 8 24 35)
 (intervals 56 232 0)
 (buffers 976 10))

[0001-5.6-Replace-Info-goto-node-with-info-in-erc-button-a.patch (text/x-patch, attachment)]

[0002-5.6-Add-erc-button-helper-for-substituting-command-k.patch (text/x-patch, attachment)]

[0003-5.6-Allow-erc-button-add-face-to-take-an-object.patch (text/x-patch, attachment)]

Message #8 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Sun, 19 Feb 2023 07:04:11 -0800

[Message part 1 (text/plain, inline)]

v2. Use dedicated internal function as module interface for modifying
nick buttonizing (via :around advice).

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-5.6-Replace-Info-goto-node-with-info-in-erc-button-a.patch (text/x-patch, attachment)]

[0002-5.6-Add-erc-button-helper-for-substituting-command-k.patch (text/x-patch, attachment)]

[0003-5.6-Allow-erc-button-add-face-to-take-an-object.patch (text/x-patch, attachment)]

Message #11 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Thu, 09 Mar 2023 06:42:07 -0800

[Message part 1 (text/plain, inline)]

v3. Expand `erc-button-alist' pattern to recognize inline (info "...")
forms. Autoload button helpers (locally, in ERC's own loaddefs).

[0000-v2-v3.diff (text/x-patch, attachment)]

[0001-5.6-Replace-Info-goto-node-with-info-in-erc-button-a.patch (text/x-patch, attachment)]

[0002-5.6-Add-erc-button-helper-for-substituting-command-k.patch (text/x-patch, attachment)]

[0003-5.6-Allow-erc-button-add-face-to-take-an-object.patch (text/x-patch, attachment)]

Message #14 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Tue, 18 Apr 2023 07:11:59 -0700

[Message part 1 (text/plain, inline)]

This bug's main contribution has been the introduction of a function
variant for the FORM field of `erc-button-alist' entries. It was meant
to offer a more natural way to influence buttonizing than the boolean
sexps it was displacing while still retaining enough structure to
encourage maintainability (for example, by highlighting which elements
invite modification, like a button's faces and its bounds, and which are
off limits, like certain required text properties).

However, in the short term, I feel that locking this down too cleverly
will only hamstring us as we inch closer to adopting various protocol
extensions for ERC 5.7. As requirements shift beneath us, the current
design will always end up seeming overly restrictive or permissive. As
such, I think it's best to partially revert these changes and instead
look to an existing interface we already know (but don't love), namely
`erc-button-add-button'. From now on, I think we should just interpret
any function occupying the FORM field as a replacement "buttonizer" to
be called in its place.

The same general thinking applies to the nicks-specific buttonizer as
well, though it being intrinsically special and, for now, internal means
we can take more liberties in inconveniencing its consumers (which are
all built-in modules). Thus, I'm proposing we replace the slightly
unwieldy set of positional params with a single passed-around struct,
which members of the interface's "advice stack" can modify at will. See
implementation for details.

Note that these changes currently require those from "bug#62834: Make
erc-button navigation more flexible". Thanks.

[0001-5.6-Improve-erc-button-modify-nick-function-interfac.patch (text/x-patch, attachment)]

[0002-5.6-Revise-FORM-as-function-interface-in-erc-button-.patch (text/x-patch, attachment)]

Message #17 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Sat, 29 Apr 2023 08:56:06 -0700

[Message part 1 (text/plain, inline)]

"J.P." <jp <at> neverwas.me> writes:

> The same general thinking applies to the nicks-specific buttonizer as
> well, though it being intrinsically special and, for now, internal means
> we can take more liberties in inconveniencing its consumers (which are
> all built-in modules). Thus, I'm proposing we replace the slightly
> unwieldy set of positional params with a single passed-around struct,
> which members of the interface's "advice stack" can modify at will. See
> implementation for details.

Previously, consumers of the new nick-buttonizer interface were given a
look at every single word in a message. But they should only really care
about those with an associated `erc-server-user' object, meaning known
nicks. And while it's true that some might want to create these
associations on the fly, I think they're better off doing so earlier on,
both to help separate concerns and to skip the hassle of determining
whether a candidate is a speaker or a mention.

To that end, I've carved out a couple more access points to influence
how nick buttonizing happens. Both use the same pattern of "local advice
around a function-interface variable," which I've come to regard as the
most predictable and flexible for building new internal APIs. The first
lives in `erc-server-PRIVMSG' and integrates with the old
`erc-format-nick-function', which takes the user object it spits out.
The second runs right before the nick buttonizer but only as a fallback
when the usual means of finding an `erc-server-user' object from a
candidate fails. It's set to `ignore' by default.

[0000-v1-v2.diff (text/x-patch, attachment)]

[0001-5.6-Revise-FORM-as-function-interface-in-erc-button-.patch (text/x-patch, attachment)]

[0002-5.6-Improve-erc-button-modify-nick-function-interfac.patch (text/x-patch, attachment)]

[0003-5.6-Use-getter-for-finding-users-in-erc-server-PRIVM.patch (text/x-patch, attachment)]

Message #22 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Tue, 23 May 2023 06:35:05 -0700

[Message part 1 (text/plain, inline)]

The new DWIM `erc-tab' command defers to pcomplete inside the prompt
area and runs a hook otherwise. But the hook's interface demands that
implementing members handle a raw prefix arg for no compelling reason.
And most of these members are movement-focused commands whose natural
interactive spec tends to be numeric, making for some roundabout
boilerplate awkwardness. This patch switches to numeric prefixes
everywhere, which is how things likely should have been originally.

[0001-5.6-Simplify-erc-tab-interface.patch (text/x-patch, attachment)]

Message #25 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Fri, 02 Jun 2023 07:07:15 -0700

[Message part 1 (text/plain, inline)]

Some of the recent changes to this module were perhaps not handled as
sensibly as they could've been. The broad strokes seem sane enough, but
a few key aspects affecting the user experience were left too rough
around the edges for my taste. My main gripe involves the partial
deprecation of the `nicknames' entry for the option `erc-button-alist'.
After some reflection, I'm now of the opinion that imposing a specific
constraint on a specific slot in a specific default entry that may not
even be present after customization is just too messy a notion to foist
on users or to try and communicate in a doc string.

A better approach, I now feel, is to remove the troublesome `nicknames'
entry altogether and take special care behind the scenes to gracefully
accommodate users who still have it present in their configs. The
attached changes attempt something like this and also tidy up other odds
and ends in erc-button.el. Note that the second patch also appears in
bug#63569 and is only included here for its ERC-NEWS changes, which
touch on some of the above. Thanks.

[0001-5.6-Deprecate-nicknames-entry-in-erc-button-alist.patch (text/x-patch, attachment)]

[0002-5.6-Allow-ERC-modules-to-extend-erc-nick-popup-alist.patch (text/x-patch, attachment)]

Message #32 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Wed, 13 Sep 2023 07:09:54 -0700

[Message part 1 (text/plain, inline)]

This feature added an internal interface that allows for creating
ephemeral "phantom" users, which help make nickname buttonizing possible
with protocol bridges and chat-history playback. Unfortunately, the
original design cut a major corner that it shouldn't have. Essentially,
I wanted to avoid adding an `erc-channel-user' to accompany every
phantom `erc-server-user' being spoofed, primarily because it's a waste
of space. However, I've come to believe this shortcut won't be worth the
added maintenance burden of having to check for missing objects when
performing related operations. Attached is a patch to fix this.

[0001-5.6-Spoof-channel-users-in-erc-button-phantom-users-.patch (text/x-patch, attachment)]

Message #35 received at 60933 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 60933 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#60933: 30.0.50; ERC >5.5: Make buttonizing more extensible
Date: Tue, 19 Sep 2023 06:28:40 -0700

"J.P." <jp <at> neverwas.me> writes:

> This feature added an internal interface that allows for creating
> ephemeral "phantom" users, which help make nickname buttonizing possible
> with protocol bridges and chat-history playback. Unfortunately, the
> original design cut a major corner that it shouldn't have. Essentially,
> I wanted to avoid adding an `erc-channel-user' to accompany every
> phantom `erc-server-user' being spoofed, primarily because it's a waste
> of space. However, I've come to believe this shortcut won't be worth the
> added maintenance burden of having to check for missing objects when
> performing related operations. Attached is a patch to fix this.

A version of this was installed as

  a0ed463baba Spoof channel users in erc-button--phantom-users-mode

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.