GNU bug report logs - #54536
29.0.50; Improve ERC's handling of multiline prompt input

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 54536 in the body.
You can then email your comments to 54536 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
Cc: emacs-erc <at> gnu.org
Subject: 29.0.50; Improve ERC's handling of multiline prompt input
Date: Wed, 23 Mar 2022 06:26:44 -0700

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

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 (text/x-patch, attachment)]

[0002-Improve-ERC-s-handling-of-multiline-prompt-input.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Wed, 23 Mar 2022 14:50:13 +0100

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

> 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.

Makes sense to me.

> 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.

Dropping trailing blank lines is a good thing, I think.

> 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.

Sounds good.

> 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.

Ditto.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Thu, 24 Mar 2022 12:50:57 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> 1. What should happen when a user submits multiline input containing
>>    empty lines? [...] This patch says [...]
>
> Makes sense to me.
>
>> 2. Should trailing blank lines be treated differently? [...]
>>
> Dropping trailing blank lines is a good thing, I think.
>
>> 3. When `erc-send-whitespace-lines' is non-nil, should it [...]
>>    This patch says no to the first and yes to the second.
>
> Sounds good.

Appreciate the feedback!

I'd like to get #48598 ("buffer-naming collisions involving bouncers in
ERC") up to snuff relatively soon. Would it make sense to petition
emacs-devel for eyeballs at some point? Also, is there any way to try
out some patches on EMBA CI? I have a feeling some of my tests that work
locally and on GitLab.com's GCP runners may have to be tuned a bit for
EMBA. (Or would these questions be better put to the build-automation
folks?) Thanks.

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

From: Michael Albinus <michael.albinus <at> gmx.de>
To: "J.P." <jp <at> neverwas.me>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Thu, 24 Mar 2022 21:16:12 +0100

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

Hi,

> I'd like to get #48598 ("buffer-naming collisions involving bouncers in
> ERC") up to snuff relatively soon. Would it make sense to petition
> emacs-devel for eyeballs at some point? Also, is there any way to try
> out some patches on EMBA CI? I have a feeling some of my tests that work
> locally and on GitLab.com's GCP runners may have to be tuned a bit for
> EMBA. (Or would these questions be better put to the build-automation
> folks?) Thanks.

On EMBA, also git branches run the CI tests. See file test/infra/gitlab-ci.yml:

--8<---------------cut here---------------start------------->8---
    - if: '$CI_COMMIT_BRANCH !~ /^(master|emacs|feature|fix)/'
      when: never
--8<---------------cut here---------------end--------------->8---

So your branch name must start with one of these words.

Best regards, Michael.

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

From: "J.P." <jp <at> neverwas.me>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Thu, 24 Mar 2022 16:38:52 -0700

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

> So your branch name must start with one of these words.

Thanks a lot for the explanation. Among those prefixes, "fix" seems the
least misleading for my purposes, those being (1) rapid iteration toward
a passing pipeline and (2) minimal distraction for others. Hopefully,
there's already precedent for more ephemeral, fly-by-night "fix/*"
branches. If so, and there's a prescribed naming scheme to that end
(something like "fix/bug-48598-temp" or similar), perusing the remote
refs hasn't revealed it. Regardless, I'll wait for a go-ahead before
trying anything.

Thanks again,
J.P.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 54536 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 25 Mar 2022 16:29:46 +0100

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

> Thanks a lot for the explanation. Among those prefixes, "fix" seems the
> least misleading for my purposes, those being (1) rapid iteration toward
> a passing pipeline and (2) minimal distraction for others. Hopefully,
> there's already precedent for more ephemeral, fly-by-night "fix/*"
> branches. If so, and there's a prescribed naming scheme to that end
> (something like "fix/bug-48598-temp" or similar), perusing the remote
> refs hasn't revealed it. Regardless, I'll wait for a go-ahead before
> trying anything.

Calling the branch fix/whatever is fine.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 25 Mar 2022 16:31:25 +0100

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

> I'd like to get #48598 ("buffer-naming collisions involving bouncers in
> ERC") up to snuff relatively soon. Would it make sense to petition
> emacs-devel for eyeballs at some point? 

Sure, if you want to.  I had a brief peek myself, but the patch series
was so long that I didn't really have anything to say.  :-/

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 25 Mar 2022 12:20:41 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> I'd like to get #48598 ("buffer-naming collisions involving bouncers in
>> ERC") up to snuff relatively soon. Would it make sense to petition
>> emacs-devel for eyeballs at some point? 
>
> Sure, if you want to.  I had a brief peek myself, but the patch series
> was so long that I didn't really have anything to say.  :-/

Thanks for the peek. Your impression is more than fair. I think for now
I'll try soliciting specific questions, perhaps via top-level replies to
that bug but with subject headers changed to reflect whatever's being
posed (while also Cc-ing various persons where appropriate). And in
cases where a question may have broader relevance, I'll hit up
help-gnu-emacs first/instead.

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

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54536 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 25 Mar 2022 12:23:10 -0700

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Calling the branch fix/whatever is fine.

Thanks.

BTW, I think these can go:

  refs/heads/features/erc-message-tags
  refs/heads/fix/bug-34657-erc-hooks

Is it customary to contact the authors before deleting?

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 54536 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Michael Albinus <michael.albinus <at> gmx.de>
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Sat, 26 Mar 2022 17:44:37 +0100

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

> BTW, I think these can go:
>
>   refs/heads/features/erc-message-tags
>   refs/heads/fix/bug-34657-erc-hooks
>
> Is it customary to contact the authors before deleting?

If the branches have been merged (or their contents have been applied to
the trunk otherwise), it's OK to delete them.  If not, it's better to
contact the authors first.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: "J.P." <jp <at> neverwas.me>
To: Matheus Fillipe <matheusfillipeag <at> gmail.com>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Sun, 03 Apr 2022 12:44:39 -0700

Matheus Fillipe <matheusfillipeag <at> gmail.com> writes:

> I've been testing this and as an evil-mode user I had a problem that
> whenever I paste something or sometimes just out of the blue I would
> send one empty line after my message. After a few hours using erc this
> it only happened once but Im not able to reproduce it so... I think
> this is a great addition and it solves my problem!

Appreciate the feedback! (Although, we ought not settle for "it
only happened once," if we can help it.) A few silly questions:

1. In your testing, what was the value of `erc-send-whitespace-lines'?

2. Do you have any unusual bindings or minor modes going (other than
   Evil)? Just asking to try and gauge whether it's worth doing
   something like an emacs -Q.

3. How do you send input normally? For example: switch to insert state,
   type stuff after the prompt, hit RET. Just asking in case I try
   recreating your setup.

4. Are you willing to keep testing it? If so and it happens again, can
   you try a `view-lossage' and maybe also a `report-emacs-bug', and
   just copy-paste all the generated facts into a reply?

BTW, I guess the "reply" button on the MHonArc-generated bug-gnu-emacs
pages doesn't do a "reply all" (or else there's some trick I don't know
about to get it to include Cc participants).

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

From: Matheus Fillipe <matheusfillipeag <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>
Cc: "emacs-erc <at> gnu.org" <emacs-erc <at> gnu.org>,
 "54536 <at> debbugs.gnu.org" <54536 <at> debbugs.gnu.org>
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline
 prompt input
Date: Sun, 3 Apr 2022 17:15:21 -0300

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

So far the patches seem to have fixed the issue I long had sending empty lines randomly.

Here are my replies to your questions.
1) erc-send-whitespace-lines was set to nil
2) Hmm no I don't have nothing quite unusual on erc that i can think of now. I have erc-nl-nicks.
3) Yes exactly nothing unusual about that.
4) I will since it seems to have "fixed" the issue so far. I will keep that in mind in case it happens again.

That one case was the only until now. Didn't happen again and I've tried to reproduce but would never happen, so I'm not sure if it really matters. I will keep testing.
On Apr 3 2022, at 4:44 pm, J.P. <jp <at> neverwas.me> wrote:
> Matheus Fillipe <matheusfillipeag <at> gmail.com> writes:
>
> > I've been testing this and as an evil-mode user I had a problem that
> > whenever I paste something or sometimes just out of the blue I would
> > send one empty line after my message. After a few hours using erc this
> > it only happened once but Im not able to reproduce it so... I think
> > this is a great addition and it solves my problem!
>
> Appreciate the feedback! (Although, we ought not settle for "it
> only happened once," if we can help it.) A few silly questions:
>
> 1. In your testing, what was the value of `erc-send-whitespace-lines'?
> 2. Do you have any unusual bindings or minor modes going (other than
> Evil)? Just asking to try and gauge whether it's worth doing
> something like an emacs -Q.
>
> 3. How do you send input normally? For example: switch to insert state,
> type stuff after the prompt, hit RET. Just asking in case I try
> recreating your setup.
>
> 4. Are you willing to keep testing it? If so and it happens again, can
> you try a `view-lossage' and maybe also a `report-emacs-bug', and
> just copy-paste all the generated facts into a reply?
>
> BTW, I guess the "reply" button on the MHonArc-generated bug-gnu-emacs
> pages doesn't do a "reply all" (or else there's some trick I don't know
> about to get it to include Cc participants).
>

[Message part 2 (text/html, inline)]

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

From: "J.P." <jp <at> neverwas.me>
To: 54536 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 22 Apr 2022 20:17:58 -0700

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

v3. Except for a subtle change involving compatibility, there aren't any
real differences in behavior.

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

> 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.

This description is rather sloppy and ambiguous, so I have attempted to
clarify things below (underscores are spaces). The subtle compat change
happens between the first two examples. Basically, when the option
`erc-send-whitespace-lines' is active and trailing blank lines are
present, the new (v3) iteration of this patch no longer interprets slash
commands but instead just sends lines as text. This more closely mirrors
traditional ERC behavior.

(I suppose we could also have an option to go the other, v2 route, if
people want.)


Patch v2 (previous)
~~~~~~~~~~~~~~~~~~~

- `erc-send-whitespace-lines' ON
- All trailing blanks stripped
- Command interpreted
- Nothing inserted (unless echo-message cap negotiated, coming in #49860)

  input:
    . ERC> /msg #chan hi
    .
    . [RET]

  I/O:
    -> PRIVMSG #chan :hi

  shown:
    (nothing)


Patch v3 (this)
~~~~~~~~~~~~~~~
- `erc-send-whitespace-lines' ON
- Trailing blanks stripped
- Command not interpreted

  input:
    . ERC> /msg #chan hi
    .
    . [RET]

  I/O:
    -> PRIVMSG #chan :/msg #chan hi

  shown:
    <me> /msg #chan hi


The rest are just included for good measure, but none has changed:


HEAD
~~~~

- `erc-send-whitespace-lines' ON or OFF
- Trailing blanks not stripped or padded
- Command not interpreted
- Protocol violation (my fault from #50008, not in 5.4.1 or 28)

  input:
    . ERC> /msg #chan hi
    . [RET]

  I/O:
    -> PRIVMSG #chan :/msg #chan hi
    -> PRIVMSG #chan :
    <- :irc.foonet.org 412 me :No text to send

  shown:
    . <me> /msg #chan hi
    . <me>
    . *** No text to send


Patch v2 and v3
~~~~~~~~~~~~~~~

- `erc-send-whitespace-lines' OFF
- ding, input remains, echo area says "Blank line - ignoring ..."

  input:
    . ERC> /msg #chan hi
    . _* [RET]

  I/O:
    (nothing)

  shown:
    (nothing)


All (HEAD, v2, v3)
~~~~~~~~~~~~~~~~~~

- `erc-send-whitespace-lines' ON (or OFF when old)
- Command not interpreted
- User-padded trailing blank preserved

  input:
    . ERC > /msg #chan hi
    . _ [RET]

  I/O:
    -> PRIVMSG #chan :/msg #chan hi
    -> PRIVMSG #chan :_

  shown:
    <me> /msg #chan hi
    <me>

- `erc-send-whitespace-lines' ON (or OFF when old)
- Command not interpreted
- Intervening blank padded

  input:
    . ERC> /msg #chan hi
    .
    . again [RET]

  I/O:
    -> PRIVMSG #chan :/msg #chan hi
    -> PRIVMSG #chan :_
    -> PRIVMSG #chan :again

  shown:
    <me> /msg #chan hi
    <me>
    <me> again

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

[0001-Fix-regression-in-erc-send-input-line.patch (text/x-patch, attachment)]

[0002-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]

[0003-Improve-ERC-s-handling-of-multiline-prompt-input.patch (text/x-patch, attachment)]

[0004-SQUASH-ME-Add-hook-for-splitting-multiline-input-in-.patch (text/x-patch, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: 54536 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Fri, 29 Apr 2022 06:05:26 -0700

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

v4.

I've decided it's probably better to abstain from exporting the input
validation hooks or their members without good reason. Likewise for the
hook involving split-lines and command-detection. So they've all been
renamed as internal, for now.

This version also brings with it some out-of-scope feature creep in
response to recent clamoring for a way to prevent all multiline input.
I've therefore added two options and wired them into the pre-send
validation mechanism introduced earlier in this series. The first is
called `erc-inhibit-multiline-input', which must be either a positive
integer or t. As an int, it indicates the maximum number of lines
allowed to be submitted for sending (above which a beep and a scolding
result). The second is called `erc-ask-about-multiline-input'. When
non-nil, instead of getting scolded, the user is asked whether to go
ahead and send anyway (just this once).

A few (arguably surprising) idiosyncrasies surround the interaction
between `erc-send-whitespace-lines' and these newly proposed options,
but nothing too radical or inconsistent (IMO). For example, during the
reckoning of `erc-inhibit-multiline-input', trailing blanks are always
trimmed, but when `erc-send-whitespace-lines' is nil, this becomes
irrelevant because the send is preempted beforehand, which is in line
with the behavior described in the initial bug report.

[0000-v3-v4.diff (text/x-patch, attachment)]

[0001-Fix-regression-in-erc-send-input-line.patch (text/x-patch, attachment)]

[0002-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]

[0003-Improve-ERC-s-handling-of-multiline-prompt-input.patch (text/x-patch, attachment)]

[0004-Optionally-prevent-sending-multiline-input-in-ERC.patch (text/x-patch, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: 54536 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Tue, 17 May 2022 06:10:05 -0700

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

v5. Fix compiler error and other minor issues.

[0000-v4-v5.diff (text/x-patch, attachment)]

[0001-Fix-regression-in-erc-send-input-line.patch (text/x-patch, attachment)]

[0002-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]

[0003-Improve-ERC-s-handling-of-multiline-prompt-input.patch (text/x-patch, attachment)]

[0004-Optionally-prevent-sending-multiline-input-in-ERC.patch (text/x-patch, attachment)]

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

From: "J.P." <jp <at> neverwas.me>
To: Will Mengarini <seldon <at> eskimo.com>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Tue, 17 May 2022 18:34:10 -0700

Will Mengarini <seldon <at> eskimo.com> writes:

> "It you need this" should be "If you need this".

Whoops! Thanks.

--
"It you build it, they will come."

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

From: Will Mengarini <seldon <at> eskimo.com>
To: "J.P." <jp <at> neverwas.me>
Cc: emacs-erc <at> gnu.org, 54536 <at> debbugs.gnu.org
Subject: Re: bug#54536: 29.0.50; Improve ERC's handling of multiline prompt
 input
Date: Tue, 17 May 2022 15:48:52 -0700

"It you need this" should be "If you need this".

Previous Next

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