GNU bug report logs - #67032
30.0.50; ERC 5.6-git: Treat erc-send-message more responsibly

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 67032 in the body.
You can then email your comments to 67032 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.6-git: Treat erc-send-message more responsibly
Date: Thu, 09 Nov 2023 18:26:51 -0800

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

Tags: patch

The function `erc-send-message', as used in-tree, sends and inserts
messages produced by handlers for certain slash commands. But rather
than being a simplistic analog for `erc-send-current-line', it's used in
practice to take over for that function in situations where the actual
prompt input is modified or replaced (and possibly reprocessed anew as
simulated "meta" input, as is the case with /SAY). From the user's
perspective, such messages are supposed to look and feel like all other
outgoing chat messages. However, at present, they don't.

I was originally hoping to introduce these changes for the next release,
but a bug has surfaced that exposes a major problem with the current
implementation.

From emacs -Q:

  1. Connect and join a channel
  2. Type /sm RET at the prompt
  3. Check the server buffer for a "message too long" error

The issue here is not that we've reached a module count large enough to
tip the outgoing text produced by `erc-modes' over the byte limit but
rather that `erc-send-message' has outgrown its usefulness and must now
evolve into something more robust and capable (in a backward compatible
way, of course).

In tackling this, I've opted to sidestep a few related concerns that
will have to be dealt with eventually. The first has to do with
discovering and possibly reintegrating whatever role the `noncommands'
module is designed to play in processing specialty slash commands, like
those reliant on `erc-send-message'. These days (reaching as far back as
Emacs 26.1), the module appears to effectively be a no-op, at least with
the default client configuration. Until we know more, I'm inclined to
let it rot away in erc-goodies, since its code only runs on interactive
input anyway.

Another issue I've avoided confronting with these changes is the ugly
relationship between `erc-format-privmessage', `erc-server-PRIVMSG',
`erc-format-nick-function', and `erc-display-message'. Sooner or later,
most of the speaker-related formatting shared between this bunch will
need to be consolidated and likely made accessible from
`erc-display-message' alone so that various next-gen features, such as
displaying messages from other devices sharing the same presence, can be
handled properly and made to look like the result of local prompt input.
All in good time, I guess.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2023-11-09 built on localhost
Repository revision: 9c9b87639f919169eed956e9e7cce472d3a2f719
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 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 derived epg rfc6068 epg-config
gnus-util text-property-search 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 erc auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map format-spec
cl-loaddefs cl-lib erc-backend 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 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 emacs)

Memory information:
((conses 16 66646 9545) (symbols 48 8720 0) (strings 32 23596 1638)
 (string-bytes 1 688941) (vectors 16 16134)
 (vector-slots 8 216395 14139) (floats 8 24 47) (intervals 56 242 0)
 (buffers 984 10))

[0001-5.6-Make-ERC-error-notice-formatting-more-consistent.patch (text/x-patch, attachment)]

[0002-5.6-Make-ERC-s-message-sending-functions-more-flexib.patch (text/x-patch, attachment)]

[0003-5.6-Simplify-logic-for-inserting-ERC-prompt-input.patch (text/x-patch, attachment)]

[0004-5.6-Slightly-simplify-text-props-on-echoed-ERC-input.patch (text/x-patch, attachment)]

[0005-5.6-Don-t-output-non-modules-in-erc-modes.patch (text/x-patch, attachment)]

Message #6 received at 67032-quiet <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 67032-quiet <at> debbugs.gnu.org
Subject: Re: bug#67032: 30.0.50; ERC 5.6-git: Treat erc-send-message more
 responsibly
Date: Fri, 10 Nov 2023 17:09:41 -0800

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

Screenshot storage.

[erc-command-indicator.png (image/png, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: 67032 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#67032: 30.0.50; ERC 5.6-git: Treat erc-send-message more
 responsibly
Date: Fri, 10 Nov 2023 17:15:14 -0800

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

v2. Revive `erc-command-indicator' functionality as new module.

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

> In tackling this, I've opted to sidestep a few related concerns that
> will have to be dealt with eventually. The first has to do with
> discovering and possibly reintegrating whatever role the `noncommands'
> module is designed to play in processing specialty slash commands, like
> those reliant on `erc-send-message'. These days (reaching as far back as
> Emacs 26.1), the module appears to effectively be a no-op, at least with
> the default client configuration. Until we know more, I'm inclined to
> let it rot away in erc-goodies, since its code only runs on interactive
> input anyway.

Actually, I've gone ahead and done some cursory spelunking in hopes of
shedding some light on this `noncommands' quandary. First off, there's
no relevant mention of `erc-display-command' or `erc-command-indicator'
in the old erc-discuss archives. But it's my current understanding that
the module seems to have been effectively sidelined when the lone call
site for `erc-display-command' was deep sixed in

  d1036d288de backport: erc bugfixes

(This was back in November of 2013, under 5.3.x and what became Emacs
24.5.) Strangely, that commit did not include any change log or ERC-NEWS
mentions, which is unfortunate because it's wide-ranging and largely
nontrivial. For example, it left behind related faces and options, like
`erc-command-indicator', thereupon effectively neutering them along with
`noncommands'. More recently, `erc-display-command' was commented out in

  0c599ee2e2c * lisp/erc/erc.el: Use `run-hook-with-args` for
              `erc-pre-send-functions`

and later removed by

  a63ed6f78a6 Remove duplicate ERC prompt on reconnect

but the damage had long since been done. My point in drudging this up is
merely to highlight where the behavior concerned diverged and that we'll
likely never know why. I really have no interest in relitigating ancient
motivations and methods. (It's quite possible that discussions did take
place elsewhere, like on Freenode or the old sourceforge list.)

Anyway, since both the interface (options, fonts) and infrastructure are
still in place, I think it behooves us to revive this functionality, not
least as a signal to others that ERC picks up after itself (eventually).
I've thus added some changes to this effect (see last patch).

Screenshot:

https://debbugs.gnu.org/cgi/bugreport.cgi?msg=6;filename=erc-command-indicator.png;att=1;bug=67032

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

[0001-5.6-Make-ERC-error-notice-formatting-more-consistent.patch (text/x-patch, attachment)]

[0002-5.6-Make-ERC-s-message-sending-functions-more-flexib.patch (text/x-patch, attachment)]

[0003-5.6-Simplify-logic-for-inserting-ERC-prompt-input.patch (text/x-patch, attachment)]

[0004-5.6-Slightly-simplify-text-props-on-echoed-ERC-input.patch (text/x-patch, attachment)]

[0005-5.6-Don-t-output-non-modules-in-erc-modes.patch (text/x-patch, attachment)]

[0006-5.6-Revive-erc-display-command-as-module-command-ind.patch (text/x-patch, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: 67032-done <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#67032: 30.0.50; ERC 5.6-git: Treat erc-send-message more
 responsibly
Date: Mon, 13 Nov 2023 12:11:10 -0800

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

> v2. Revive `erc-command-indicator' functionality as new module.
>
> [...]
>
> but the damage had long since been done. My point in drudging this up is

dredging*

> merely to highlight where the behavior concerned diverged and that we'll
> likely never know why. I really have no interest in relitigating ancient
> motivations and methods. (It's quite possible that discussions did take
> place elsewhere, like on Freenode or the old sourceforge list.)
>
> Anyway, since both the interface (options, fonts) and infrastructure are
> still in place, I think it behooves us to revive this functionality, not
> least as a signal to others that ERC picks up after itself (eventually).
> I've thus added some changes to this effect (see last patch).

This has been installed as

  1d2aa130cae * Revive erc-command-indicator as new module

And changes similar to those initially proposed can be found in and
around

  174b3dd9bd7 * Make nested input handling more robust in ERC

Thanks and closing.

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

From: "J.P." <jp <at> neverwas.me>
To: 67032 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#67032: 30.0.50; ERC 5.6-git: Treat erc-send-message more
 responsibly
Date: Wed, 13 Mar 2024 19:11:30 -0700

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

> This has been installed as
>
>   1d2aa130cae * Revive erc-command-indicator as new module

One aspect this change should've addressed but didn't was using the
revived `command-indicator' facility in `erc-load-irc-script-lines' to
make its output more predictable and consistent with other displayed
messages. While leaving it to rot would of course be safer, I suspect
it's rarely used enough to warrant the risk. An ancillary benefit of
fixing this is that it helps clarify the role of boolean return values
for `erc-process-input-line', `erc-send-input-line-function',
`erc-message', and the various `erc-cmd-FOO' slash-command handlers.
See second patch (lacks tests).

Thanks.

P.S. The commit named above unfortunately cites the wrong bug number
(67031) in its commit message.

[0001-5.6-Restore-leading-space-to-right-margin-stamps-in-.patch (text/x-patch, attachment)]

[0002-5.x-Use-command-indicator-in-erc-load-irc-script-lin.patch (text/x-patch, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: 67032 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#67032: 30.0.50; ERC 5.6-git: Treat erc-send-message more
 responsibly
Date: Thu, 28 Mar 2024 10:34:50 -0700

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

> One aspect this change should've addressed but didn't was using the
> revived `command-indicator' facility in `erc-load-irc-script-lines' to
> make its output more predictable and consistent with other displayed
> messages. While leaving it to rot would of course be safer, I suspect
> it's rarely used enough to warrant the risk. An ancillary benefit of
> fixing this is that it helps clarify the role of boolean return values
> for `erc-process-input-line', `erc-send-input-line-function',
> `erc-message', and the various `erc-cmd-FOO' slash-command handlers.
> See second patch (lacks tests).

This has been installed as

  a46789b56af * Reuse command-indicator code for script lines in ERC

This bug is already closed.

Previous Next

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