GNU bug report logs - #41242
Port feature/native-comp to Windows

Previous Next

Package: emacs;

Reported by: Nicolas Bértolo <nicolasbertolo <at> gmail.com>

Date: Wed, 13 May 2020 19:28:01 UTC

Severity: wishlist

Done: Andrea Corallo <akrl <at> sdf.org>

Bug is archived. No further changes may be made.

Full log


Message #425 received at 41242 <at> debbugs.gnu.org (full text, mbox):

From: Andrea Corallo <akrl <at> sdf.org>
To: Nicolas Bértolo <nicolasbertolo <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 41242 <at> debbugs.gnu.org
Subject: Re: 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
Nicolas Bértolo <nicolasbertolo <at> 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 <at> sdf.org




This bug report was last modified 5 years and 41 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.