29.0.50; Improve ERC's handling of multiline prompt input

[J.P.]

Tags: patch

ERC suffers from a few related issues concerning the early handling of
user input at the prompt. Especially troublesome is "multiline" input
containing line feeds and/or carriage returns. This patch (or at least
this discussion) aims to tackle both.

Any solution should probably address these fundamental UX questions:

1. What should happen when a user submits multiline input containing
   empty lines? Should these be padded so they're not rejected by the
   server? If so, where in the processing pipeline should that occur?
   Should `erc-send-whitespace-lines' play a role here?

   This patch says yes to the latter and interprets that option as
   meaning "preserve whitespace-only lines and create them as necessary
   from blank ones." As to where padding should happen, this patch punts
   and retains the existing (unfortunate) practice of treating them at
   the last minute.

2. Should trailing blank lines be treated differently? If so, how?
   Should they be auto-padded? Simply dropped? Or should encountering
   them raise an error?

   When `erc-send-whitespace-lines' is non-nil, this patch drops
   trailing blanks by default, but it also provides an escape hatch.

3. When `erc-send-whitespace-lines' is non-nil, should it auto-pad a
   submission consisting of a single empty line? Should it allow a
   whitespace-only singleton through?

   This patch says no to the first and yes to the second.

4. Should slash commands, like /MSG be allowed to lead a multiline
   submission?

   This patch says no, still choosing to interpret commands as always
   consisting of a single line.

To offer some flexibility, I'm introducing a hook to perform some
validation on the input being submitted. It comes prepopulated with
functions that replicate existing behavior, such as ensuring point
resides within the input area. It also contains an additional function
to perform the blank-detection business. While it's true that multiple
members of this hook may end up repeating some basic operations (such as
splitting the input string), at present, this isn't the case, and such
waste is pretty negligible anyway since this is an interactive function.

There is one behavioral change being introduced that doesn't come
with an escape hatch, and that's the preservation of input when
a validation check fails. Previously, a user's input would be wiped
out, which seems undesirable and unnecessary in all cases (IMO).

For these and any other, less significant changes not mentioned, the
floor is open for questions and debate, as usual. Thanks.

(See also: "bug#50008: 28.0.50; ERC sends empty lines with user input"
and "bug#50006: 28.0.50; remove deprecated option erc-send-pre-hook".)


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.31, cairo 
version 1.17.4)
 of 2022-03-23 built on localhost
Repository revision: fed9a353dbe79a7a6acc74c1e223c46e7541e627
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 35 (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 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 rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip 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
simple cl-generic 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 cl-preloaded button 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 x multi-tty
make-network-process emacs)

Memory information:
((conses 16 43960 5198)
 (symbols 48 5704 1)
 (strings 32 15802 1589)
 (string-bytes 1 526831)
 (vectors 16 12066)
 (vector-slots 8 167842 8149)
 (floats 8 20 55)
 (intervals 56 241 0)
 (buffers 992 11))

0001-Fix-regression-in-erc-send-input-line.patch
Description: Text Data

0002-Improve-ERC-s-handling-of-multiline-prompt-input.patch
Description: Text Data