bug#17467: 24.3; locate-library returning spurious path

[Alex Kosorukoff]

On Sun, May 11, 2014 at 3:55 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> Yes, this makes sense. Here is a patch that the issues you mentioned.

I'm still not sure which situations you want to exclude, so it's hard to
judge whether your patch does do it...

I exclude anything that is not ending with .el, .elc, .el.gz, or .elc.gz, for example, my patch won't return any files that have no extension and will not return files that have only .gz that is not preceded by el or elc. Otherwise, the latest patch works the same way as the original locate-library

> +         (locate-file library
> +                      (or path load-path)
> +                      (unless (or nosuffix (string-suffix-p ".el.gz" library))

...but special casing ".el.gz" is definitely not a good idea.  Why would
it need special treatment?
It's extremely rare for `library' to end in ".el.gz" here.

This is because if a user specified .el.gz already, we shouldn't try to extend it by appending extra suffixes, e.g. looking for .el.gz.el, el.gz.elc or .el.gz.gz, none of those suffixes can't possibly result in valid library names. If a user specified only .el or .elc, then we still can have two options for suffixes ("", ".gz"). If none of the known suffixes were specified, we have four options produced by  (get-load-suffixes). BTW, this was not the last patch, it won't apply to older emacs versions and also not handling .elc.gz (which should not be extended just like .el.gz). My last patch is using string-match.

 

        Stefan