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: Wed, 18 Jan 2023 13:01:51 +0000 Message-ID: <87v8l45740.fsf@localhost> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.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="12415"; 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 Wed Jan 18 14:02:42 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 1pI85R-00033v-Vt for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 14:02:42 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI84p-0001UX-NI; Wed, 18 Jan 2023 08:02:03 -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 1pI84o-0001UC-NW for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 08:02: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 1pI84o-00038U-DQ for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 08:02:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pI84o-00029y-5T for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 08:02:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jan 2023 13:02: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.16740468888260 (code B ref 60929); Wed, 18 Jan 2023 13:02:02 +0000 Original-Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 13:01:28 +0000 Original-Received: from localhost ([127.0.0.1]:39766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI84F-000299-Q4 for submit@debbugs.gnu.org; Wed, 18 Jan 2023 08:01:28 -0500 Original-Received: from mout01.posteo.de ([185.67.36.65]:39885) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI84D-00028u-VX for 60929@debbugs.gnu.org; Wed, 18 Jan 2023 08:01:26 -0500 Original-Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3A20C240235 for <60929@debbugs.gnu.org>; Wed, 18 Jan 2023 14:01:19 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674046880; bh=ibk1FNafxFxAJ5B7dpUt1Q2ksq2hkv7f6+rdoCcsnBE=; h=From:To:Cc:Subject:Date:From; b=GQ59rxUvNg5iQFtKWy8ZT147rUDH7b4LT5riKLalk9WKk8WlTUEGJkfBVxSOZPu+o i63K9Rw7OS9myiqmQxZ/tPeCPtgex8ZJF6N71pFtyR7mbZClYZc86kslXPiGmyxg8q CNo/qIIp6HC7INLhmotbx9Y5Qwdv3Ge/9rvCr806c2K1v+bXL+zVF7E7VLaxLq5ADT OJXMtGS7aiAqwoes3stfWDpna48mzGdf/6+sqdJCSig71e6r3hgXPQ8Oo0B2Lfg7aR 7qr+fFQ60GW7dDk2xICqEZErqc7z3ilo4Q1bU5NM8P0GIuQSt/w6hKXX2n9KZR3bb8 NwvcACDbcdFBg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4Nxm9B6lSJz9rxR; Wed, 18 Jan 2023 14:01:18 +0100 (CET) In-Reply-To: <83y1q01031.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:253627 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: Return FILENAME sans final "extension". The extension, in a file name, is the part that begins with the last ., except that a leading . of the file name, if there is one, doesn't count. Nothing is said about versions. Yet, (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" >> 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. >> But it only works for the native Emacs "~" style of backups (on Linux, >> at least). If one tries (file-name-extension "foo.org.bak") ; => "bak", >> we do not see backup extension stripped, which is correct wrt the >> docstring, but problematic when we need to handle backup files on >> Windows. >> >> If one needs to strip backup extension/suffix for .bak and similar >> files, there is a need to re-use >> "\\.\\(?:orig\\|in\\|[bB][aA][kK]\\)\\'" regexp, which is not ideal >> because auto-mode-alist may include other backup suffixes in future. >> >> 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. 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. >> Context: https://orgmode.org/list/25543.50706.554658.6937@gargle.gargle.HOWL > > FWIW, I don't understand this context: is it wrong for some reason > that foo.org.bak is visited in Org mode? If it's wrong, then why? It is not wrong. > And what does that have to do with the main issue you are raising > here? I feel there's some logical gap here. 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) 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. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at