GNU bug report logs - #54826
29.0.50; Prevent duplicate prompts when reconnecting in ERC

Previous Next

Package: emacs;

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

Date: Sat, 9 Apr 2022 20:30:02 UTC

Severity: minor

Tags: patch

Found in version 29.0.50

Fixed in version 29.1

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 54826 in the body.
You can then email your comments to 54826 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#54826; Package emacs. (Sat, 09 Apr 2022 20:30: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. (Sat, 09 Apr 2022 20:30: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: 29.0.50; Prevent duplicate prompts when reconnecting in ERC
Date: Sat, 09 Apr 2022 13:29:23 -0700
[Message part 1 (text/plain, inline)]
Tags: patch

Currently, when a user disconnects from an IRC session, the input prompt
in the server buffer vanishes. That probably wouldn't matter if the
primary means of reconnecting didn't involve needing that very prompt.
That is, the recommended way to reconnect is indeed to issue a
/reconnect "slash-command" in the input area (the newly nondescript
region preceding EOB). IMO, this degrades the overall user experience
because a user needs prior knowledge (or must magically intuit) that the
input area is in fact still viable and responsive.

But that's not all. As soon as that command is issued (normally via
RET), a second prompt appears before connection activities commence.
Depending on a user's setup and the endpoint they're connecting to, a
few things can happen. But most often, server messages start appearing
between the two prompts.

The proposed patch leverages a long abandoned option called
`erc-hide-prompt' to help address both these concerns. Revived and
repurposed, it now holds an indicator of the desired prompt behavior
upon disconnecting. By default, it merely "hides" the prompt by
replacing it with a user-configurable string (currently ">" by default).
This happens in all buffers owned by the connection, including target
buffers. When the value is 'server' or 'target', only those buffer types
are affected. When the value is nil, prompts are never hidden. Hidden
prompts can be revealed by typing in the input area. However, once
revealed, a prompt won't be rehidden (until the next disconnection).

Questions:

1. Currently, channels and queries are lumped together as 'target'. What
   about changing the shape of the option to a set of {'server',
   'channel', 'query'} in a union with t for "all of the above" (to
   preserve compatibility)?

2. Currently, when the value of `erc-hide-prompt' is 'target' or t,
   prompts in channels are automatically revealed upon reconnecting, but
   in queries, they aren't. This adheres faithfully to the protocol and
   accurately reflects the internal state of the model. Broadly
   speaking, a client can't reliably tell whether a party they're
   corresponding with in a query is still available (unless they share a
   channel).

   Is overloading the "prompt hidden" indicator with multiple meanings
   too distracting? (Currently, it means both "disconnected" and
   "physically connected but possibly not resumable".) Should we instead
   just reveal the prompt for all queries upon reconnecting, even though
   it may not be possible to continue certain conversations? Would it be
   worth accommodating both behaviors via yet another knob (or perhaps
   different 'query' variants, when going with 1, above)?

2. Right now, the prompt looks like this when hidden:

   n-1 | *** ERC finished ***                                   [04:30]
   n   | >_

   Where _ is the cursor at point max. Should we leave a space after the
   ">"?

This particular patch may benefit from integration trials with popular
external ERC modules as well as exotic values for various built-in
options. Any takers, please be aware that ERC famously has trouble
reassociating buffers upon reconnecting; if that's likely to interfere
with your testing, please consider trying #48598 (which currently
contains this patch). Volunteers (and detractors) welcome. Thanks.


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-04-05 built on localhost
Repository revision: e2fb5ecaea67497224455fdbfe4850a5a74c9d00
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 oclosure 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 43818 5691)
 (symbols 48 5713 1)
 (strings 32 15808 1645)
 (string-bytes 1 527821)
 (vectors 16 12098)
 (vector-slots 8 168912 12189)
 (floats 8 20 34)
 (intervals 56 221 0)
 (buffers 992 10))
[0001-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]
[0002-SQUASH-ME-Remove-duplicate-ERC-prompt-on-reconnect.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54826; Package emacs. (Sun, 10 Apr 2022 12:37:02 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 54826 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#54826: 29.0.50; Prevent duplicate prompts when reconnecting
 in ERC
Date: Sun, 10 Apr 2022 14:36:31 +0200
"J.P." <jp <at> neverwas.me> writes:

> The proposed patch leverages a long abandoned option called
> `erc-hide-prompt' to help address both these concerns.

Makes sense to me.

> 1. Currently, channels and queries are lumped together as 'target'. What
>    about changing the shape of the option to a set of {'server',
>    'channel', 'query'} in a union with t for "all of the above" (to
>    preserve compatibility)?

Sure.

>    Is overloading the "prompt hidden" indicator with multiple meanings
>    too distracting? (Currently, it means both "disconnected" and
>    "physically connected but possibly not resumable".) Should we instead
>    just reveal the prompt for all queries upon reconnecting, even though
>    it may not be possible to continue certain conversations? Would it be
>    worth accommodating both behaviors via yet another knob (or perhaps
>    different 'query' variants, when going with 1, above)?

I think a new knob would be probably be preferable.

> 2. Right now, the prompt looks like this when hidden:
>
>    n-1 | *** ERC finished ***                                   [04:30]
>    n   | >_
>
>    Where _ is the cursor at point max. Should we leave a space after the
>    ">"?

I think having a space there would be good.

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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#54826; Package emacs. (Fri, 29 Apr 2022 13:09:02 GMT) Full text and rfc822 format available.

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

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 54826 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#54826: 29.0.50; Prevent duplicate prompts when reconnecting
 in ERC
Date: Fri, 29 Apr 2022 06:08:33 -0700
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> The proposed patch leverages a long abandoned option called
>> `erc-hide-prompt' to help address both these concerns.
>
> Makes sense to me.
>
>> 1. Currently, channels and queries are lumped together as 'target'. What
>>    about changing the shape of the option to a set of {'server',
>>    'channel', 'query'} in a union with t for "all of the above" (to
>>    preserve compatibility)?
>
> Sure.
>
>>    Is overloading the "prompt hidden" indicator with multiple meanings
>>    too distracting? (Currently, it means both "disconnected" and
>>    "physically connected but possibly not resumable".) Should we instead
>>    just reveal the prompt for all queries upon reconnecting, even though
>>    it may not be possible to continue certain conversations? Would it be
>>    worth accommodating both behaviors via yet another knob (or perhaps
>>    different 'query' variants, when going with 1, above)?
>
> I think a new knob would be probably be preferable.
>
>> 2. Right now, the prompt looks like this when hidden:
>>
>>    n-1 | *** ERC finished ***                                   [04:30]
>>    n   | >_
>>
>>    Where _ is the cursor at point max. Should we leave a space after the
>>    ">"?
>
> I think having a space there would be good.

Thanks Lars.

To everyone else out there: since no one has cared to comment, I've
based these changes on Lars's feedback alone.

[0000-v1-v2.diff (text/x-patch, attachment)]
[0001-Add-some-ERC-test-helpers.patch (text/x-patch, attachment)]
[0002-SQUASH-ME-Remove-duplicate-ERC-prompt-on-reconnect.patch (text/x-patch, attachment)]

Severity set to 'minor' from 'normal' Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Sun, 19 Jun 2022 19:05:04 GMT) Full text and rfc822 format available.

bug marked as fixed in version 29.1, send any further explanations to 54826 <at> debbugs.gnu.org and "J.P." <jp <at> neverwas.me> Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Sat, 02 Jul 2022 00:59:01 GMT) Full text and rfc822 format available.

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

This bug report was last modified 1 year and 242 days ago.

Previous Next


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