GNU bug report logs - #62947
30.0.50; ERC 5.6: Improve partitioning of outgoing messages

Previous Next

Package: emacs;

Reported by: "J.P." <jp <at> neverwas.me>

Date: Wed, 19 Apr 2023 14:58:01 UTC

Severity: normal

Tags: patch

Found in version 30.0.50

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

Bug is archived. No further changes may be made.

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

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

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to emacs-erc <at> gnu.org, bug-gnu-emacs <at> gnu.org:
bug#62947; Package emacs. (Wed, 19 Apr 2023 14:58:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "J.P." <jp <at> neverwas.me>:
New bug report received and forwarded. Copy sent to emacs-erc <at> gnu.org, bug-gnu-emacs <at> gnu.org. (Wed, 19 Apr 2023 14:58:02 GMT) Full text and rfc822 format available.

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: Improve partitioning of outgoing messages
Date: Wed, 19 Apr 2023 07:56:47 -0700
[Message part 1 (text/plain, inline)]
Tags: patch

Hi,

Someone on Libera recently observed their messages being split into much
smaller chunks than expected. And apparently this problem isn't much of
a secret either. It seems to boil down to `erc-split-line's reliance on
`fill-region' for rejiggering messages on their way out the door. If you
poke around that area long enough, you'll see that all that fill-related
figuring happens column-wise, which means messages always fall under the
protocol limit (and thus the radar). I've made an attempt at correcting
this, but it'd be nice if someone better versed in Emacs fundamentals
could take a quick look. (All the doing happens in the second patch, in
the new function `erc--split-line'.)

Thanks.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.37, cairo version 1.17.6) of 2023-04-19 built on localhost
Repository revision: c279d65199df4749f649c29aca210419ab85af1a
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
  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 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 63580 9434)
 (symbols 48 8536 0)
 (strings 32 23148 1404)
 (string-bytes 1 668662)
 (vectors 16 14963)
 (vector-slots 8 206689 9758)
 (floats 8 24 29)
 (intervals 56 228 0)
 (buffers 976 10))

[0001-5.6-Don-t-send-multiline-slash-commands-as-msgs-in-E.patch (text/x-patch, attachment)]
[0002-5.6-Redo-line-splitting-for-outgoing-messages-in-ERC.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#62947; Package emacs. (Tue, 02 May 2023 04:40:02 GMT) Full text and rfc822 format available.

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

From: "J.P." <jp <at> neverwas.me>
To: 62947 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62947: 30.0.50; ERC 5.6: Improve partitioning of outgoing
 messages
Date: Mon, 01 May 2023 21:39:02 -0700
[Message part 1 (text/plain, inline)]
This bug presents an opportunity for revisiting how input handling and
pre-send hook management happen in ERC. The groundwork has already been
laid by ERC 5.5, so we might as well try inching closer to something
more responsive and intuitive. This being ERC, flexibility is also a
priority, but for now, I'm thinking we should focus on honoring existing
interfaces rather than adding new ones.

In the current envisioning (v2 attached), this imagined shift toward
smarter input handling starts by moving all line splitting and related
input preparation forward so it runs earlier, alongside the various
validation checks. Doing this alone could, for example, give us
friendlier feedback when crossing the `erc-inhibit-multiline-input'
threshold, with the rejected goods being invited to hang around in the
prompt area for successive tweaking and do-overs (instead of seeing
their mutilated pieces clutter up the kill ring, which more or less
describes the current state of affairs).

The path I'm proposing does come with one minor hiccup in terms of
corner-case breakage, but only for third-parties that expect
protocol-length line splitting to occur after the more send-focused
hooks run (chiefly, `erc-pre-send-functions'). To smooth things over,
I'm proposing an off-by-default compat switch, which would manifest as a
new "refoldp" slot for the `erc-input' object that's shared among these
hook members. Third parties can toggle this on if they'd rather not
trust other members to perform the necessary bookeeping to keep line
lengths in check.

If you'd like to try this, just

  (setq erc-inhibit-multiline-input t
        erc-send-whitespace-lines t)

and submit a long passage at the prompt.

[0000-v1-v2.diff (text/x-patch, attachment)]
[0001-5.6-Don-t-send-multiline-slash-commands-as-msgs-in-E.patch (text/x-patch, attachment)]
[0002-5.6-Redo-line-splitting-for-outgoing-messages-in-ERC.patch (text/x-patch, attachment)]
[0003-5.6-Preprocess-prompt-input-linewise-in-ERC.patch (text/x-patch, attachment)]

Reply sent to "J.P." <jp <at> neverwas.me>:
You have taken responsibility. (Sat, 06 May 2023 00:55:02 GMT) Full text and rfc822 format available.

Notification sent to "J.P." <jp <at> neverwas.me>:
bug acknowledged by developer. (Sat, 06 May 2023 00:55:02 GMT) Full text and rfc822 format available.

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

From: "J.P." <jp <at> neverwas.me>
To: 62947-done <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62947: 30.0.50; ERC 5.6: Improve partitioning of outgoing
 messages
Date: Fri, 05 May 2023 17:54:47 -0700
"J.P." <jp <at> neverwas.me> writes:

> The path I'm proposing does come with one minor hiccup in terms of
> corner-case breakage, but only for third-parties that expect
> protocol-length line splitting to occur after the more send-focused
> hooks run (chiefly, `erc-pre-send-functions'). To smooth things over,
> I'm proposing an off-by-default compat switch, which would manifest as a
> new "refoldp" slot for the `erc-input' object that's shared among these
> hook members. Third parties can toggle this on if they'd rather not
> trust other members to perform the necessary bookeeping to keep line
> lengths in check.
>
> If you'd like to try this, just
>
>   (setq erc-inhibit-multiline-input t
>         erc-send-whitespace-lines t)
>
> and submit a long passage at the prompt.

These changes have been added, perhaps prematurely, as

  https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=3a5a6fce

Thanks and closing (for now).




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 03 Jun 2023 11:24:08 GMT) Full text and rfc822 format available.

bug unarchived. Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Thu, 07 Dec 2023 03:50:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#62947; Package emacs. (Thu, 07 Dec 2023 07:20:02 GMT) Full text and rfc822 format available.

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

From: "J.P." <jp <at> neverwas.me>
To: 62947 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#62947: 30.0.50; ERC 5.6: Improve partitioning of outgoing
 messages
Date: Wed, 06 Dec 2023 23:19:18 -0800
[Message part 1 (text/plain, inline)]
This fix introduced an innocuous though technically breaking change in
the definition of `erc-input' (the struct). Basically, it added a new
slot, `refoldp', to allow users access to something resembling the
pre-5.6 behavior, where protocol-oriented message splitting would take
place after `erc-pre-send-functions' ran. That is, setting the slot to t
is meant to buy you some of that old functionality in the form of a
second split. (The new behavior of only splitting beforehand favors
interactive client users over bot/module authors.)

However, reflecting back on this, I think it wouldn't kill us to account
for the unlikely possibility of someone "subclassing" `erc-input' for
use outside this hook. In most cases, I believe simply recompiling their
dependent libraries would solve the issue, but why chance it if we don't
have to? Hence the attached change, which removes the slot but "spoofs"
its would-be accessor, `erc-input-refoldp', while the hook runs. I
originally went with a name that differed from that of the would-be
accessor, but this feature has been on HEAD for a while, so keeping it
seemed the less disruptive option.

[0006-5.6-Make-erc-input-s-refoldp-slot-conditionally-avai.patch (text/x-patch, attachment)]

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 04 Jan 2024 12:24:07 GMT) Full text and rfc822 format available.

This bug report was last modified 85 days ago.

Previous Next


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