unofficial mirror of help-gnu-emacs@gnu.org
 help / color / mirror / Atom feed
From: Tim X <timx@nospam.dev.null>
To: help-gnu-emacs@gnu.org
Subject: Re: test for presence of library
Date: Sat, 20 Feb 2010 12:09:51 +1100	[thread overview]
Message-ID: <878wao67c0.fsf@lion.rapttech.com.au> (raw)
In-Reply-To: mailman.1516.1266618008.14305.help-gnu-emacs@gnu.org

Harry Putnam <reader@newsguy.com> writes:

> pjb@informatimago.com (Pascal J. Bourguignon) writes:
>
> [...]
>
>  Harry wrote:
>>> The lisp equivalent of:
>>>
>>>  if some-lib 
>>>  then
>>>     (require some-lib)
>>>  fi
>>
>>
>> require does the test itself!
>>
>> C-h f require RET
>>
>>
>> Now, assume that we wrote:
>>
>> (when (library-exists-p 'some-lib)
>>    (require 'some-lib))
>>
>> and that just after your emacs executed (library-exists-p 'some-lib)
>> and returned true, some other process would delete that some-lib.el
>> file.  What would happen to your (require 'some-lib)?
>>
>>
>> That is, basically, your above shell script with if [ -f /my/file ] is
>> just WRONG!  If you see such tests in scripts, you are allowed to think
>> poorly of their authors.
>
> Don't hold back, in this case you are allowed and really forced to
> think poorly of the author who admits to having literally hundreds of
> such tests scattered thru a 10yr accumulation of various scripts in
> various scripting languages. 
>
> I'm a known dimwit... its even ok to use the `R' word... I doubt (Sarah
> Palin reads this group)
>
> It's ok, I've learned to live with it.
>
> Now lets assume further that we instead say simply:
>
>    (require 'some-lib)
>
> After patting myself on the back for such a wise solution to getting a
> needed library loaded, I move to a different and new machine where I've
> carted my every ready .emacs file with me.
>
> I start emacs with `emacs /some/path/file'.... but whoops, since
> `some-lib' is not in the path in this environment... my emacs blows up
> a bit.  It throws up a confusing buffer full of various leads to
> information, but none of it appears to bear directly on the job at
> hand. .. Not even any indication of what the problem is.
>
> I finally noticed at the bottom, a place to dismiss this interruption
> and get back to work.
>
> I'd like to avoid that even though its not really an earth shaking
> problem.
>
> My first thought, being a dunce and all, was to test for the presence
> of the library before requiring it, thereby smoothing out the work
> flow and interruptions. I wasn't sure how that would be done, hence
> the question here.
>
> But looking at the suggested documentation I'm left non the wiser:
>
>  (require FEATURE &optional FILENAME NOERROR)
>
> That isn't going to get it for me.. I've tried a few arrangements but
> being an idiot and all, I have no idea how something optional is
> introduced into the require.
>
> What do you recommend to a simpleton regarding how to avoid the
> interruption?  Just make sure all is perfect before starting emacs?
>
> Or maybe spend a day or two figuring out how to apply the codified
> documentation.... again... thats' a hard pull for the intellectually
> crippled.
>

Maybe consider the issue form a slightly different perspective. 

You can have two scenarios when it comes to loading a library

1. If the library is not found, throw an error and let the user deal
with it. The advantage of this approach is that you can be confident
that if no error is thrown, you the library has been loaded and the
features it provides are available. The disadvantage is that if an error
is thrown, the user has to take some action, which may be as simple as
telling emacs to ignore the error and continue. Unfortunately, further
errors could arise when something in your .emacs tries to use the
feature that would have been available if the library had loaded
successfully. 

2. Tell emacs to try and load the library, but don't throw any error if
it fails. This has the advantage that the user does not have to take any
action when emacs can't load the library. However, unless other
precautions are taken, you may get errors further along when emacs tries
to use a feature associated with that library. 

From what you have written, I'm assuming you currently have the first
situation, but would like something more like the second situation. 

both approaches can be handled using require and the predicate featurep. 

The require directive takes an optional second argument 'noerror'. If
you have 

(require 'mylib nil t)

emacs will not throw an error if it fails to find the library 'mylib.
This will give you the first part of a solution outlined in scenario 2.
However, you may still get an error thrown if later lines in your .emacs
try to use a feature that is associated with that library which is not
available. What we need to do is only try to use the feature if the
library was successfully loaded. 

If you look at most libraries, you will find, usually at the end, a line
such as 

(provide 'mylib)

This tells emacs that the feature 'mylib has been loaded. this has two
benefits,.

1. If you have multiple 'require' lines for the same library, it will
only be loaded once as require checks to see if the feature has already
been 'provided'.

2. You can use the featurep predicate to test and see if a library has
been loaded. 

So, the second part of the solution is to ensure that any config or
commands that use features provided by a library always test to see if
that feature has been loaded before trying to use it. 

Yo would end up with something like 

(require 'mylib nil t)
...
...
...
(when (featurep 'mylib) 
      (do-something-using-mylib)
      (do-another-thing-using-mylib))

Whith these two lines, you can use the same .emacs file on different
machines wherre one has the library and one does not and you won't get
bothered with errors at startup. Of course, you could still get errors
when using emacs if you try to use a feature associated with the library
that isn't available, but at least you won't get emacs stalling when it
tries to load.

HTH

Tim




-- 
tcross (at) rapttech dot com dot au


  parent reply	other threads:[~2010-02-20  1:09 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <mailman.1463.1266533787.14305.help-gnu-emacs@gnu.org>
2010-02-19  1:09 ` test for presence of library Pascal J. Bourguignon
2010-02-19 22:19   ` Harry Putnam
2010-02-19 23:12     ` Dirk-Jan C. Binnema
     [not found]   ` <mailman.1516.1266618008.14305.help-gnu-emacs@gnu.org>
2010-02-20  1:09     ` Tim X [this message]
2010-02-20  9:54     ` Pascal J. Bourguignon
     [not found]   ` <slrnho35vq.493.oudeis@nephthys.thalatta.eme>
2010-02-22  1:58     ` Pascal J. Bourguignon
2010-02-25 18:59       ` Harry Putnam
     [not found]       ` <mailman.1877.1267124412.14305.help-gnu-emacs@gnu.org>
2010-02-25 20:17         ` Pascal J. Bourguignon
2010-02-26 20:21           ` Harry Putnam
2010-02-18 22:56 Harry Putnam
2010-02-18 23:10 ` Lennart Borgman

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=878wao67c0.fsf@lion.rapttech.com.au \
    --to=timx@nospam.dev.null \
    --cc=help-gnu-emacs@gnu.org \
    /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.
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).