GNU bug report logs - #49704
28.0.50; erc-response object retained in text-props via erc-button

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 49704 in the body.
You can then email your comments to 49704 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
Subject: 28.0.50; erc-response object retained in text-props via erc-button
Date: Fri, 23 Jul 2021 00:45:12 -0700

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

Severity: minor
Tags: patch

Hi, I encountered this while messing with:

  bug#49690: 28.0.50; ERC makes a button of `let' but not `let*'

Whenever text from a received message is inserted into an ERC buffer,
the function `erc-display-line-1' runs four hooks. Two of these,
`erc-insert-modify-hook' and `erc-insert-post-hook' (basically
identical), run with the buffer narrowed to the region surrounding the
newly inserted message. This message features a text property called
`erc-parsed', whose value is the original `erc-response' object used to
represent that message as structured data during processing. Afterwards,
`erc-display-line-1' removes `erc-parsed'.

Question: shouldn't the hook functions being run here take care not to
retain references to these objects unless actually needed? Specifically,
`erc-button-add-buttons-1', which runs on `erc-insert-modify-hook' (via
`erc-button-add-buttons'), saves portions of the text matching non-nick
patterns in a text property called `erc-data'. These are arguments to be
applied to a function stored in another text property, `erc-callback',
which runs on mouse click or RET.

It's obviously too late to change the interface for these hooks (for
example, by adding a new "response object" param). But that doesn't mean
we can't insist that hook functions at least make their intentions
toward these response objects known rather than just stash them away in
case some downstream facility (e.g., third-party code) might need them
(which may have been the motivation here if this stashing was indeed
intentional).

For now, unless I'm way off the mark (wouldn't be the first time), I
propose dropping all properties of all strings stored in `erc-data'.

Of the functions called with `erc-data':

  - erc-browse-emacswiki
  - erc-browse-emacswiki-lisp
  - erc-button-search-url
  - erc-button-rfc-url
  - erc-button-describe-symbol
  - Info-goto-node
  - browse-url
  - browse-url-button-open-url

none, AFAICT, actually uses 'erc-parsed' (or any property, for that matter).

Obviously, this issue is small potatoes relative to ERC's other problems,
so it can probably be put off indefinitely. Thanks.

P.S. See also: `erc-hide-current-message-p'


In GNU Emacs 28.0.50 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-07-20 built on localhost
Repository revision: 1b251ed4e8550c889d17fe7d88f58aa2fbc95fe0
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
 --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
 --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
 --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
 --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-O0 -g3'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS 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
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv 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 electric uniquify ediff-hook vc-hooks
lisp-float-type 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 elisp-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 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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal 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 51359 6165)
 (symbols 48 6620 1)
 (strings 32 18257 1521)
 (string-bytes 1 615936)
 (vectors 16 13438)
 (vector-slots 8 179083 10089)
 (floats 8 21 47)
 (intervals 56 260 0)
 (buffers 992 10))

[0001-Remove-text-props-from-callback-args-in-erc-button.patch (text/x-patch, attachment)]

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 49704 <at> debbugs.gnu.org
Subject: Re: bug#49704: 28.0.50; erc-response object retained in text-props
 via erc-button
Date: Fri, 23 Jul 2021 13:46:58 +0200

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

> Question: shouldn't the hook functions being run here take care not to
> retain references to these objects unless actually needed?

I'm not quite sure I understand what problem the current text properties
lead to?  Is it saving memory-hungry closures in the text properties or
something?

I had a look at the data in some buttons in an erc buffer, and nothing
there really seems excessive?

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

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

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 49704 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#49704: 28.0.50; erc-response object retained in text-props
 via erc-button
Date: Fri, 23 Jul 2021 06:14:20 -0700

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

> I'm not quite sure I understand what problem the current text properties
> lead to?  Is it saving memory-hungry closures in the text properties or
> something?

No, no closures, just strings containing the raw message and the various
message parts. So on average, not a huge deal, I guess, even for
channels with lots of links (for example, from a GitHub bot yapping
about every commit)?

> I had a look at the data in some buttons in an erc buffer, and nothing
> there really seems excessive?

Here's a recent example from #emacs.

Original message:

  <Redacted> alice: check out the example in this page:
  https://www.gnu.org/software/groff/manual/html_node/Line-Layout.html#Line-Layout

`erc-data' prop (edited):

  (#("https://www.gnu.org/software/groff/manual/html_node/Line-Layout.html#Line-Layout" 0 80
     (tags
      ((batch . "767fece2e664ff56f97eb768f7ddb5c7")
       (time . "2021-07-21T09:04:51.884Z"))
      rear-sticky t erc-parsed
      #s(erc-response
         "@batch=767fece2e664ff56f97eb768f7ddb5c7;time=2021-07-21T09:04:51.884Z "
         ":Redacted!viking <at> 124.197.53.238 PRIVMSG #emacs :alice: check out the "
         "example in this page: https://www.gnu.org/software/groff/manual/html_"
         "node/Line-Layout.html#Line-Layout" "Redacted!viking <at> 124.197.53.238" "PRIVMSG"
         ("#emacs" "alice: check out the example in this page: https://www.gnu.org"
          "/software/groff/manual/html_node/Line-Layout.html#Line-Layout")
         "alice: check out the example in this page: https://www.gnu.org/software"
         "/groff/manual/html_node/Line-Layout.html#Line-Layout"
         ((batch . "767fece2e664ff56f97eb768f7ddb5c7")
          (time . "2021-07-21T09:04:51.884Z")))
      font-lock-face erc-default-face)))

So just the message text in a different form. If these aren't worth the
bean counting, that's good news. ERC will need to store increasingly
more data for *all* messages as it adapts to the evolving standard. It
already relies on text properties in part to do that, so it's good to
know that'll continue to be an option.

I suppose I got all worked up over nothing then. As usual, many thanks
and many more apologies. I leave you in peace (for now).

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 49704 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#49704: 28.0.50; erc-response object retained in text-props
 via erc-button
Date: Fri, 23 Jul 2021 15:16:45 +0200

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

> No, no closures, just strings containing the raw message and the various
> message parts.

Oh, OK, I thought I was misunderstanding something.  I think your
patch is the right thing here, though -- I don't think any usages of the
the stashed data uses the text properties, and it'll make Emacs use less
memory, so I've now applied it to the trunk.

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

Previous Next

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