bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Ihor Radchenko <yantar92@posteo.net> 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

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> 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.

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> Cc: 60929@debbugs.gnu.org
> Date: Wed, 18 Jan 2023 14:47:14 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > 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.

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 60929@debbugs.gnu.org
> Date: Wed, 18 Jan 2023 13:01:51 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> 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?

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 60929@debbugs.gnu.org
> Date: Tue, 24 Jan 2023 11:12:56 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Eli Zaretskii]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: 60929@debbugs.gnu.org
> Date: Wed, 25 Jan 2023 13:18:48 +0000
> 
> Eli Zaretskii <eliz@gnu.org> 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.

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ruijie Yu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Ihor Radchenko <yantar92@posteo.net>
>> Cc: 60929@debbugs.gnu.org
>> Date: Wed, 25 Jan 2023 13:18:48 +0000
>>
>> Eli Zaretskii <eliz@gnu.org> 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

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Eli Zaretskii <eliz@gnu.org> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes

[Ihor Radchenko]

Ruijie Yu <ruijie@netyu.xyz> 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 <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>