bug#49704: 28.0.50; erc-response object retained in text-props via erc-button

[J.P.]

Lars Ingebrigtsen <larsi@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@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@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).