Re: XEmacs 20.4: find-function-noselect
On Wed, May 13, 1998 at 12:42:48PM +0900, Stephen J. Turnbull wrote:
>>>>> "juhp" == Jens-Ulrik Petersen
<petersen(a)kurims.kyoto-u.ac.jp> writes:
juhp> A leading dot should never be considered to be an extension
juhp> separator. I can't think of any example where
juhp> (file-name-sans-extension ".file") => "" would be
useful.
But I can think of a case where the Scheme semantics can be dangerous.
If you take the name literally, you would think you could safely
delete all files whose full name is (file-name-sans-extension ".emacs"
file). I would personally prefer that by default stripping ".emacs"
from ".emacs" not result in ".emacs".
The crux of the problem is "what is an extension ?". There are two
competing definitions:
- whatever lies after the last '.'
- the part of the name after '.' that describes the type of the file
Broken as it is, the second version is the usual one. It has been the
habit on all 8.3 filesystems[1] and nowadays on Unix half of the
utilities uses file(1) for types, and the other half the
extensions[2]. The only filesystems with real type information that I
know of are the BeOS and MacOS ones.
If we decide to go for the second definition, which follows the
principle of least astonishment, .-files should be untouched by the
extension stripping since they usually don't have any type information
in the name. So .emacs.emacs should stay that way.
Whether blah.tar.gz has one or two extensions is Yet Another
Problem[tm].
OG.
[1] This includes my good old Oric-1 with floppy extension and Atari
1040STF, all CP/M thingies and everything derived from MS-DOS
[2] For instance the HPvue (ancestor of CDE) file manager uses file
extensions, while the SGI's version uses file(1). Welcome to the joys
of Unix.
[tm] This is not a footnote.