GNU bug report logs - #58797
29.0.50; Revise format of stored message tags in ERC

Previous Next

Full log

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

From: Emanuel Berg <incal <at> dataswamp.org>
To: bug-gnu-emacs <at> gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#58797: 29.0.50; Revise format of stored message tags in ERC
Date: Thu, 27 Oct 2022 09:46:48 +0200

J.P. wrote:

> Tags: patch
>
> I'm proposing we change the format (type) of the "tags"
> field in the `erc-response'

What is that, it's not a variable and it's not a function ...

> struct from
>
>   (STRING . LIST)
>
> where LIST contains at most one (possibly empty) string, to
>
>   (SYMBOL . OPT-STRING)

Well, as you know, symbol and string are object types in
Emacs, the use of the "OPT" prefix OTOH signals it's a name
and the purpose is to hold options, this mix isn't good IMO.

You can change OPT to OPTS perhaps, SYMBOL I don't know what
to change to since I don't know what symbols are intended to
be stored there ...

Also IMO the dotted list data structure is passé but if code
relies on it I don't suggest changing that just for the sake
of it ...

> For ERC 5.5 and Emacs 29

Okay, but isn't ERC built-in only or can you get "future"
version of ERC from GNU ELPA? Okay, that's it then, I see that
5.4.1 is avaliable there, I'm on

  ERC 5.4.1 (IRC client for GNU Emacs 29.0.50)

But I use, as you see already, a very fresh Emacs, namely

  GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, cairo
  version 1.16.0) of 2022-10-09 [commit
  a2dd9d683a02525183b5e692e42622c65639dda8]

so I guess I'm on the edge here :)

> Why bother?

To improve the software ...

> Isn't this a breaking change?

You can't make an omelet without hatching eggs ...

> Why now? Why not wait?

Do it today, in a different way!

-- 
underground experts united
https://dataswamp.org/~incal

Previous Next

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