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 14:47:14 +0200 Message-ID: <83y1q01031.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="23640"; 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 13:49:20 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 1pI7sW-0005oj-La for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 Jan 2023 13:49:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pI7rw-0001xV-Qs; Wed, 18 Jan 2023 07:48:44 -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 1pI7rG-0001iz-Nf for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:48:24 -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 1pI7rF-0008AV-Ub for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:48:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pI7rF-0001my-Qa for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 07:48:01 -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 12:48: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.16740460296672 (code B ref 60929); Wed, 18 Jan 2023 12:48:01 +0000 Original-Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 12:47:09 +0000 Original-Received: from localhost ([127.0.0.1]:39748 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI7qP-0001jX-Bq for submit@debbugs.gnu.org; Wed, 18 Jan 2023 07:47:09 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:55164) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI7qN-0001jB-Cl for 60929@debbugs.gnu.org; Wed, 18 Jan 2023 07:47:07 -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 1pI7qH-0007gA-SZ; Wed, 18 Jan 2023 07:47:01 -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=/rN/EcRUizsQpJzMwP8pjMaDGUPiKi3aoE9Yc+xlRqw=; b=Et5dsX1xht6Q 2tYUlQ+0N1i/p5LU/UqggmqhnrMfO0m297bquWNELht148TpGFxeijDMr4m/sQ7PZiE2XM8ESFY+d MIRWGpW/QVjJcGJ8TkjXrgorCZwfUqlOgVhVFeNLilZ+6EmmDrMU8B6+gH44Q17v0x6nsAJkUqRyw EkAup7q7wdcCIyOhMxQCZyb5uxZdMkkZteLLW9XqPCXtnUuAWHohu6rW8rnGyxVj2FwH/HNKBNJiy NWZo0aNc15ywYJFgnoMN/ZjU/Thsu1WDtjUetxPwsq/5vtcz1mh9KzkpXxlD7rcLD6ZNrQwl4lk1W v0bOFBz+JiAu09WB4Mz0OA==; 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 1pI7qH-0006pE-Aq; Wed, 18 Jan 2023 07:47:01 -0500 In-Reply-To: <87o7qw6rrz.fsf@localhost> (message from Ihor Radchenko on Wed, 18 Jan 2023 10:50:08 +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:253626 Archived-At: > From: Ihor Radchenko > Date: Wed, 18 Jan 2023 10:50:08 +0000 > > Would it be possible to make `file-name-sans-extension' strip extension > upon removing backup suffixes (optionally)? > > Currently, Emacs' handling of backup extensions is a bit inconsistent: file-name-sans-extension isn't supposed to remove backup suffixes, it's supposed to remove file _versions_. > 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...? > Further, `file-name-extension' returns: > > The extension, in a file name, is the part that begins with the last ., > excluding version numbers and backup suffixes, except that a leading . > of the file name, if there is one, doesn't count. This documentation is slightly inaccurate, and thus misleading. It should be fixed. The truth is evident if you look at the code: this function is the opposite of file-name-sans-extension, whose doc string doesn't say anything about backup suffixes. > 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. > 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? And what does that have to do with the main issue you are raising here? I feel there's some logical gap here.