bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#41242: Port feature/native-comp to Windows - Reduce the number of fi


From: Andrea Corallo
Subject: bug#41242: Port feature/native-comp to Windows - Reduce the number of files probed when finding a lisp file.
Date: Tue, 02 Jun 2020 14:43:14 +0000
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux)

Nicolas Bértolo <nicolasbertolo@gmail.com> writes:

>> In which folders are we going to search if we do (load "...a/path/foo.eln")?
>
>> I believe in this case we should search the file only in "...a/path/"
>> because the user really want to load this specific file.  Am I correct?
>
> I'm not sure we want the load function to be that smart. This is from
> the manual:
>
> -----
> The load function is not clever about looking at filename. In the perverse 
> case
> of a file named foo.el.el, evaluation of (load "foo.el") will indeed find it.
> -----
>
> I think we should respect that principle when dealing with .eln files, even if
> it leads to trying to open absurd filenames.

Mmmh you are maybe right, but the directory and the filename are two
different things, I've to think about it.  I'd be curious of other
opinions.

> I did some tests, and these are the files probed in each case:
>
> (load "dir/foo.eln")
>
> "{elt}/dir/foo.eln.eln"
> "{elt}/dir/eln-hash/foo.eln.eln"
> "{elt}/dir/foo.eln.dll"
> "{elt}/dir/foo.eln.elc"
> "{elt}/dir/foo.eln.elc.gz"
> "{elt}/dir/foo.eln.el"
> "{elt}/dir/foo.eln.el.gz"
> "{elt}/dir/foo.eln"
> "{elt}/dir/foo.eln.gz"
>
> where {elt} is an element from `load-path`.
>
> (load "C:/dir/foo.eln")
>
> "c:/dir/foo.eln.eln"
> "c:/dir/eln-hash/foo.eln.eln"
> "c:/dir/foo.eln.dll"
> "c:/dir/foo.eln.elc"
> "c:/dir/foo.eln.elc.gz"
> "c:/dir/foo.eln.el"
> "c:/dir/foo.eln.el.gz"
> "c:/dir/foo.eln"
> "c:/dir/foo.eln.gz"
>
> (load "dir/foo.eln" nil nil t) <- nosuffix: t
>
> "{elt}/dir/foo.eln"
>
> (load "C:/dir/foo.eln" nil nil t) <- nosuffix: t
>
> "C:/dir/foo.eln"
>
>> That said IMO this logic is sufficiently complex to deserve a minimum of
>> testing to make sure we have it under control.  Not sure if the best
>> place is files-tests.el or comp-tests.el.
>
> I agree about this. I am not sure what is the best way to do it. The list of
> files probed is inaccessible from Lisp.

Yes but we can always compile a file and load it to see what's inside,
this is what we do in comp-tests.el, technically is not a problem if we
think is necessary.

  Andrea

-- 
akrl@sdf.org





reply via email to

[Prev in Thread] Current Thread [Next in Thread]