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

[Alex Kosorukoff <alex@3form.com>]

[-- Attachment #1: Type: text/plain, Size: 1510 bytes --]

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

> > variant matched tramp.el.old which is not a valid library name.
>
> Who cares?  The point is that if the user asks to load foo.el.old, we
> should consider load-file-rep-suffixes, whereas for "foo" we shouldn't.
> I'm not particularly worried about finding files with name "foo.el.old.el".


Do you mean we need this shortcut due to some performance considerations? I
am not sure why else we would want a partial solution when we can have a
complete one. In my opinion we should only consider load-file-rep-suffixes
if the name matches \\.elc?\\' (the difference is the end of string
marker), so foo.el and foo.el.old.el are both ok to extend with .gz, but
foo.el.old and foo shouldn't be extended. Am I missing something?

> +          (unless nosuffix
> > +            (if (string-match "\\.elc?\\(\\.gz\\)?\\'" library)
>
> I don't want to hardcode "gz" here.  We have load-file-rep-suffixes for
> that.
>

Yes, you are right, .gz shouldn't be hardcoded. Though I am not sure if
allowing anything there is ok. Maybe we can just use (sring-match (concat
"\\.elc?\\(" (regexp_opt load-file-rep-suffixes) "\\)\\'") library)?


>
> > +                (if (= 2 (length (match-data))) load-file-rep-suffixes)
> > +              (get-load-suffixes))))))
>
> If you only use (get-load-suffixes) that will fail when we (load
> "~/.gnus").
> My check for absolute-file-name-p was not an optimization.
>

Got it.

        Stefan
>

[-- Attachment #2: Type: text/html, Size: 2851 bytes --]