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

Previous Next

Full log

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

From: "J.P." <jp <at> neverwas.me>
To: Emanuel Berg <incal <at> dataswamp.org>
Cc: bug-gnu-emacs <at> gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#58797: 29.0.50; Revise format of stored message tags in ERC
Date: Fri, 28 Oct 2022 06:29:39 -0700

Emanuel Berg <incal <at> dataswamp.org> writes:

> 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 ...

Um, I guess by "type" I meant something more like `:type' in the broader
"describing the shape of some field" sense. Not so much (info "(elisp)
Lisp Data Types") or what have you. Apologies for the confusion.

>> 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 ...

Poor choice of descriptive label on my part, clearly. I didn't mean to
suggest a custom user option but rather something like a
NIL-OR-NONEMPTY-STRING. IOW, whatever might satisfy a `typep' spec of

  '(cons symbol (or null (and string (not (string 0)))))

or similar (bastardized pseudo-CL notwithstanding).

>> 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)

The releases on ELPA are basically snapshots of lisp/erc taken whenever
the ";; Version: " header changes. So, the work you see on HEAD is still
unreleased. It's possible that incrementing the version ahead of time
(like to 5.5-git or something) would make that clearer, but AFAIK we
can't do that without triggering yet another release. Hope that makes
sense.

Previous Next

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