[Top][All Lists]

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

Re: locate-library, the NOSUFFIX arg and a [PATCH]

From: Stefan Monnier
Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH]
Date: Fri, 22 Jan 2010 10:18:21 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1.91 (gnu/linux)

>> This is poorly worded but means that it will not only look for files
>> of the form DIR/FILE.SUFFIX but also for DIR/FILE (i.e. it will add the
>> empty string as a valid suffix).

> A) It doesn't do that now.

What makes you think so?

> B) If the empty string is a valid suffix then all strings are
> potentially valid library suffixes.

What makes you think so?

> Regardless, you've ignored the second portion of the docs which
> negates _your_ interpretation above, and have neglected to explain or
> address my initial query:

>  "Aren't these two statements mutually exclusive?"

I did explain it, tho obvious you didn't understand it.

> o If NOSUFFIX is nil - omit the suffix

No: if NOSUFFIX is nil, also include the empty suffix.

> o If NOSUFIX is non-nil don't add suffixes `load-suffixes'.
> What other suffixes are there other than `load-suffixes'?

The empty suffix.

> The docs don't explicitly mention that the values of `load-file-rep-suffixes',
> and `get-load-suffixes' _also_ affect the return value.

> load-suffixes
> => (".elc" ".el")

> (locate-library "subr")
> => "{...}/emacs/lisp/subr.elc"

> (locate-library "subr" t)
> => nil

> Again, according to the docs the `t' arg should elide ".elc" and ".el"
> suffixes.

Again, no, because this argument describes which extensions might be
added to the provided string in order to find a file name.  None of the
file name's suffixes are ever removed by locate-library.

[Stopped reading at this point, sorry]


reply via email to

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