From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: [elpa] externals/org ee0961ba31: lisp/org-table.el: fix warning about `eq' usage Date: Wed, 01 Nov 2023 01:07:50 -0500 Message-ID: <87pm0u9fbd.fsf@red-bean.com> References: <169879312007.20093.7465071871654518215@vcs2.savannah.gnu.org> <20231031225840.6A0FEC06553@vcs2.savannah.gnu.org> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39716"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Stefan Monnier To: Emacs Devel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Nov 01 07:08:54 2023 Return-path: Envelope-to: ged-emacs-devel@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 1qy4PM-000A3u-45 for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Nov 2023 07:08:52 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qy4OT-0003jQ-Bm; Wed, 01 Nov 2023 02:07:57 -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 1qy4OR-0003hV-1V for emacs-devel@gnu.org; Wed, 01 Nov 2023 02:07:55 -0400 Original-Received: from sanpietro.red-bean.com ([45.79.25.59]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qy4OP-0008HJ-5k for emacs-devel@gnu.org; Wed, 01 Nov 2023 02:07:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID:Date: Reply-To:In-reply-to:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=rPaYbqb7uSvEc9Q2Tmi2uPDYXxJxIpi66DYPS5bJd54=; t=1698818872; x=1700028472; b=f3yKlYeYOiD0wQHLXYW71hld1fufxzutLeKeCtWX6IuW/1lfm3PkYXRqDsGnYFDN+vtg8xvGYD0 nAQTD16jBi6WSKh72aVOwAwStqGx15FoIyvmJ9vK1N85ZSUBItGjniVTXbBhOmNxGgamJDrXEBb9F n1oyZSPN8sd7YoIzyALTuK8fiLp7ep1deMy+bXJvgXGARh7xmOYdd85cHUh7gzp4cf/H+qnI9pmLZ 91Kkb2YRw1GsbN8IUYmVLmnorWQXBO7rkYeWs/tBNBVXgV+4Wa5ESEVsItW3ntvSNWIObI58uGswS yXEGQ1OOxE+zIjXcyyJaIAbLlaYM27dppKyA==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:36890 helo=floss) by sanpietro.red-bean.com with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1qy4ON-00EoUU-87; Wed, 01 Nov 2023 06:07:51 +0000 In-reply-to: Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=sanpietro.red-bean.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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:312040 Archived-At: --=-=-= Content-Type: text/plain; format=flowed Stefan Monnier wrote: >> This change does not affect the behavior of >> `org-table-make-reference' because `eq' treats all instances >> of the empty string as the same object anyway, e.g., >> `(eq (string-trim "aaabbb" "a+" "b+") "")' ==> t. > >Not quite so: (eq (string-to-multibyte "") "") => nil Thank you for noticing this, Stefan. I did many tests with `eq' and various kinds of generated empty strings before writing that commit message -- but, alas, I didn't think of testing with a multibyte string. (I also looked in the documentation, and the fact that there was no explicit mention of all empty strings being the same object should have tipped me off!) So, I believe this means there is an error in that commit message. I've attached the commitinfo below for easy reference, with 'inline' disposition. However, the code change itself remains correct... I think? That is: the previous code presumably had a latent bug, in that there *could* have been times when the `eq' test would fail when comparing against a multibyte empty string. I don't know much about how Org Mode gets merged into Emacs, nor whether there are opportunities for rebasing anywhere along the way in that process. If there's a way to update that commit message, then I'd do so (I can post a new one here). But if there's no such opportunity, then so be it: I'll be on the permanent record with a technical mistake in a log message. I'm sure it wouldn't be the first time :-/. Best regards, -Karl --=-=-= Content-Type: text/plain Content-Disposition: inline; filename=commit-ee0961ba317.txt Content-Description: commit ee0961ba317 commit ee0961ba3170f7bc89c2f6fabda4b6ea2e7a2c88 Author: Karl Fogel AuthorDate: Mon Oct 30 10:33:29 2023 -0500 Commit: Bastien Guerry CommitDate: Tue Oct 31 21:38:23 2023 +0100 lisp/org-table.el: fix warning about `eq' usage * lisp/org-table.el (org-table-make-reference): Use `equal' instead of `eq' to compare strings. This change makes the following warning go away: Warning (comp): org-table.el:2867:23: \ Warning: `eq' called with literal string that may never match (arg 2) This change does not affect the behavior of `org-table-make-reference' because `eq' treats all instances of the empty string as the same object anyway, e.g., `(eq (string-trim "aaabbb" "a+" "b+") "")' ==> t. The only effect of this change is to eliminate the warning. M lisp/org-table.el --=-=-=--