From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jan 2023 10:50:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 60929@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.167403899121013 (code B ref -1); Wed, 18 Jan 2023 10:50:01 +0000 Received: (at submit) by debbugs.gnu.org; 18 Jan 2023 10:49:51 +0000 Received: from localhost ([127.0.0.1]:39397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI60t-0005Sr-0d for submit@debbugs.gnu.org; Wed, 18 Jan 2023 05:49:51 -0500 Received: from lists.gnu.org ([209.51.188.17]:51454) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI60o-0005Sf-Vl for submit@debbugs.gnu.org; Wed, 18 Jan 2023 05:49:49 -0500 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 1pI60o-0002pn-ML for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 05:49:46 -0500 Received: from mout01.posteo.de ([185.67.36.65]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pI60l-0002Ey-8O for bug-gnu-emacs@gnu.org; Wed, 18 Jan 2023 05:49:46 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 3D09F240323 for ; Wed, 18 Jan 2023 11:49:39 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674038979; bh=3/Bg2V8mCuyttnQcBdiRxYKE83R/MuOPy0zJ0O2WhBk=; h=From:To:Subject:Date:From; b=aUF3csAEcEvHWaIq61Wh7Ju497F4Yc2u6W5YVwrurAebCm6EJO/EtoDxJCdiGcfFs PTuzwp7AhliaozLgN3S8eXDPVMDrGbzH3vCg+n5W7yqnjoDQMtOjx+hkIxigoxxk7+ 4UtVotNXHQq/EfwoRWwmHYqEzOv/zekY4rBITl9NkCmd9EootO9qi5BV3B+EWfc6NQ 8tDFI7tcNCnr89ydr3/trFJkVoylGs0+Jwqge1q2BEO9djEa5YK8BC2DCp1rDhmbrm F1JoVPu80wNXQZMxWCA2//GlaC2B/p29GzNgGL7zVL8AvWGmfjN5k1kGgnF5TzY5YK rPSBYntcl60Mw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NxjFF1MRGz9rxX for ; Wed, 18 Jan 2023 11:49:36 +0100 (CET) From: Ihor Radchenko Date: Wed, 18 Jan 2023 10:50:08 +0000 Message-ID: <87o7qw6rrz.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@posteo.net; helo=mout01.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) Hi, 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: 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. 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. 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 ".". Context: https://orgmode.org/list/25543.50706.554658.6937@gargle.gargle.HOWL In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, cairo version 1.17.6) of 2023-01-16 built on localhost Repository revision: bb679244152dddd9949ca065aa6617457f7a7144 Repository branch: master Windowing system distributor 'The X.Org Foundation', version 11.0.12101006 System Description: Gentoo Linux -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ruijie Yu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jan 2023 11:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167404049132498 (code B ref 60929); Wed, 18 Jan 2023 11:15:01 +0000 Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 11:14:51 +0000 Received: from localhost ([127.0.0.1]:39463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI6P4-0008S5-Vj for submit@debbugs.gnu.org; Wed, 18 Jan 2023 06:14:51 -0500 Received: from netyu.xyz ([152.44.41.246]:49304 helo=mail.netyu.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI6P2-0008Rw-KB for 60929@debbugs.gnu.org; Wed, 18 Jan 2023 06:14:49 -0500 Received: from fw.net.yu.netyu.xyz ( [222.248.4.98]) by netyu.xyz (OpenSMTPD) with ESMTPSA id cb23116c (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 18 Jan 2023 11:14:47 +0000 (UTC) References: <87o7qw6rrz.fsf@localhost> User-agent: mu4e 1.8.13; emacs 29.0.60 From: Ruijie Yu Date: Wed, 18 Jan 2023 19:08:36 +0800 In-reply-to: <87o7qw6rrz.fsf@localhost> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Ihor Radchenko writes: > Hi, > > 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: > > 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. > > [...] > > It would be useful if functions like `file-name-extension', > `file-name-sans-extension', and similar could optionally strip backup > suffixes that contain ".". > [...] Note that since the backup extensions can be stripped recursively in `auto-mode-alist' (that is, "test.c.bak.Bak.BAK.baK" is opened in c-mode because of the recursive extension stripping), if this FR is to be accepted, we would need to ensure that the above scenario is covered. Best, RY From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes 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 X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.16740460296672 (code B ref 60929); Wed, 18 Jan 2023 12:48:01 +0000 Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 12:47:09 +0000 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 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 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==; 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 Date: Wed, 18 Jan 2023 14:47:14 +0200 Message-Id: <83y1q01031.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87o7qw6rrz.fsf@localhost> (message from Ihor Radchenko on Wed, 18 Jan 2023 10:50:08 +0000) References: <87o7qw6rrz.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.16740468888260 (code B ref 60929); Wed, 18 Jan 2023 13:02:02 +0000 Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 13:01:28 +0000 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 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 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== 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) From: Ihor Radchenko In-Reply-To: <83y1q01031.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> Date: Wed, 18 Jan 2023 13:01:51 +0000 Message-ID: <87v8l45740.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 18 Jan 2023 14:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: yantar92@posteo.net Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167405164216048 (code B ref 60929); Wed, 18 Jan 2023 14:21:01 +0000 Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 14:20:42 +0000 Received: from localhost ([127.0.0.1]:39918 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI9Iw-0004Am-1K for submit@debbugs.gnu.org; Wed, 18 Jan 2023 09:20:42 -0500 Received: from eggs.gnu.org ([209.51.188.92]:58574) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pI9It-0004AY-VB for 60929@debbugs.gnu.org; Wed, 18 Jan 2023 09:20:40 -0500 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 1pI9Io-0000Kr-Jy; Wed, 18 Jan 2023 09:20:34 -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=yojy4Ybbm4GKC1EnQi8VTFxYjPFRVJwZUq5SSCv68ak=; b=hEGr/xBpdgLW qU8HQYk84sVSniMTM2/f6A8Rf+mTw5TA1PkRl7kvh0jikdZUIQqQKxrT1VYRS8QVTaR+noarj5wvB +GHEL8oRWdCa04G7TqT0oNJncLK8J767sJDLPDQn+PnpnqacFZxEnte8Wo/RUPWaHVaB7RRELvVcS WYvgCF5lyI2D5xWWXt9DO1S/buQ6avtmC/gQuGXBzT0U/NLeBTJTzBwkevdrvzClPuU1lQt8suuqP i78zzVi06J873fJrCoafZgiCX7n8DLf9s2OlnzVLM7YsfwQ78O9Bsu2D0DV7uqsCP7XZOJ/Sl5/s3 a/rNWfVMQJtrM8xi6TWsiQ==; 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 1pI9Io-0004rn-3i; Wed, 18 Jan 2023 09:20:34 -0500 Date: Wed, 18 Jan 2023 16:20:48 +0200 Message-Id: <83k01j2abj.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <83y1q01031.fsf@gnu.org> (message from Eli Zaretskii on Wed, 18 Jan 2023 14:47:14 +0200) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 60929@debbugs.gnu.org > Date: Wed, 18 Jan 2023 14:47:14 +0200 > From: Eli Zaretskii > > > 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. Now done. From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes 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 X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167405322618567 (code B ref 60929); Wed, 18 Jan 2023 14:48:02 +0000 Received: (at 60929) by debbugs.gnu.org; 18 Jan 2023 14:47:06 +0000 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 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 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==; 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 Date: Wed, 18 Jan 2023 16:47:08 +0200 Message-Id: <83ilh3293n.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87v8l45740.fsf@localhost> (message from Ihor Radchenko on Wed, 18 Jan 2023 13:01:51 +0000) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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. From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes 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 X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167446829727424 (code B ref 60929); Mon, 23 Jan 2023 10:05:01 +0000 Received: (at 60929) by debbugs.gnu.org; 23 Jan 2023 10:04:57 +0000 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 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 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== 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) From: Ihor Radchenko In-Reply-To: <83ilh3293n.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> Date: Mon, 23 Jan 2023 10:05:18 +0000 Message-ID: <878rht7eht.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) 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 From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 23 Jan 2023 13:35:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.16744808693385 (code B ref 60929); Mon, 23 Jan 2023 13:35:03 +0000 Received: (at 60929) by debbugs.gnu.org; 23 Jan 2023 13:34:29 +0000 Received: from localhost ([127.0.0.1]:53667 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJwxx-0000sX-4q for submit@debbugs.gnu.org; Mon, 23 Jan 2023 08:34:29 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48218) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pJwxw-0000sK-1i for 60929@debbugs.gnu.org; Mon, 23 Jan 2023 08:34:28 -0500 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 1pJwxq-0001cu-Q6; Mon, 23 Jan 2023 08:34:22 -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=uHB0ONW3V6aQnCdyUiZ3/n2MUvvHELOiyDf8xb05vks=; b=oUoIiAoTlV5e q7BoZV6z5whWdmfTClOLw4pVpLENHg7TWs85WGfwZzrMod3ru45wQHpeSfEX5vOr1pTO+GhnVvBfA 2FLzfGAi1uV76lw9+hzUQumfVD/5Sk6h1BjxIoQ10mxk63I7dVc6ES0d300afvLbDWug+xAcYH5u6 3dnjsmPO0aFKJDUeahGGhLveYTiODF8mm0/KEKDFkFZ/ZIZUKcx9kAOp3KkEnA6/ls8G0qtj/uxqh xQg/7wSFVMZaXuUvP/hrkfAMAyesPH6E5VBqa4liOkmkw3rcxVOJlQXm3eGmj61VlB9WCH2co+pcR Vz+tHkoK7uGDHaASDjEYqQ==; 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 1pJwxq-0001cc-63; Mon, 23 Jan 2023 08:34:22 -0500 Date: Mon, 23 Jan 2023 15:34:30 +0200 Message-Id: <83tu0hidcp.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <878rht7eht.fsf@localhost> (message from Ihor Radchenko on Mon, 23 Jan 2023 10:05:18 +0000) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 60929@debbugs.gnu.org > Date: Mon, 23 Jan 2023 10:05:18 +0000 > > So, let me formulate the FR more generally: > > 1. Emacs is currently able to work with double-extension files > transparently. Not only double-extension: you could have foo.org.bak.gpg, for example. The way we process entries in auto-mode-alist allows to "peel off" any number of extensions. > - 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) What would you do with the "effective" file name obtained via such a hypothetical API? I'm asking because the answer might be relevant to defining the terms in which the API will return the information; a file name is just one possibility, not the only one. For example, if you want the file name so you could know the appropriate major mode, perhaps a better interface would be to give you a list of relevant major modes? From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2023 11:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167455875727505 (code B ref 60929); Tue, 24 Jan 2023 11:13:02 +0000 Received: (at 60929) by debbugs.gnu.org; 24 Jan 2023 11:12:37 +0000 Received: from localhost ([127.0.0.1]:55976 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKHEC-00079Z-Jo for submit@debbugs.gnu.org; Tue, 24 Jan 2023 06:12:36 -0500 Received: from mout02.posteo.de ([185.67.36.66]:38233) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKHEB-00079M-Pa for 60929@debbugs.gnu.org; Tue, 24 Jan 2023 06:12:36 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D8360240132 for <60929@debbugs.gnu.org>; Tue, 24 Jan 2023 12:12:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674558749; bh=LA28ZARi0IBsVz94zv4oYsLJds70k6hAvI2zSH/XE40=; h=From:To:Cc:Subject:Date:From; b=fF5ksuxW3nFRV8MI0gq90BNx8P1s9dh4pNvu+6xFPdQbPu8dLxmv/x+FJz7UmnNsW MBc4Rk6x+bQbUjNeVojw3oP73pc/9pSbN5R2nPvSIZnzm1t5fXJlbCD4EcDgSPpr2C M/2DCUBXAx5jmW5qPMLNeiD5ZDcLPyXXDVwx9ZXJ7wn/a/mYtP0UiVzPIhCrwUm8Gg gTWH5zM6jmyN23qHsuWTvb9Km+1Fin2o2S13btAfAllrtXmczk/l+W/1rNeXML2bv/ Xz3JeKOxaaOE2Wu+4p0war2+F8KLar8WCUEZhb1wc32KpqkVJkVFPPpdQ7z2ThC98g N9Htc62hhw+uA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P1PSr3Jc3z6tnQ; Tue, 24 Jan 2023 12:12:25 +0100 (CET) From: Ihor Radchenko In-Reply-To: <83tu0hidcp.fsf@gnu.org> Message-ID: <87cz745gqp.fsf@localhost> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> Date: Tue, 24 Jan 2023 11:12:56 +0000 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> 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) > > What would you do with the "effective" file name obtained via such a > hypothetical API? I'm asking because the answer might be relevant to > defining the terms in which the API will return the information; a > file name is just one possibility, not the only one. The original need is deriving exported file name. I can also imagine one trying to apply equivalent encryption or simply file name suffix to the exported file: foo.org.gpg -> (exports to) foo.html.gpg foo.org.~10~ -> (exports to) foo.html.~10~ foo.org.gpg -> (backed up to + auto-encrypted) foo.org.gpg~ foo.org.gz -> (exports to + auto-compressed) foo.html.gz Hmm... If we go further into generalization, what I am talking about is centralized API to "describe" current buffer file: 1. What is already there: - `buffer-file-name' - `buffer-file-truename' - `buffer-file-number' 2. What could be made available: - TRAMP mount point - `buffer-effective-name' - some info + callback to re-encrypt/re-archive/re-apply suffixes for a given file buffer onto another file buffer. > For example, if you want the file name so you could know the > appropriate major mode, perhaps a better interface would be to give > you a list of relevant major modes? I am not sure what you refer to here. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 24 Jan 2023 12:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167456385913056 (code B ref 60929); Tue, 24 Jan 2023 12:38:01 +0000 Received: (at 60929) by debbugs.gnu.org; 24 Jan 2023 12:37:39 +0000 Received: from localhost ([127.0.0.1]:56062 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKIYU-0003OW-Sz for submit@debbugs.gnu.org; Tue, 24 Jan 2023 07:37:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:54974) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKIYT-0003OJ-5i for 60929@debbugs.gnu.org; Tue, 24 Jan 2023 07:37:37 -0500 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 1pKIYM-0001qt-Pb; Tue, 24 Jan 2023 07:37:31 -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=uNEZvzbvcobBwkkVydGAeb9AKKeDE2NiivhXz5fQsoI=; b=QxgE+G0eDU2e NpgFeNj1UR+VkHRyzNZO4KUqYboe3pauFldWbO9Ay+F4s0Dm4lOeFM5/fo/DwhUzXCYj1/rhtdfkZ R2gPjUPRzK/Drz+7q/ckM+WtWIavztJI6Iw3bJFzelAwKMXd3iQNPT3rSLtXg1WrDPMjhvj2mMPHa SnIcUtqIGUVSBbZ5MoqxQSR+KQQxs1HdscFxjiadpEC6P9rc84UoYNsacqgQsAnMJaObgX/FQBIh/ m0YgoexL46ZYdf7UwfNFwtVv87RrnVbkE+X/CHuANlfS2REXXa7DCZLLm6jExWg+w2rgAsfvAj9XK C8ZAweULeOycs79mMlPPjQ==; 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 1pKIY9-0007Nr-E3; Tue, 24 Jan 2023 07:37:28 -0500 Date: Tue, 24 Jan 2023 14:37:27 +0200 Message-Id: <83y1psglbs.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87cz745gqp.fsf@localhost> (message from Ihor Radchenko on Tue, 24 Jan 2023 11:12:56 +0000) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 60929@debbugs.gnu.org > Date: Tue, 24 Jan 2023 11:12:56 +0000 > > Eli Zaretskii writes: > > Hmm... If we go further into generalization, what I am talking about is > centralized API to "describe" current buffer file: > > 1. What is already there: > > - `buffer-file-name' > - `buffer-file-truename' > - `buffer-file-number' > > 2. What could be made available: > > - TRAMP mount point > - `buffer-effective-name' > - some info + callback to re-encrypt/re-archive/re-apply suffixes > for a given file buffer onto another file buffer. > > > For example, if you want the file name so you could know the > > appropriate major mode, perhaps a better interface would be to give > > you a list of relevant major modes? > > I am not sure what you refer to here. I mean: . given "foo.org.~10~" return the list ("foo" org-mode backup) . given "foo.org.gpg.gz" return ("foo" org-mode epa-file compress) etc. From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 13:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167465270829382 (code B ref 60929); Wed, 25 Jan 2023 13:19:01 +0000 Received: (at 60929) by debbugs.gnu.org; 25 Jan 2023 13:18:28 +0000 Received: from localhost ([127.0.0.1]:58604 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKffY-0007dq-4D for submit@debbugs.gnu.org; Wed, 25 Jan 2023 08:18:28 -0500 Received: from mout02.posteo.de ([185.67.36.66]:52717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKffU-0007dW-UR for 60929@debbugs.gnu.org; Wed, 25 Jan 2023 08:18:27 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id A64C4240817 for <60929@debbugs.gnu.org>; Wed, 25 Jan 2023 14:18:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674652698; bh=dAFynaNztvY3mqzpyuvY2C1My6FDnAXYrM6NfsYb1hs=; h=From:To:Cc:Subject:Date:From; b=U4FWRABB2j7JSgN9AjTNGwg7dMKYTJlxs0/tBCg8xtnIT88KakEMxDeCwlnF4turM R1HNBlGaIXA6hyTR0zUf6FQ7X6RENdlbKLBSBlar4SRBgrljG27m5JgMaZf+TDIMgs /DlsgXcCts1UTwImxMmTJwyxTMHH9IURtJnp0tlez0e+c07IpNJhidQvLIAN14pewH HbI7CmFBWB8khaew0zL40qEGA649RKcy5rbRKD6H0c3JDCQgof57qR2Ttk4+RKNrG8 1t8wYCFxe7kBrGAEo3iBWsHgAFNkTeAqDdz4/BOghPNU8TcFOMrpXwKE/4CSzIYscN IAKuEYI2xEZzQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P24CY10Mvz9rxb; Wed, 25 Jan 2023 14:18:16 +0100 (CET) From: Ihor Radchenko In-Reply-To: <83y1psglbs.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> <83y1psglbs.fsf@gnu.org> Date: Wed, 25 Jan 2023 13:18:48 +0000 Message-ID: <87y1pqlpl3.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> I am not sure what you refer to here. > > I mean: > > . given "foo.org.~10~" return the list ("foo" org-mode backup) > . given "foo.org.gpg.gz" return ("foo" org-mode epa-file compress) I do not think that you can deterministically associate file extension with major mode. Alternative major modes do exist for some file extensions (like built-in python.el vs. python-mode.el). Just extension list may suffice in the simplest scenarios. In addition, given "foo.txt.org.gpg.gz" may return ("foo.txt" "org" "gpg" "gz") not stripping the first .txt as it never affects how Emacs opens the file. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 13:27:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ihor Radchenko Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167465319230337 (code B ref 60929); Wed, 25 Jan 2023 13:27:01 +0000 Received: (at 60929) by debbugs.gnu.org; 25 Jan 2023 13:26:32 +0000 Received: from localhost ([127.0.0.1]:58618 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfnM-0007tF-D7 for submit@debbugs.gnu.org; Wed, 25 Jan 2023 08:26:32 -0500 Received: from eggs.gnu.org ([209.51.188.92]:48390) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfnK-0007sz-Ee for 60929@debbugs.gnu.org; Wed, 25 Jan 2023 08:26:31 -0500 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 1pKfnE-0004K9-89; Wed, 25 Jan 2023 08:26:25 -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=mICp83T9pu4eFMHPBE/m3WTa+gdzCNUVxVl6wd6d/mU=; b=qaBRhfklSgg5 K9Sgj2giRN4gFgfXTv7mhKlb5Sd2hN4ABSad7qUtkXZMTL0hNTRL0hyRh2gW7ifjUH2lZ1ohBXIdk +HtBqo0eHda8bZHvoLqs+tmvrN8pQEJ4kK1H3KvQvM/Xu3y0K1WbhXhfgZ34NBBt5bo+kiArATkY0 0mV/2fBpPb87vg3EIr8fDrX9IvbolRsSj9S3YfnZq12rRA9wI1MJJ4QjTC+q/ELTbgGjLMHnQ6IxZ OLk9pJfdRwC5kHAa0RngI8+9+6Oi30gICEkkPJVTuceWYmtPtkFl0Pr4/VUcW7JFzdIOGMM9sj3ay bmkilSy0HjlWQ6CD0EHUwg==; 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 1pKfnD-0003PF-7L; Wed, 25 Jan 2023 08:26:23 -0500 Date: Wed, 25 Jan 2023 15:26:37 +0200 Message-Id: <83mt66g2ya.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87y1pqlpl3.fsf@localhost> (message from Ihor Radchenko on Wed, 25 Jan 2023 13:18:48 +0000) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> <83y1psglbs.fsf@gnu.org> <87y1pqlpl3.fsf@localhost> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Ihor Radchenko > Cc: 60929@debbugs.gnu.org > Date: Wed, 25 Jan 2023 13:18:48 +0000 > > Eli Zaretskii writes: > > > . given "foo.org.~10~" return the list ("foo" org-mode backup) > > . given "foo.org.gpg.gz" return ("foo" org-mode epa-file compress) > > I do not think that you can deterministically associate file extension > with major mode. Alternative major modes do exist for some file > extensions (like built-in python.el vs. python-mode.el). Just extension > list may suffice in the simplest scenarios. The intent was to use auto-mode-alist, of course. Or are you saying that you'd like, for example, to treat *.org files as Org files even if the user customized auto-mode-alist to use a different mode? > In addition, given "foo.txt.org.gpg.gz" may return > ("foo.txt" "org" "gpg" "gz") not stripping the first .txt as it never > affects how Emacs opens the file. Talking about "opening the file" again narrows the scope of the requested feature, IMO. We don't want to assume that the application would like to open the file. Besides, Text mode does affect how Emacs treats the file. From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ruijie Yu Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Ihor Radchenko , 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167465380531611 (code B ref 60929); Wed, 25 Jan 2023 13:37:02 +0000 Received: (at 60929) by debbugs.gnu.org; 25 Jan 2023 13:36:45 +0000 Received: from localhost ([127.0.0.1]:58635 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfxF-0008Dl-EW for submit@debbugs.gnu.org; Wed, 25 Jan 2023 08:36:45 -0500 Received: from netyu.xyz ([152.44.41.246]:50930 helo=mail.netyu.xyz) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfxC-0008DX-Ms for 60929@debbugs.gnu.org; Wed, 25 Jan 2023 08:36:43 -0500 Received: from fw.net.yu.netyu.xyz ( [223.94.109.149]) by netyu.xyz (OpenSMTPD) with ESMTPSA id 800d1e41 (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Wed, 25 Jan 2023 13:36:40 +0000 (UTC) References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> <83y1psglbs.fsf@gnu.org> <87y1pqlpl3.fsf@localhost> <83mt66g2ya.fsf@gnu.org> User-agent: mu4e 1.8.13; emacs 29.0.60 From: Ruijie Yu Date: Wed, 25 Jan 2023 21:33:59 +0800 In-reply-to: <83mt66g2ya.fsf@gnu.org> Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Eli Zaretskii writes: >> From: Ihor Radchenko >> Cc: 60929@debbugs.gnu.org >> Date: Wed, 25 Jan 2023 13:18:48 +0000 >> >> Eli Zaretskii writes: >> >> > . given "foo.org.~10~" return the list ("foo" org-mode backup) >> > . given "foo.org.gpg.gz" return ("foo" org-mode epa-file compress) >> >> I do not think that you can deterministically associate file extension >> with major mode. Alternative major modes do exist for some file >> extensions (like built-in python.el vs. python-mode.el). Just extension >> list may suffice in the simplest scenarios. > > The intent was to use auto-mode-alist, of course. Or are you saying > that you'd like, for example, to treat *.org files as Org files even > if the user customized auto-mode-alist to use a different mode? > >> In addition, given "foo.txt.org.gpg.gz" may return >> ("foo.txt" "org" "gpg" "gz") not stripping the first .txt as it never >> affects how Emacs opens the file. > > Talking about "opening the file" again narrows the scope of the > requested feature, IMO. We don't want to assume that the application > would like to open the file. Besides, Text mode does affect how Emacs > treats the file. Another thing to consider is when the mode is not activated via `auto-mode-alist' -- for example, via M-x major-mode. Consider what happens to the proposed file extension list when "foo.txt" and "bar.txt.bak.gpg" are manually activated as `org-mode'. Best, RY From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167465380631617 (code B ref 60929); Wed, 25 Jan 2023 13:37:02 +0000 Received: (at 60929) by debbugs.gnu.org; 25 Jan 2023 13:36:46 +0000 Received: from localhost ([127.0.0.1]:58637 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfxF-0008Do-Pf for submit@debbugs.gnu.org; Wed, 25 Jan 2023 08:36:46 -0500 Received: from mout02.posteo.de ([185.67.36.66]:33301) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKfxB-0008DL-Gf for 60929@debbugs.gnu.org; Wed, 25 Jan 2023 08:36:43 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 175E524012E for <60929@debbugs.gnu.org>; Wed, 25 Jan 2023 14:36:32 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674653795; bh=niSC1vjBXET/Zjlz4huTwIcriFfngIFgFL8Tpwm0Iug=; h=From:To:Cc:Subject:Date:From; b=P2pZmonpjc/wlJGY8fftjlCDrPzW0+7gMwxp7tybFSVvgncE28zsY/6F3S7GMdWxS x+Ut7aX0iOK+KUyN/Qj8sOyymxFjAQQC1J2wf+uKSJRmnX9pGrQzxVnhTTxyeMlcyV VtMtqeTLc0XMR5/7vJH6d74py+2wAaeyOQk5lxxqodcLiZw2y+1bqj2IpN1Lgo0pKp Hka6xkDfHDA1w1pevkRF+KVe5NgcY4CQqTBruD5j1l2djH00KRXs5+aCVM9pqCM0MW T48obVtITxHZNrIm9LBHH608UmQXaEN0jl2SCyL3Ip+hFF50QD/WTJk/t3FD3D7oJt v4PT2riMfxZSg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P24cb6N2Dz9rxH; Wed, 25 Jan 2023 14:36:30 +0100 (CET) From: Ihor Radchenko In-Reply-To: <83mt66g2ya.fsf@gnu.org> References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> <83y1psglbs.fsf@gnu.org> <87y1pqlpl3.fsf@localhost> <83mt66g2ya.fsf@gnu.org> Date: Wed, 25 Jan 2023 13:37:03 +0000 Message-ID: <87pmb2loqo.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: >> > . given "foo.org.~10~" return the list ("foo" org-mode backup) >> > . given "foo.org.gpg.gz" return ("foo" org-mode epa-file compress) >> >> I do not think that you can deterministically associate file extension >> with major mode. Alternative major modes do exist for some file >> extensions (like built-in python.el vs. python-mode.el). Just extension >> list may suffice in the simplest scenarios. > > The intent was to use auto-mode-alist, of course. Or are you saying > that you'd like, for example, to treat *.org files as Org files even > if the user customized auto-mode-alist to use a different mode? Fair point. But then the extension information will be lost. "backup" may mean multiple different things, including "bak" or "~10~" or "~". "compress" may also involve different algorithms. >> In addition, given "foo.txt.org.gpg.gz" may return >> ("foo.txt" "org" "gpg" "gz") not stripping the first .txt as it never >> affects how Emacs opens the file. > > Talking about "opening the file" again narrows the scope of the > requested feature, IMO. We don't want to assume that the application > would like to open the file. Besides, Text mode does affect how Emacs > treats the file. Agree. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From unknown Sun Jun 15 08:38:44 2025 X-Loop: help-debbugs@gnu.org Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes Resent-From: Ihor Radchenko Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 25 Jan 2023 13:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60929 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Ruijie Yu Cc: Eli Zaretskii , 60929@debbugs.gnu.org Received: via spool by 60929-submit@debbugs.gnu.org id=B60929.167465420832379 (code B ref 60929); Wed, 25 Jan 2023 13:44:02 +0000 Received: (at 60929) by debbugs.gnu.org; 25 Jan 2023 13:43:28 +0000 Received: from localhost ([127.0.0.1]:58652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKg3j-0008QB-SF for submit@debbugs.gnu.org; Wed, 25 Jan 2023 08:43:28 -0500 Received: from mout01.posteo.de ([185.67.36.65]:51117) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pKg3g-0008Pq-WE for 60929@debbugs.gnu.org; Wed, 25 Jan 2023 08:43:27 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 129812404CE for <60929@debbugs.gnu.org>; Wed, 25 Jan 2023 14:43:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1674654199; bh=RlWLPnfXKmDq1MWKFw8J32hWv2GFRkE12/zYkorJILg=; h=From:To:Cc:Subject:Date:From; b=pmCDmeM3Qbx8pS+SaBZEM4qCMogQVSaFlWYhCRRuYoUvJpS1Y8dnt/XfWbnuLy8yA ajlbxHkd2V33ea02UraOv1BqoYKSJdL0BUpLB/OWVoiFzggyDQNSlplJtjx9GEHiPl kdsQdWuyzqELfQDnR7rV4MDlckAAuUX5xa4ZfdmRlaFP0usfFS+jLF9nspvvngNsl7 1T66YBCyE611oJB3xZyGJHwRpVHdQKahvaoEg/bSwegT6Ec4x7AcN+7iJjOqfth7Zg 5mkAFhAc0AVt9uf3fZSXjWjrer8Ktim6FWVohTqEGhcYFfExsGUv1UitkxjzTtvBeT Hb69gDEwZuPPQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4P24mM36Kcz6tm6; Wed, 25 Jan 2023 14:43:15 +0100 (CET) From: Ihor Radchenko In-Reply-To: References: <87o7qw6rrz.fsf@localhost> <83y1q01031.fsf@gnu.org> <87v8l45740.fsf@localhost> <83ilh3293n.fsf@gnu.org> <878rht7eht.fsf@localhost> <83tu0hidcp.fsf@gnu.org> <87cz745gqp.fsf@localhost> <83y1psglbs.fsf@gnu.org> <87y1pqlpl3.fsf@localhost> <83mt66g2ya.fsf@gnu.org> Date: Wed, 25 Jan 2023 13:43:46 +0000 Message-ID: <87k01alofh.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ruijie Yu writes: >> Talking about "opening the file" again narrows the scope of the >> requested feature, IMO. We don't want to assume that the application >> would like to open the file. Besides, Text mode does affect how Emacs >> treats the file. > > Another thing to consider is when the mode is not activated via > `auto-mode-alist' -- for example, via M-x major-mode. Consider what > happens to the proposed file extension list when "foo.txt" and > "bar.txt.bak.gpg" are manually activated as `org-mode'. That's easy. One can simply check `major-mode' variable value. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at