Re: XEmacs 20.4: find-function-noselect

OG> The crux of the problem is "what is an extension ?". There OG> are two competing definitions: - whatever lies after the last OG> '.' - the part of the name after '.' that describes the type OG> of the file OK. OG> Broken as it is, the second version is the usual one. It has OG> been the habit on all 8.3 filesystems[1] and nowadays on Unix OG> half of the utilities uses file(1) for types, and the other OG> half the extensions[2]. The only filesystems with real type OG> information that I know of are the BeOS and MacOS ones. Unix utilities usually use this type information as heuristics to give visual feedback to users, eg, in directory listing colorization. Shell globbing (Bash 2.00.0(1)-release on Linux) gives a null expansion to ~/*.emacs (the only thing in my ~ that could plausibly match is `.emacs' itself), which supports the Scheme intuition. However, this is quite slippery to apply to a programming language. It's not clear to me that the heuristic for an interactive interface is a good analogy for API design. Again looking at shells, Bash at least has a large number of operators for doing exactly the kind of manipulation that we are discussing here for variable expansion and munging. So it's not clear to me what the principle of least astonishment really says about this. Maybe we should be replicating Bash's suite of `%', `%%', `#', `##' operators with their various exception handling mechanisms? (This is pure devil's advocacy on my part, although I do not promise to die of astonishment if it against all odds turns out to be a good idea.)