bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Eli Zaretskii
Subject: bug#60929: 30.0.50; [FR] `file-name-extension' and backup suffixes
Date: Wed, 18 Jan 2023 16:47:08 +0200

> 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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]