bug#58797: 29.0.50; Revise format of stored message tags in ERC

[J.P.]

Emanuel Berg <incal@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.