bug#66073: 30.0.50; ERC 5.6: Improve handling of blank lines at ERC's prompt

[J.P.]

Tags: patch

ERC has made some strides in recent versions when it comes to dealing
with unwelcome or irregular whitespace in user input [1]. But rough
edges definitely remain. One important option influencing this area is
`erc-warn-about-blank-lines'. It concerns feedback in the echo area from
blank lines submitted at the prompt [2]. Its purview overlaps somewhat
with that of `erc-send-whitespace-lines', though the latter option also
affects implicit trimming and padding. This proposal attempts to clarify
and formalize ERC's treatment of both.

One thing this bug does not attempt is to define and attain optimal UX
in this area because finding a sweet spot between user friendliness and
compatibility is likely infeasible given the many options whose defaults
can't be changed without breaking ancient bots and user code [3].
Instead, this bug attempts to file down some burry bits affecting how
submitted input is massaged and how accompanying feedback is
communicated, both currently inconsistent and not super predictable. (It
also attempts to fix a closely related bug [4].)

To better understand what's being proposed here, compare the last row of
the following table with the "desired output" below (see [5] for
baseline cases):

  | vers/opts | ""  | " " | "\n"  | "\n " | " \n" | "\n\n" | "a\n" | "a\n " | 
"a\n \nb" |
  
|-----------+-----+-----+-------+-------+-------+--------+-------+--------+-----------|
  | 28 +w,-s* | err | e/c | e/c   | e/c   | e/c   | e/c    | a,\s  | a,\s   | 
a,\s,b    |
  | 28 -w,-s  | nop | clr | clr   | clr   | clr   | clr    | a,\s  | a,\s   | 
a,\s,b    |
  | 28 +w,+s  | err | \s  | \s,\s | \s,\s | \s,\s | \s(x3) | a,\s  | a,\s   | 
a,\s,b    |
  | 28 -w,+s  | nop | \s  | \s,\s | \s,\s | \s,\s | \s(x3) | a,\s  | a,\s   | 
a,\s,b    |
  
|-----------+-----+-----+-------+-------+-------+--------+-------+--------+-----------|
  | 29 +w,-s* | err | err | err   | err   | err   | err    | err   | err    | 
err       |
  | 29 -w,-s  | nop | nop | nop   | nop   | nop   | nop    | nop   | nop    | 
nop       |
  | 29 +w,+s  | err | \s  | \s    | \s,\s | \s    | \s     | a     | a,\s   | 
a,\s,b    |
  | 29 -w,+s  | nop | \s  | \s    | \s,\s | \s    | \s     | a     | a,\s   | 
a,\s,b    |
  
|-----------+-----+-----+-------+-------+-------+--------+-------+--------+-----------|
  | 30 +w,-s* | err | err | err   | err   | err   | err    | err   | err    | 
err       |
  | 30 -w,-s  | fbe | fbe | fbe   | fbe   | fbe   | fbe    | fbe   | fbe    | 
fbe       |
  | 30 +w,+s  | nop | \s  | clr   | \s,\s | \s    | clr    | a     | a,\s   | 
a,\s,b    |
  | 30 -w,+s  | nop | \s  | clr   | \s,\s | \s    | clr    | a     | a,\s   | 
a,\s,b    |

  Desired output:

  | 30 +w,-s* | err | *er | *er   | *er    | *er  | *er    | *er   | *er    | 
*er       |
  | 30 -w,-s  | nop | nop | nop   | nop    | nop  | nop    | nop   | nop    | 
nop       |
  | 30 +w,+s  | err | *\s | *\s   | *\s,\s | *\s  | *\s    | *a    | *a,\s  | 
*a,\s,b   |
  | 30 -w,+s  | nop | \s  | \s    | \s,\s  | \s   | \s     | a     | a,\s   | 
a,\s,b    |
  
  - w: `erc-warn-about-blank-lines'
  - s: `erc-send-whitespace-lines'
  - +w,-s*: default configuration as seen with Emacs -Q
  - err: signal `user-error' but leave input area untouched
  - nop: No-op; leave input untouched
  - fbe: fallback error (likely a bug [4]), otherwise like err
  - clr: clear entire prompt area and don't send anything
  - e/c: signal a `user-error' and clear the prompt area
  - *er: detailed error with null/white tallies and other context
  - <char...>: outgoing message (\s is a space), implies clearing
  - *<char...>: same, but with detailed feedback in echo area

For examples of the improved feedback wording, see the attached test
called `erc--check-prompt-input-for-multiline-blanks/explanations'. The
basic idea is to report on the number of lines padded and/or stripped
when `erc-send-whitespace-lines' is enabled and the number of blanks
and/or trailing lines detected when that option is nil (as long as
`erc-warn-about-blank-lines' is still enabled).

One idea discussed recently on Libera was to enable implicit trimming of
trailing blanks by default, at least for the common "a\n" case. While
certainly possible, doing so would make for some complicated explaining
in the doc strings of both options. And adding yet another knob to
achieve this effect would only further complicate an already unruly mix.
Hopefully, the proposed solution of richer feedback will prove
sufficient enough to fill this void.

Lastly, this bug also addresses some design mishaps in this same general
area. For example, the functions `erc--blank-in-multiline-input-p' and
`erc--discard-trailing-multiline-nulls' really shouldn't concern
themselves with user options. Rather, they should just report on or
process data as requested by their options-aware caller (the function
`erc--check-prompt-input-for-excess-lines'), which should be the sole
arbiter of what gets sent and warned about (and how).

As always, if anyone has any better ideas, please say so. I'd like to
solve this before the next release, which is hopefully right around the
corner. Thanks.


[1] Related bugs:

    bug#54536: 29.0.50; Improve ERC's handling of multiline prompt input
    bug#62947: 30.0.50; ERC 5.6: Improve partitioning of outgoing messages

[2] Here, "blank" refers to empty lines as well as those consisting
    entirely of whitespace. However, ERC at times also uses "whitespace"
    to refer to empty lines.

[3] Plenty of user code relies on simulating user interaction, for
    example, by inserting hunks of text at the prompt and calling
    `erc-send-current-line' instead of using lower level library
    functions. Such code would surely suffer were it to be interrupted
    by a dialog asking for confirmation before sending. For an example
    of saner options values that could one day become defaults (e.g.,
    in ERC 6.0) see "(erc) Sample Configuration" in the manual.

[4] A second, comparatively minor issue also addressed by this bug is
    more or less a clear-cut regression, shown as "30 -w,-s" in the
    table (note all the fbe's). Basically, in all recent releases,
    disabling `erc-warn-about-blank-lines' resulted in a `ding'
    (accompanied by a clearing of input in 27 and 28). Unfortunately,
    the version on HEAD just prints a rather useless error message
    instead: "Input error: invalid".

[5] Baseline behavior identical across all versions, regardless of
    options:

    |                      | a | "a\nb" |
    |----------------------+---+--------|
    | all versions/options | a | a,b    |


In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.6) of 2023-09-17 built on localhost
Repository revision: a0ed463babaa6301dfe2fecc27e2a6c92eb0d90c
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 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 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 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 emacs)

Memory information:
((conses 16 120902 9231) (symbols 48 10034 0) (strings 32 24640 2237)
 (string-bytes 1 824086) (vectors 16 14496)
 (vector-slots 8 204135 15157) (floats 8 24 45) (intervals 56 242 0)
 (buffers 984 10))

0001-5.6-Improve-erc-warn-about-blank-lines-behavior.patch
Description: Text Data