Subject: 30.0.50; ERC 5.x: Introduce a modern message-insertion API

From: "J.P." <[email-masked]>
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))