GNU bug report logs -
#60929
30.0.50; [FR] `file-name-extension' and backup suffixes
Previous Next
Full log
Message #26 received at 60929 <at> debbugs.gnu.org (full text, mbox):
> 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.