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#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Date: Wed, 18 Jan 2023 16:47:08 +0200 Message-ID: <83ilh3293n.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9541"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60929@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jan 18 15:48:40 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 1pI9jz-0002Gn-57 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 15:48:39 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI9jj-0005IX-Q8; Wed, 18 Jan 2023 09:48:23 -0500 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 1pI9jP-0005Ao-EM for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 09:48:03 -0500 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 1pI9jP-0004l8-2D for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 09:48:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pI9jO-0004qk-Hj for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 09:48:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jan 2023 14:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs Original-Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167405322618567 (code B ref 60929); Wed, 18 Jan 2023 14:48:02 +0000 Original-Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 14:47:06 +0000 Original-Received: from localhost ([127.0.0.1]:39989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI9iQ-0004pK-Rp for submit@debbugs.gnu.org; Wed, 18 Jan 2023 09:47:06 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36650) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI9iO-0004op-Si for 60929@debbugs.gnu.org; Wed, 18 Jan 2023 09:47:01 -0500 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 1pI9iJ-0004bZ-Hn; Wed, 18 Jan 2023 09:46:55 -0500 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=npgPhWgzN2GnAlqlWZetTTpiUVjlPUPMd8Gglpo1nBc=; b=npn0ZYvqvTgy Cf1tjsLTmCNzc/qJnGj2S7aKEjGizmxMjv8CbQENnixrPJU+duSu9Vvg2QHlA4sbCizmYA+GSRkFg JfND2TGAfjtSo4erpHOukxGzjasR1f0UdxDZvR+h+tSg4vOQI1SCU4mHj9dX3obhCCsV5l3x/mAX+ 9FPJ79sMCbQadH5hYPv8eoevedhcr6SaR44XsFJVkgQsqjG6gJm9PKmacPtqX36fGREN/EY5ArP3E 6mkEFuupxaMUIKxsJGaZXtv8Py4sI1/yhk60mq4kKhWgC+w0s4MZDNOdUkIyvigHCnEkPZHkpBSxn Y7rzz4jLJpIjFzvnZc15xw==; 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 1pI9iI-00033G-GK; Wed, 18 Jan 2023 09:46:55 -0500 In-Reply-To: <87v8l45740.fsf@localhost> (message from Ihor Radchenko on Wed, 18 Jan 2023 13:01:51 +0000) 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:253639 Archived-At: > From: Ihor Radchenko > Cc: 60929@debbugs.gnu.org > Date: Wed, 18 Jan 2023 13:01:51 +0000 > > Eli Zaretskii writes: > > > file-name-sans-extension isn't supposed to remove backup suffixes, > > it's supposed to remove file _versions_. > > Then, its docstring is totally misleading: Please read the just-updated one. I did say that the doc string was misleading, so we are in violent agreement here. > (file-name-sans-extension "asd.org.~12~") ; => "asd" <-- surprising > (file-name-sans-extension "asd.org~") ; => "asd" > (file-name-sans-extension "asd.org.bak") ; => "asd.org" > (file-name-sans-extension "asd.org") ; => "asd" Does the new doc string explain the above well enough? > >> auto-mode-alist recognizes > >> > >> ("\\.~?[0-9]+\\.[0-9][-.0-9]*~?\\'" nil t) > >> ("\\.\\(?:orig\\|in\\|[bB][aA][kK]\\)\\'" nil t) > >> > >> as backup extension and thus opens files like foo.org.bak with Org mode. > > > > And this is wrong because...? > > Nothing wrong. Just inconsistent. > The first regexp is covered by `file-name-extension' > But not the second. I don't see how the mode in which we visit the file can or should be "consistent" with what file-name-extension does. These are two different (although somewhat related) operations, and for two different purposes. You seem to explain that the fact we visit foo.org.bak in Org mode by what file-name-sans-extension does, but that's not what actually happens, and you know it. > >> It would be useful if functions like `file-name-extension', > >> `file-name-sans-extension', and similar could optionally strip backup > >> suffixes that contain ".". > > > > Can't you do this by binding file-name-version-regexp to something > > that gets the job done. > > Sure, but I wanted to keep things between what Emacs considers a backup > file and my code in sync. The purpose of what you need to do and what Emacs considers a backup may or may not be the same. > Also, `file-name-version-regexp' is not the most obvious variable name > when I think about backups. I thought that version and backup are > totally unrelated. They aren't, and I hope the updated doc strings make that more clear. > The issue is how Org calculates export file name. > As another part of the linked message points, foo.org.bak is transformed > to foo.org.html, when exporting to HTML. This is because Org uses > `file-name-sans-extension' to find "base" file name, which is not giving > the expected results for backup files like foo.org.bak (note that > (file-name-base "foo.org.bak") ; => "foo.org" and cannot be used either) It sounds like your code assumes that any file visited in Org mode has only one extension? Is that assumption justified? > So, I'd need to have a separate code branch to fix the original issue > with export file name from backup files. It will need to match against > some regexp for backup files. Rather than trying to re-invent the regexp > of copy-paste from auto-mode-alist, I was hoping that some API exists in > Emacs to work with backup files. Thus, this FR. AFAIU, you want an API that would recursively remove extensions until some criteria (perhaps the same ones we use when processing auto-mode-alist?) are satisfied. We don't have such an API, AFAIK. And I think your request as written makes the problem sound less general than it actually is: your problem is not just with backup files and their various extensions in auto-mode-alist, the problem will also happen in other cases, like foo.org.gpg, or with any customizations of auto-mode-alist that add extensions which are processed like backup files are processed now. So I think your feature request should be redefined in more general terms.