> Oh, right. So the docstring should be fixed to make it clear that the
> argument should be an *absolute* file name.
Uh? convert-standard-filename works right with non-absolute paths:
(convert-standard-filename "file/test:.dat") => "file\\test!.dat"
It just handles an initial "X:" differently (on Windows):
(convert-standard-filename "c:file/test:.dat") => "c:file\\test!.dat"
I see nothing wrong with convert-standard-filename or its docstring.
AFAICS, the problem is that convert-standard-filename is intended to
transform a filename into another filename, suitable for the current
filesystem. But what you're trying in the code you proposed is using
convert-standard-filename to build the *name* part of a filename.
There's nothing anywhere that guarantees that a filename (with path
etc) is a valid name for a file. In MS-DOS/Windows you've got the ":",
in VMS the brackets, etc. When you concatenate thumbs-thumbsdir with
the output of convert-standard-filename, the result can perfectly be a
non-valid filename.
So you'll have to use convert-standard-filename, and then filter its
output to remove potentially dangerous characters, or, as I did in my
example, use convert-standard-filename as the last pass:
(convert-standard-filename (concat thumbs-thumbsdir "/"
(subst-char-in-string [etc...])
I don't think the trouble is worth the tiny benefit that the filename
of the cached thumbnail is user-friendly on debugging. If someone has
to debug it he can modify thumbs-thumbname easily enough.
--
/L/e/k/t/u
_______________________________________________
Emacs-devel mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-devel
