From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "J.P." Newsgroups: gmane.emacs.erc.general,gmane.emacs.bugs Subject: Re: bug#58797: 29.0.50; Revise format of stored message tags in ERC Date: Fri, 28 Oct 2022 06:29:39 -0700 Message-ID: <87k04knkjg.fsf@neverwas.me> References: <87fsfa4t7j.fsf@neverwas.me> <87fsf9r9nb.fsf@dataswamp.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31312"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux) Cc: bug-gnu-emacs@gnu.org, emacs-erc@gnu.org To: Emanuel Berg Original-X-From: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Fri Oct 28 15:30:39 2022 Return-path: Envelope-to: sf-erc-help@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1ooPRV-0007ro-04 for sf-erc-help@m.gmane-mx.org; Fri, 28 Oct 2022 15:30:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ooPRT-0001az-4l; Fri, 28 Oct 2022 09:30:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ooPR6-0001El-Cz for emacs-erc@gnu.org; Fri, 28 Oct 2022 09:30:20 -0400 Original-Received: from mail-108-mta2.mxroute.com ([136.175.108.2]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ooPR2-0006NC-Lk for emacs-erc@gnu.org; Fri, 28 Oct 2022 09:30:11 -0400 Original-Received: from mail-111-mta2.mxroute.com ([136.175.111.2] filter006.mxroute.com) (Authenticated sender: mN4UYu2MZsgR) by mail-108-mta2.mxroute.com (ZoneMTA) with ESMTPSA id 1841ec90e990006e99.003 for (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256); Fri, 28 Oct 2022 13:30:03 +0000 X-Zone-Loop: 0f2670f01abbf925d0205c188d3b4c2258326ef47cbb X-Originating-IP: [136.175.111.2] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me ; s=x; h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To: Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=PMqV0ZxPtKVoJgRzTBf6Qdyq9Yg3kM34brsAJC8F950=; b=jXb3cmjdeYbEtDq7ivkfMeXtaB ResVZz+FkkO2rDkQ0BJ60mT3EFzO2eEGuFJdsrAGcY2Lmag4d2LFaSV0pt79CYC+dnz23MlD5RhmU CfaHReQ3eMw9T1kzIYnJjDa/hgHWDU7/oAWlQ+Os20EOb1NlCTXr+ix/UDyBzuipxjYbimGkdw5US KqGzC1L26YVtsKkcPssmEFMO6YlaFgkgPgnN5kjAkxLia+oxddyr0hGaRIbtjBgn/+YJ3vN5T9CuM gVr6zyuuVscBP+9IoDM7OPfoN17nnbJzwv/DNR3vZEL1E9+k47Mr7im61QMJCb8rB8mINYjwxX2np FFuhD3Pg==; In-Reply-To: <87fsf9r9nb.fsf@dataswamp.org> (Emanuel Berg's message of "Thu, 27 Oct 2022 09:46:48 +0200") X-Authenticated-Id: masked@neverwas.me Received-SPF: pass client-ip=136.175.108.2; envelope-from=jp@neverwas.me; helo=mail-108-mta2.mxroute.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-erc@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General discussion about ERC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "emacs-erc" Errors-To: emacs-erc-bounces+sf-erc-help=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.erc.general:1935 gmane.emacs.bugs:246428 Archived-At: Emanuel Berg 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.