From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.bugs Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Date: Mon, 23 Jan 2023 10:05:18 +0000 Message-ID: <878rht7eht.fsf@localhost> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.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="4231"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 60929@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 23 11:05:17 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 1pJthV-0000uB-1N for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 23 Jan 2023 11:05:17 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pJthJ-0008T9-1N; Mon, 23 Jan 2023 05:05:05 -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 1pJthG-0008RL-A7 for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 05:05:02 -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 1pJthG-0005oE-0P for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 05:05:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pJthF-00078d-Po for bug-gnu-emacs@gnu.org; Mon, 23 Jan 2023 05:05:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2023 10:05:01 +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.167446829727424 (code B ref 60929); Mon, 23 Jan 2023 10:05:01 +0000 Original-Received: (at 60929) by debbugs.gnu.org; 23 Jan 2023 10:04:57 +0000 Original-Received: from localhost ([127.0.0.1]:53408 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJthA-00078F-DL for submit@debbugs.gnu.org; Mon, 23 Jan 2023 05:04:56 -0500 Original-Received: from mout02.posteo.de ([185.67.36.66]:48701) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJth7-00077z-Bw for 60929@debbugs.gnu.org; Mon, 23 Jan 2023 05:04:54 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 27077240388 for <60929@debbugs.gnu.org>; Mon, 23 Jan 2023 11:04:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674468287; bh=pdr0HUqgs8qZYDJzcEpDvaNL3LQG+3zssXpG6by4s6k=; h=From:To:Cc:Subject:Date:From; b=PfvWLPW9067Q1gB/adlGnWXaen+l7fx1GJbCdaPUkbd9zpxqE7IIG4t3D5XuQ3wyh xgqQL/mdk73W3qFkZ7a8TboMWpPEzyl3D+V/iTlgM5miWS6856xwCvkXRbNmnokhqn dz3FNaDx60KNkBK/BZkwxceCOPZIi6vLo+Ek9Ceue2wkP5OiV4wnRUUyaq8k8CfWPE QAfC/NnzhMBXxuZbpG3a4MP8ea54qWAxWC8VZj3IHEgBLH1UFnwxGeXWNxgY+SW2jA Idv+o98+u1F5zSb8/TFzwxddnSLrsvcUDulnB7+FnjXKJWy6ZPJlpRM4zYh2s4gADe hZ8y50u4b3ZKQ== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P0m1B1JxQz9rxL; Mon, 23 Jan 2023 11:04:45 +0100 (CET) In-Reply-To: <83ilh3293n.fsf@gnu.org> 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:253983 Archived-At: 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? Yes. It is completely accurate now, AFAIU. >> >> 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. Sure. I did not imply the `file-name-extension' must follow selection of major-mode. What I mean is that Emacs has an additional regexp about what files can be considered "backup". This regexp is not reachable if other places in code happen to need it. >> 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? It is not, indeed. Just some reasonable default. Users can always override the file name Org uses when exporting. However, stripping known double extension in .org.bak files would make the Org's default even more intuitive (Org already strips Emacs' default backup suffix anyway). >> 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. You are right. In fact, Org mode does strip .gpg as well---another special case. Some third-party extensions go further and similarly strip .age suffix (https://github.com/FiloSottile/age). So, let me formulate the FR more generally: 1. Emacs is currently able to work with double-extension files transparently. - For example, opening encrypted foo.ext.gpg files looks as if the file foo.ext were opened - no special action is required on the user side. - Similarly, backup foo.ext.bak/foo.ext.~12~ file versions are opened using the same rules (in auto-mode-alist) as foo.ext. Again, users mostly get the same experience as if they simply opened foo.ext. 2. These double-extension functionality is, however, implemented on ad-hoc basis with no clear common Elisp API provided. Elisp libraries may need to re-implement handling of files foo.ext.extra specially, even though, otherwise, the files are seen to the libraries as foo.ext 3. It would be nice to have Elisp API to determine (1) "effective" file name as seen to the user wrt editing functionality (foo.ext); (2) a list of transformations Emacs applied to the file contents when opening the file (decrypt, strip backup/version, tramp connection, etc) -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at