From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#62693: 28.2; VC: CVS: Fix lost file reporting and enable reverting it Date: Mon, 17 Apr 2023 20:48:27 +0300 Message-ID: <83a5z69z84.fsf@gnu.org> References: <2029306.bkXEbi1Pq8@ravel> <83y1mtcx4g.fsf@gnu.org> <2020915.n1Ql7ez4OO@ravel> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13250"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dmitry@gutov.dev, 62693@debbugs.gnu.org To: Olivier Certner Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 17 19:49:22 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1poSyg-0003Eg-Ew for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 17 Apr 2023 19:49:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1poSyO-00038J-Dt; Mon, 17 Apr 2023 13:49:04 -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 1poSyM-00038A-Vd for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 13:49:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1poSyM-0004p9-Ni for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 13:49:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1poSyM-0005VR-5X for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2023 13:49:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 17 Apr 2023 17:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62693 X-GNU-PR-Package: emacs Original-Received: via spool by 62693-submit@debbugs.gnu.org id=B62693.168175371021112 (code B ref 62693); Mon, 17 Apr 2023 17:49:02 +0000 Original-Received: (at 62693) by debbugs.gnu.org; 17 Apr 2023 17:48:30 +0000 Original-Received: from localhost ([127.0.0.1]:55961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1poSxp-0005UP-LA for submit@debbugs.gnu.org; Mon, 17 Apr 2023 13:48:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1poSxo-0005Tt-Cq for 62693@debbugs.gnu.org; Mon, 17 Apr 2023 13:48:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poSxi-0004e3-84; Mon, 17 Apr 2023 13:48:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=gZHODSen29qG8LldIZSCmqTYB6HbWGUrA3JTCUmkTdk=; b=LE0HuyreGgEn gn/YU3cMt/k2eOav62rfLhpioT91ZHeeWxpnsg8gBTkRZwUbb54+98XDhgiakLhAsLaCqBdt2IIBX /tZE1Peukhsyfcu2Zw9bUjiYRlMyZe46a1LI2O3MG8q9lKDCfoz27khP41+evYdBLXpFlilZXjvtI jTem3pv527NBJRO5wNjZzC29Lq5WAbV7ah2fnPjfQU4wPg+ljulwcgAuO24y6AIqdgEXOXVU6Jr3i aluYlpD8Sv3wEJt62rckZ6p3Mtr2veJ1fKaX+L2KMQpJzM+vQPcK8Jb3vZytFTDh2J5Gldi4IKOVl 9SJ5gU/Cciy2Zwa3Ek9v/w==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1poSxh-00047A-KD; Mon, 17 Apr 2023 13:48:21 -0400 In-Reply-To: <2020915.n1Ql7ez4OO@ravel> (message from Olivier Certner on Mon, 17 Apr 2023 11:24:26 +0200) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:260191 Archived-At: > From: Olivier Certner > Cc: 62693@debbugs.gnu.org > Date: Mon, 17 Apr 2023 11:24:26 +0200 > > > The patch is AFAICS basically a complete rewrite of an important > > function, so I don't see how I could agree applying this to the > > release branch. Sorry. (Was the introduction of so many CL-isms > > really necessary, btw?) > > This paragraph leaves me astonished. > > First, because it is wrong: `vs-cvs-parse-root' is not a major function, it is > a very minor one. I should have said "non-trivial". Sorry for potentially confusing selection of words. > Second, because "Was the introduction of so many CL-isms really necessary, > btw?" is both unproductive and rude, and as such doubly inappropriate. Dmitry asked whether it was okay to install this on the release branch, which is currently undergoing pretest. So I looked at the changes from the POV of the potential for unintended consequences and regressions. This job is much harder when the code is thoroughly rewritten, let alone uses a different macro system and style. That is why I asked the question: I presume that if the changes were less radical, they could perhaps have been deemed appropriate for the release branch, or at least the chances for that were higher. > If > there is a policy of banishing CL forms, then say so, and even better, write > it in the documentation. If there is already one (I'm not aware of any), then > point me to it. You even didn't bother naming the constructs you're > questioning. So let me review all candidates for you. The "so many" (!) CL- > isms are of 3 kinds only: `cl-defun', `cl-labels' and `cl-ecase'. The first is > used to bail out early from the function without complicating code. It is much > more appropriate from a language point of view than the `throw'/`catch' it > expands to (to readers, and implementors as well if at some point Emacs gains > true lexical non-local exits). The second fills an Emacs Lisp gap (definition > of internal recursive functions), so is necessary (unless you want me to > define these functions with `defun' whereas they are only internal and not > meant to be called standalone, or use `let' with `lambda` forms and > funcalls?). The third is the most concise way to express the intent, even > before `pcase'. Sure, I could use the latter and define a catch-all case with > an internal error, but then I'll have to do that the 4 times `cl-ecase' is > used: 4 additional lines with no added value. Does using `cl-ecase' really > change the face of Emacs world? > > To be frank, I'm quite worried that I have to explain all that to an Emacs > maintainer. You didn't have to. That's not why I asked the question. > I find "file name" or "directory name" even worse because they are ambiguous. > So I've settled on using "pathname" instead (the (UNIX/Windows) "path" to some > file, not just the filename (i.e., no slashes)). Is that OK for you? Not really, but that's a minor point. We can always fix the terminology later. Thanks.