GNU bug report logs - #68861
30.0.50; ERC 5.x: Introduce a modern message-insertion API

Previous Next

To reply to this bug, email your comments to 68861 AT debbugs.gnu.org.

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.x: Introduce a modern message-insertion API
Date: Wed, 31 Jan 2024 19:07:58 -0800

Severity: wishlist

Some recent ramblings on this topic (by me) were crudely tacked on to
the end of the now closed bug#67677. In summary, the solution originally
delivered by that bug of having all chat messages formatted by literal
`format-spec' templates was left wanting in terms of an easily exposable
and extendable public API. What it currently provides is merely a
declarative means of defining the layout of a message in an easily
verifiable manner, which is helpful for gaining an intuition into how a
message will look upon insertion. But it leaves unaddressed a
requirement commonly expressed by third parties, namely, a convenient
and straightforward way of influencing specific portions of a message
prior to formatting and without regard for overall layout.

The first attempt at providing such granular access was the awkwardly
termed "msgfspec" proposal offered in bug#67677 [1]. While supposedly
focused on convenience, it suffered from a fatal flaw in that modifying
a base template still involved scanning to splice in additions, even if
mostly hidden from the user. Instead, I think it'd be preferable to take
a more traditional tack and preserve the various constituent parts of a
template as separate nodes in a tree-like structure for deferred
assembly just prior to formatting, perhaps in conjunction with some
caching mechanism. The literal, propertized base template would still
feature prominently as part of a template class's definition, but its
role would be reduced to serving as input for a validation scheme.

In terms of proposals, I think a successful candidate for adoption
should provide at least two working demos, preferably among the
following:

  - Bidirectional input and display
  - Headline style messages w. speaker on a separate line
  - Text substitution (language translation, encryption, etc.)
  - Display names (e.g., for bridges, perhaps reversible)

My guess is this feature won't be ready for ERC 5.6, especially without
explicit interest from others. As such, proposals (from me) may be based
atop work that includes changes not currently on HEAD, such as those
from #49860.

Thanks.

[1] The current "msgfpec" demo linked to in #68265 will be moved to a
    location reflecting this bug number.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2024-01-04 built on localhost
Repository revision: 1081e975c9370999df1a288b117bfd9053050d21
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 37 (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
NATIVE_COMP 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
  minibuffer-regexp-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 epg rfc6068 epg-config gnus-util
time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils compile text-property-search comint ansi-osc
ansi-color ring comp-run comp-common erc derived auth-source eieio
eieio-core password-cache json map format-spec erc-backend erc-networks
easy-mmode byte-opt bytecomp byte-compile erc-common inline cl-extra
help-mode erc-compat cl-seq cl-macs gv pcase rx subr-x cl-loaddefs
cl-lib 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 touch-screen 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 gtk
x-toolkit xinput2 x multi-tty move-toolbar make-network-process
native-compile emacs)

Memory information:
((conses 16 149907 11404) (symbols 48 11361 0) (strings 32 27740 4779)
 (string-bytes 1 971593) (vectors 16 17647)
 (vector-slots 8 310679 13296) (floats 8 27 25) (intervals 56 330 0)
 (buffers 976 12))

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

From: "J.P." <jp <at> neverwas.me>
To: 68861 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#68861: 30.0.50; ERC 5.x: Introduce a modern
 message-insertion API
Date: Mon, 04 Mar 2024 19:03:29 -0800

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

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

> In terms of proposals, I think a successful candidate for adoption
> should provide at least two working demos, preferably among the
> following:
>
>   - Bidirectional input and display
>   - Headline style messages w. speaker on a separate line
>   - Text substitution (language translation, encryption, etc.)
>   - Display names (e.g., for bridges, perhaps reversible)
>
> My guess is this feature won't be ready for ERC 5.6, especially without
> explicit interest from others. As such, proposals (from me) may be based
> atop work that includes changes not currently on HEAD, such as those
> from #49860.

In the absence of a coherent proposal for a revamped message preparation
and insertion API, I believe it may be wise to collect counterexamples
exhibiting some of the desperate and ugly measures taken to access the
various components of a message and influence its assembly for display.
The objective here is to emphasize the considerable shortcomings
currently on offer in this regard.

To that end, I've attached an adapted version of a POC from another bug
(#49860) as a working, practical example of the problem. It attempts to
introduce speaker display names for bridge bots by way of a new module.
To be clear, this is not being proposed for inclusion in ERC 5.6 (or any
subsequent version). Rather, its purpose is in keeping with the
aforementioned goal of underscoring the deficiencies of the current
situation. Of particular note is the fourth patch and the terrible
lengths it goes to in order to access and manipulate the content portion
of chat messages before they're fused to their leading "<speaker> "
prefixes.

Folks at home: even if you don't try this patch set, please look at the
module setup code and the interfaces it consumes. And please do post
your own scenarios here. They need not come in the form of patches or
include any working code.

Thanks.

[0001-5.x-Add-predicate-for-logical-ERC-module-activation.patch (text/x-patch, attachment)]

[0002-5.x-Indirectly-call-erc-fill-wrap-continued-message-.patch (text/x-patch, attachment)]

[0003-5.x-Expose-erc-response-object-as-dynamic-variable.patch (text/x-patch, attachment)]

[0004-POC-Replace-erc-cmem-from-nick-function-args-with-st.patch (text/x-patch, attachment)]

[0005-POC-Add-general-display-name-support-to-ERC.patch (text/x-patch, attachment)]

Previous Next

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