emacs-erc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior


From: J.P.
Subject: bug#62833: 30.0.50; ERC 5.6: Rethink buffer-display options and behavior
Date: Fri, 14 Apr 2023 06:56:16 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

Tags: patch

Hi,

I'm hoping this can serve as a unified "omnibug" for all the overlapping
discourse scattered about regarding buffer-display options and the
behavior they produce. The main focus will be those aspects impacting
ERC 5.6 and how they integrate with the upstream display-buffer facility
provided by window.el. In a sense, this is a spiritual successor to

  bug#51753: ERC switches to channel buffer on reconnect

and will inherit the outstanding display-related portions of

  bug#60428: 30.0.50; ERC >5.5: Make M-x erc a more welcoming entry point

the most recent being this proposal:

> This bug's original patch set tried to walk back an austere aspect of
> bug#51753's changes that lumped interactive buffer creation in with
> protocol driven creation. It mainly did so by introducing a new option,
> `erc-interactive-display', that reinstated direct window-buffer
> replacement when running M-x erc. However, as pointed out by Corwin on
> Libera, this did not account for interactive /JOINs.
>
> The attached patch aims to address this oversight as well as simplify
> the display-options picture a bit further by consolidating the roles of
> `erc-interactive-display' and `erc-query-display'. The thinking is that
> both options cover the same basic ground involving buffers created as a
> consequence of issuing slash commands. This patch also adds an interface
> for other such commands to use for detecting when they're being called
> from the command line.

Despite this, I'm still rather unsure about merging our ancient display
options. Aliasing `erc-interactive-display' to `erc-query-display' seems
sane because the latter only appears once, in an interactive command. A
more daring and arguably more meaningful move would be to repurpose
`erc-auto-query' (newly aliased to `erc-receive-query-display') as
something like a more general `erc-receive-display', which could cover
display handling for anything protocol driven (i.e., "non-interactive").
Among the reasons to abstain might be

  1. it would necessarily involve redefining the meaning of the option's
     nil value to mean "fall back to erc-join-buffer" instead of "print
     to the server buffer instead," which has no available alternative

  2. it invites an initial security risk (reminiscent of bug#51753)
     or at least a service interruption

For the first point, redefining the nil value is probably justified in
theory because all other values only concern themselves with where a
buffer is displayed, not where messages are routed for printing or
whether buffers are even created, which is the province of dedicated
switches (see note below re `erc-query-on-unjoined-chan-privmsg'). So I
guess this really comes down to whether providing an alternative
companion option and noting it in the doc string is an acceptable trade
off. Point two is more challenging but could perhaps be addressed by a
one-off warning requiring a click-through, before which
`erc-join-buffer' (now `erc-buffer-display') would remain in effect.

There's also the matter of assigning Custom groups for these options.
It'd be "nice" if we could tag these with multiple groups rather than
confine them to exclusive ownership. They're currently spread over
`erc-buffers', `erc-query', and `erc-display'. All seem to have valid
claims when you consider their respective constituencies.

It's also been casually suggested that we might consider deferring to
`erc-setup-buffer' in areas not directly involved in message handling,
such as in erc-sidebar, to allow the options in question to influence
how buffers are displayed more generally. Not sure I have an opinion on
this quite yet, but if anyone else does, please share.

Lastly, I've tacked on another patch that's somewhat related in the
buffer-creation (but not so much -display) sense. It concerns the
restoration of the option `erc-query-on-unjoined-chan-privmsg', which
was orphaned in 5.5 (by me) both out of ignorance and an abundance of
caution.

Thanks.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.35, cairo version 1.17.6) of 2023-04-12 built on localhost
Repository revision: 861cf3a5c9d2081d811dcfc2c5ce5357f3dc44d4
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (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
  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 derived 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 auth-source cl-seq
eieio eieio-core cl-macs password-cache json subr-x map format-spec
cl-loaddefs cl-lib erc-backend erc-networks byte-opt gv bytecomp
byte-compile erc-common erc-compat 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 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
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 63110 9012)
 (symbols 48 8532 0)
 (strings 32 23158 1921)
 (string-bytes 1 669049)
 (vectors 16 14968)
 (vector-slots 8 206726 6655)
 (floats 8 24 39)
 (intervals 56 231 0)
 (buffers 976 10))

Attachment: 0000-v1-v2.diff
Description: Text Data

Attachment: 0001-5.6-Revive-option-erc-query-on-unjoined-chan-privmsg.patch
Description: Text Data

Attachment: 0002-5.6-Extend-erc-interactive-display-to-cover-JOINs.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]