Gnus development mailing list
 help / color / mirror / Atom feed
From: Reiner Steib <reinersteib+gmane@imap.cc>
To: Harald Hanche-Olsen <hanche@math.ntnu.no>
Cc: <ding@gnus.org>, <bugs@gnus.org>
Subject: Re: Problem running gnus when image is not already loaded
Date: Sat, 02 Feb 2008 14:27:06 +0100	[thread overview]
Message-ID: <v9ve57qyj9.fsf@marauder.physik.uni-ulm.de> (raw)
In-Reply-To: <20080202.121924.157909693.hanche@math.ntnu.no> (Harald Hanche-Olsen's message of "Sat, 02 Feb 2008 12:19:24 +0100 (CET)")

On Sat, Feb 02 2008, Harald Hanche-Olsen wrote:

> Gnus v5.11
> GNU Emacs 23.0.0.2 (i386-unknown-freebsd5.3, X toolkit, Xaw3d scroll bars)
>  of 2005-10-18 on shuttle

When running some CVS snapshot (as 23.0.0 indicates, though I don't
know to which date and branch it belongs), it doesn't make sense to
run a version more than 2 years old.

However, I think you analysis is correct nevertheless.  :-)

> The ultrashort summary:
>
> I usually read usenet news by running:  emacs -f gnus &
> from an xterm.  Once in a rare while, gnus stops with the splash
> screen still up, and the message
>
>   Symbol's value as variable is void: image-load-path
>
> in the minibuffer.
>
> I believe I have narrowed this down to the following code in
> gnus-group-startup-message (irrelevant bits brutally snipped):
>
>   (cond
>    ((and
>      (fboundp 'find-image)
>      (display-graphic-p)
>      (let* ((data-directory ...)
> 	    (image-load-path ...)
> 	    (image (find-image ...)))
>        (when image ...)))))
>
> Assume that image.el[c] has not yet been loaded when this runs.
> Now find-image is autoloaded, so the symbol is fbound.
> We bind image-load-path and call find-image, which tries to
> (defvar load-image-path)
> and that fails because the variable is let-bound.
> Of course gnus-group-startup-message succeeds, but later on
> gnus-mode-line-buffer-identification fails when it tries to put a
> little gnu in the modeline and image-load-path is unbound.
>
> I believe one needs an extra test to be run just after
> (display-graphic-p) in the code above.  Perhaps (require 'image nil t)
> would do, but we don't really want to hard code the location of
> find-image in gnus code?  So I came up with this instead
>
>      (let ((f (symbol-function 'find-image)))
>        (if (consp f)
> 	   (and (eql (car f) 'autoload)
> 		(load (cadr f) nil nil nil t))
> 	 t))
>
> but I'll leave that judgement up to you folks (obviously).

I'm not sure if your or my suggestion (force loading it by adding a
dummy call to `find-image' is preferable.  Opinions?

--8<---------------cut here---------------start------------->8---
--- gnus.el.~7.77.~	2008-01-20 10:27:58.000000000 +0100
+++ gnus.el	2008-02-02 14:21:34.000000000 +0100
@@ -1002,6 +1002,12 @@
   (cond
    ((and
      (fboundp 'find-image)
+     (or
+      ;; Make sure the library defining `image-load-path' is loaded now
+      ;; (`find-image' is autoloaded).  Else, we may get "defvar ignored
+      ;; because image-load-path is let-bound".
+      (find-image '(nil (:type xpm :file "gnus.xpm")))
+      t)
      (display-graphic-p)
      (let* ((data-directory (nnheader-find-etc-directory "images/gnus"))
 	    (image-load-path (cond (data-directory
--8<---------------cut here---------------end--------------->8---

> I have no idea why image is usually, but not always, loaded before
> gnus starts up.  Maybe if I didn't have (tool-bar-mode 0) in my
> .emacs, image would always be loaded.  But I do.
>
> Finally, for your delectation, here is a bit of the hard evidence that
> led me to the conjecture above (the other evidence is from browsing
> source code).  It is a diff between the *Messages* buffer from two
> runs of emacs -f gnus, the first one (marked -) when all is good, and
> the other (marked +) when the bug bit me.
>
> --- gnus-image-load-path-ok	Fri Jan 18 19:20:26 2008
> +++ gnus-image-load-path-not-ok	Sat Feb  2 09:39:32 2008
> @@ -12,21 +12,18 @@
>  Loading tool-bar...done
>  Loading help-fns...done
>  Loading advice...done
> -Loading image...done
> -For information about the GNU Project and its goals, type C-h C-p.
>  Loading gnus...
>  Loading fix-gnus (source)...done
>  Loading gnus...done
>  Loading gnus-start...
>  Loading easymenu...done
>  Loading gnus-start...done
> +Loading image...
> +Warning: defvar ignored because image-load-path is let-bound
> +Loading image...done
>  Loading gnus-agent...
>  Loading fix-gnus-group (source)...done
>  Loading regexp-opt...done
>  Loading gnus-agent...done
>  Reading /local/home/hanche/.newsrc.eld...
> -Reading active file from localhost via nntp...
> -Loading timezone...done
> -No new newsgroups
> -Checking new news...done
> +gnus-mode-line-buffer-identification: Symbol's value as variable is void: image-load-path
>
> - Harald
>
> PS.  I'd appreciate if you Cc'd me on any discussion of this problemm
> on your mailing list.

Done.  Added ding@gnus, MFT set.

Bye, Reiner.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/



       reply	other threads:[~2008-02-02 13:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080202.121924.157909693.hanche@math.ntnu.no>
2008-02-02 13:27 ` Reiner Steib [this message]
2008-02-02 16:03   ` Harald Hanche-Olsen
2008-02-02 17:50     ` Reiner Steib
2008-02-02 17:58   ` Harald Hanche-Olsen
2008-02-02 18:12     ` Reiner Steib

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

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

  git send-email \
    --in-reply-to=v9ve57qyj9.fsf@marauder.physik.uni-ulm.de \
    --to=reinersteib+gmane@imap.cc \
    --cc=Reiner.Steib@gmx.de \
    --cc=bugs@gnus.org \
    --cc=ding@gnus.org \
    --cc=hanche@math.ntnu.no \
    /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 NNTP newsgroup(s).