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

Previous Next

Package: emacs;

Reported by: Ihor Radchenko <yantar92 <at> posteo.net>

Date: Wed, 18 Jan 2023 10:50:01 UTC

Severity: normal

Found in version 30.0.50

Full log


View this message in rfc822 format

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ihor Radchenko <yantar92 <at> posteo.net>
Cc: 60929 <at> debbugs.gnu.org
Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes
Date: Mon, 23 Jan 2023 15:34:30 +0200
> From: Ihor Radchenko <yantar92 <at> posteo.net>
> Cc: 60929 <at> 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?




This bug report was last modified 2 years and 142 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.