unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: MON KEY <monkey@sandpframing.com>
Cc: emacs-devel@gnu.org
Subject: Re: locate-library, the NOSUFFIX arg and a [PATCH]
Date: Fri, 22 Jan 2010 10:18:21 -0500	[thread overview]
Message-ID: <jwvsk9ykw7t.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <d2afcfda1001211558y71cfd638r3ff068e0cb1d5389@mail.gmail.com> (MON KEY's message of "Thu, 21 Jan 2010 18:58:15 -0500")

>> 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]


        Stefan




  reply	other threads:[~2010-01-22 15:18 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-19 22:28 locate-library, the NOSUFFIX arg and a [PATCH] MON KEY
2010-01-21 14:08 ` Stefan Monnier
2010-01-21 23:58   ` MON KEY
2010-01-22 15:18     ` Stefan Monnier [this message]
2010-01-23  2:10       ` MON KEY
2010-01-23 11:23         ` Stefan Monnier
2010-01-24  1:39           ` MON KEY
2010-01-25  3:23             ` Stefan Monnier
2010-01-27  4:25               ` MON KEY
2010-01-27 14:55                 ` Stefan Monnier
2010-01-28  1:09                   ` MON KEY
2010-01-28  2:46                     ` Stefan Monnier
2010-01-29  2:55                       ` MON KEY

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=jwvsk9ykw7t.fsf-monnier+emacs@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=emacs-devel@gnu.org \
    --cc=monkey@sandpframing.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).