GNU bug report logs -
#66073
30.0.50; ERC 5.6: Improve handling of blank lines at ERC's prompt
Previous Next
Reported by: "J.P." <jp <at> neverwas.me>
Date: Mon, 18 Sep 2023 14:26:02 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 66073 in the body.
You can then email your comments to 66073 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
emacs-erc <at> gnu.org, bug-gnu-emacs <at> gnu.org
:
bug#66073
; Package
emacs
.
(Mon, 18 Sep 2023 14:26:02 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
.
(Mon, 18 Sep 2023 14:26:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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 (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#66073
; Package
emacs
.
(Fri, 22 Sep 2023 14:22:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 66073 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
v2. Fix faulty interaction with `erc-inhibit-multiline-input'. Move
slash-command detection to input-review hook.
[0000-v1-v2.diff (text/x-patch, attachment)]
[0001-Increase-ERC-test-server-queue-size.patch (text/x-patch, attachment)]
[0002-Exempt-text-scale-mode-from-erc-scrolltobottom-all.patch (text/x-patch, attachment)]
[0003-5.6-Improve-erc-warn-about-blank-lines-behavior.patch (text/x-patch, attachment)]
[0004-Detect-slash-commands-in-erc-input-review-functions.patch (text/x-patch, attachment)]
Reply sent
to
"J.P." <jp <at> neverwas.me>
:
You have taken responsibility.
(Tue, 03 Oct 2023 01:22:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
"J.P." <jp <at> neverwas.me>
:
bug acknowledged by developer.
(Tue, 03 Oct 2023 01:22:02 GMT)
Full text and
rfc822 format available.
Message #13 received at 66073-done <at> debbugs.gnu.org (full text, mbox):
"J.P." <jp <at> neverwas.me> writes:
> v2. Fix faulty interaction with `erc-inhibit-multiline-input'. Move
> slash-command detection to input-review hook.
I've installed an updated version of this as
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=a3c6ed0e
Closing for now, though I do anticipate some (hopefully light) followup
work in this area. Thanks.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Tue, 31 Oct 2023 11:24:07 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 04:06:01 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#66073
; Package
emacs
.
(Thu, 07 Dec 2023 07:26:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 66073 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Changes from this bug attempted to fix a number of historical behavioral
quirks related to intercepting and validating prompt input preflight.
One thing they glossed over was not dealing with the confusing "No
process running" warning issued when a user submits input in an orphaned
target buffer. This unfortunate behavior has been with ERC for ages and
might well be cemented into the wider user "ecosystem" such that fixing
it interferes with things like a `condition-case' handler matching
against the exact wording, etc. However, given the annoying nature of
this style of input feedback, I think it makes sense to bite the bullet
here and just chance a minimally churn-inducing change. See attached.
[0008-5.6-Clarify-warning-for-process-dependent-input-in-E.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:10 GMT)
Full text and
rfc822 format available.
This bug report was last modified 1 year and 125 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.