unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
@ 2014-10-24  6:32 enami tsugutomo
  2014-10-24  8:35 ` Katsumi Yamaoka
  0 siblings, 1 reply; 9+ messages in thread
From: enami tsugutomo @ 2014-10-24  6:32 UTC (permalink / raw)
  To: 18813

Hi,

gnus start (i.e. M-x gnus) fails unless image.el is loaded in advance.
Here is a backtrace (with through cat -v and some sensitive data is
replaced with `...').  It looks like
gnus-mode-line-buffer-identification shadows load-path.

Debugger entered--Lisp error: (file-error "Cannot open load file" "No such file or directory" "image")
  find-image(((:type xpm :file "gnus-pointer.xpm" :ascent center) (:type xbm :file "gnus-pointer.xbm" :ascent center)))
  gnus-mode-line-buffer-identification(("Gnus: %b {nntp:news}"))
  gnus-group-set-mode-line()
  gnus-dribble-enter("")
  gnus-dribble-touch()
  gnus-read-active-for-groups((nnimap "rplaca.sm.sony.co.jp" (nnimap-inbox "INBOX") (nnimap-split-methods (quote nnmail-split-fancy))) ... ((546 qresync nil "mail-lists.nsd-asunaro-sw" qresync)))
  gnus-get-unread-articles(nil nil)
  gnus-setup-news(nil nil nil)
  byte-code("^H\204^N^@	\204^N^@\306 \210\202L^@\307\310!\210\311\n!^S\f\204^^^@^M\203!^@\312 \210\313\314^N^X^H#\210\307\315!\210^N^Y\2036^@\316\317\320\"\210\321 \210\322^N^X!\210\323 \210\324\325!\210\326 \210\307\327!\210\314\207" [dont-connect did-connect gnus-startup-file gnus-current-startup-file gnus-slave gnus-use-dribble-file gnus-group-quit gnus-run-hooks gnus-startup-hook gnus-make-newsrc-file gnus-dribble-read-file gnus-setup-news nil gnus-setup-news-hook gnus-request-create-group "queue" (nndraft "") gnus-start-draft-setup gnus-group-list-groups gnus-group-first-unread-group gnus-configure-windows group gnus-group-set-mode-line gnus-started-hook level gnus-agent] 4)
  gnus-1(nil nil nil)
  gnus(nil)
  funcall-interactively(gnus nil)
  call-interactively(gnus record nil)
  command-execute(gnus record)
  execute-extended-command(nil "gnus")
  funcall-interactively(execute-extended-command nil "gnus")
  call-interactively(execute-extended-command nil nil)
  command-execute(execute-extended-command)




In GNU Emacs 25.0.50.2 (x86_64-unknown-linux-gnu)
 of 2014-10-24 on sigabrt
Repository revision: 118187 monnier@iro.umontreal.ca-20141023214436-ejbbgqri83hnqnmf
System Description:	Ubuntu 14.04.1 LTS

Configured using:
 `configure --with-x=no'

Configured features:
SOUND NOTIFY ZLIB

Important settings:
  value of $LANG: C
  locale-coding-system: nil

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  file-name-shadow-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Recent input:
RET n ESC x l o a d SPC l i RET d e b u g TAB RET ESC 
x s e t SPC v a TAB RET d e b u g - o n SPC e r TAB 
RET t RET ESC x g n u s RET y ESC x l o a d SPC l i 
b TAB RET h e l p - m o d e RET ESC x g n u s RET y 
C-x h ESC w ESC x e DEL r e p o SPC r TAB RET ESC w 
q ESC x r e p o TAB r TAB RET

Recent messages:
Opening connection to rplaca.sm.sony.co.jp...done
nnimap rplaca.sm.sony.co.jp splitting mail...
nnimap read 0k from rplaca.sm.sony.co.jp
nnimap rplaca.sm.sony.co.jp splitting mail...done
Entering debugger...
Mark set [2 times]
Making completion list...
command-execute: Cannot open load file: No such file or directory, emacsbug
Back to top level
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug sendmail help-mode cus-edit cus-start
cus-load debug regexp-opt utf-7 nndraft nnmh rfc2104 network-stream
auth-source cl-macs gv eieio byte-opt bytecomp byte-compile cconv
eieio-core starttls gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 epg-config mm-view mml-smime smime
password-cache dig mailcap nntp gnus-cache gnus-sum gnus-group gnus-undo
gnus-start gnus-cloud nnimap nnmail mail-source tls utf7 netrc nnoo
parse-time gnus-spec gnus-int gnus-range message dired format-spec
rfc822 mml easymenu mml-sec mm-decode mm-bodies mm-encode mail-parse
rfc2231 rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader
gnus-win gnus gnus-ems nnheader gnus-util mail-utils mm-util help-fns
mail-prsvr wid-edit cl-loaddefs cl-lib time-date japan-util tooltip
eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
tabulated-list newcomment elisp-mode lisp-mode prog-mode register page
menu-bar rfn-eshadow timer select mouse jit-lock font-lock syntax
facemenu font-core frame cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese hebrew greek romanian slovak
czech european ethiopic indian cyrillic chinese case-table epa-hook
jka-cmpr-hook help simple abbrev minibuffer nadvice loaddefs button
faces cus-face macroexp files text-properties overlay sha1 md5 base64
format env code-pages mule custom widget hashtable-print-readable
backquote make-network-process inotify multi-tty emacs)

Memory information:
((conses 16 302720 43408)
 (symbols 48 26593 0)
 (miscs 40 91 113)
 (strings 32 39793 4599)
 (string-bytes 1 1274215)
 (vectors 16 18590)
 (vector-slots 8 535542 7646)
 (floats 8 225 313)
 (intervals 56 242 51)
 (buffers 976 23)
 (heap 1024 33799 4482))





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-24  6:32 bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance enami tsugutomo
@ 2014-10-24  8:35 ` Katsumi Yamaoka
  2014-10-26 23:03   ` tsugutomo.enami
  0 siblings, 1 reply; 9+ messages in thread
From: Katsumi Yamaoka @ 2014-10-24  8:35 UTC (permalink / raw)
  To: tsugutomo.enami; +Cc: 18813-done

On Fri, 24 Oct 2014 15:32:23 +0900, enami tsugutomo wrote:
> gnus start (i.e. M-x gnus) fails unless image.el is loaded in advance.
> Here is a backtrace (with through cat -v and some sensitive data is
> replaced with `...').  It looks like
> gnus-mode-line-buffer-identification shadows load-path.

Enami-san, thanks for tracking it down.  I've changed the function
in question as follows:

--- a/lisp/gnus.el
+++ b/lisp/gnus.el
@@ -326,7 +326,7 @@ be set in `.emacs' instead."
   (if (fboundp 'find-image)
       (defun gnus-mode-line-buffer-identification (line)
 	(let ((str (car-safe line))
-	      (load-path (mm-image-load-path)))
+	      (load-path (append (mm-image-load-path) load-path)))
 	  (if (and (stringp str)
 		   (string-match "^Gnus:" str))
 	      (progn (add-text-properties

I think it would not be a matter even if it causes finding another
gnus-pointer.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-24  8:35 ` Katsumi Yamaoka
@ 2014-10-26 23:03   ` tsugutomo.enami
  2014-10-27  0:28     ` Katsumi Yamaoka
  0 siblings, 1 reply; 9+ messages in thread
From: tsugutomo.enami @ 2014-10-26 23:03 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: 18813-done

Hi,

I wonder why it works for other people for a while and found
gnus-group-startup-message forces find-image to be loaded when
necessary.

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Enami-san, thanks for tracking it down.  I've changed the function
> in question as follows:
>
> --- a/lisp/gnus.el
> +++ b/lisp/gnus.el
> @@ -326,7 +326,7 @@ be set in `.emacs' instead."
>    (if (fboundp 'find-image)

So, I guess alternative way is changing the above test to (and (fboundp
'find-image) (display-graphic-p)) like gnus-group-startup-message does.

I'm not sure which one is better.

enami.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-26 23:03   ` tsugutomo.enami
@ 2014-10-27  0:28     ` Katsumi Yamaoka
  2014-10-27  1:57       ` tsugutomo.enami
  2014-10-27  3:41       ` Eli Zaretskii
  0 siblings, 2 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2014-10-27  0:28 UTC (permalink / raw)
  To: tsugutomo.enami; +Cc: 18813-done

On Mon, 27 Oct 2014 08:03:15 +0900, tsugutomo.enami@jp.sony.com wrote:
> I wonder why it works for other people for a while and found
> gnus-group-startup-message forces find-image to be loaded when
> necessary.
[...]
> So, I guess alternative way is changing the above test to (and (fboundp
> 'find-image) (display-graphic-p)) like gnus-group-startup-message does.

> I'm not sure which one is better.

Well, I have another doubt.  Did you mean image.elc is not loaded
only if the display type is not graphical?  Does the error happen
in both 24.0.50 (you seem to use) and 25.0.50 (labeled in the bug
subject)?
Currently I can test it with only 24.3 and 25.0.50, and find-image
is fully available in both the versions with the -Q option no
matter what the display type is, and even in the batch mode.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-27  0:28     ` Katsumi Yamaoka
@ 2014-10-27  1:57       ` tsugutomo.enami
  2014-10-27  3:31         ` Katsumi Yamaoka
  2014-10-27  3:41       ` Eli Zaretskii
  1 sibling, 1 reply; 9+ messages in thread
From: tsugutomo.enami @ 2014-10-27  1:57 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: 18813-done

Katsumi Yamaoka <yamaoka@jpl.org> writes:

> Well, I have another doubt.  Did you mean image.elc is not loaded
> only if the display type is not graphical?

Loading image.el won't fail and it works.  I wonder if it is really
necessary to setup image when display is not capable of displaying it.

> Does the error happen in both 24.0.50 (you seem to use) and 25.0.50
> (labeled in the bug subject)?

# 24.0.50 is currentl my main mail environment.  As I was asked to
# prepare patch against emacs trunk in bug#18728, I've prepared 25.0.50
# on temporary machine and found this bug#18813 while testing on it.

This bug#18813 doesn't occur on 24.0.50, since image.el is loaded while
gnus-art.el is loaded (gnus-image-type-available-p defined in
gnus-ems.el calls image-type-available-p).

On 25.0.50, tests in gnus-image-type-available-p are reordered and now
control returns before calling image-type-available-p when
display-images-p returns nil (it is in my case).  So, image.el is not
loaded.

Hmm, why are they reordered?  I guess it is to avoid loading unnecessary
library.

enami.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-27  1:57       ` tsugutomo.enami
@ 2014-10-27  3:31         ` Katsumi Yamaoka
  2014-10-27  3:52           ` Katsumi Yamaoka
  0 siblings, 1 reply; 9+ messages in thread
From: Katsumi Yamaoka @ 2014-10-27  3:31 UTC (permalink / raw)
  To: tsugutomo.enami; +Cc: 18813

On Mon, 27 Oct 2014 10:57:54 +0900, tsugutomo.enami@jp.sony.com wrote:
> Katsumi Yamaoka <yamaoka@jpl.org> writes:

>> Well, I have another doubt.  Did you mean image.elc is not loaded
>> only if the display type is not graphical?

> Loading image.el won't fail and it works.  I wonder if it is really
> necessary to setup image when display is not capable of displaying it.

I see.  The image data are definitely unnecessary for a non-graphic
display, so I'll add (display-graphic-p) to the tests.

> This bug#18813 doesn't occur on 24.0.50, since image.el is loaded while
> gnus-art.el is loaded (gnus-image-type-available-p defined in
> gnus-ems.el calls image-type-available-p).

Thank you for clarifying this.

> On 25.0.50, tests in gnus-image-type-available-p are reordered and now
> control returns before calling image-type-available-p when
> display-images-p returns nil (it is in my case).  So, image.el is not
> loaded.

> Hmm, why are they reordered?  I guess it is to avoid loading unnecessary
> library.

2013-06-06  Teodor Zlatanov  <tzz@lifelogs.com>

	* gnus-ems.el (gnus-image-type-available-p): Test `display-images-p'
	before `image-type-available-p' to avoid loading the image libraries
	needlessly.

This is just the cause of your problem (it does not mean Ted's
change was wrong, of course).

In addition, my doubt about loading image.elc was cleared.

,---- loadup.el
| (if (fboundp 'x-create-frame)
|     (progn
|       (load "fringe")
|       ;; Needed by `imagemagick-register-types'
|       (load "emacs-lisp/regexp-opt")
|       (load "image")
|       (load "international/fontset")
|       (load "dnd")
|       (load "tool-bar")))
`----

This is why find-image is always available in my system.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-27  0:28     ` Katsumi Yamaoka
  2014-10-27  1:57       ` tsugutomo.enami
@ 2014-10-27  3:41       ` Eli Zaretskii
  2014-10-27  3:56         ` Katsumi Yamaoka
  1 sibling, 1 reply; 9+ messages in thread
From: Eli Zaretskii @ 2014-10-27  3:41 UTC (permalink / raw)
  To: Katsumi Yamaoka; +Cc: tsugutomo.enami, 18813

> Date: Mon, 27 Oct 2014 09:28:03 +0900
> From: Katsumi Yamaoka <yamaoka@jpl.org>
> Cc: 18813-done@debbugs.gnu.org
> 
> Currently I can test it with only 24.3 and 25.0.50, and find-image
> is fully available in both the versions with the -Q option no
> matter what the display type is, and even in the batch mode.

The OP built Emacs --without-x, in which case image.el is not
preloaded, and the support code is missing.

Try configuring --without-x.





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-27  3:31         ` Katsumi Yamaoka
@ 2014-10-27  3:52           ` Katsumi Yamaoka
  0 siblings, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2014-10-27  3:52 UTC (permalink / raw)
  To: tsugutomo.enami; +Cc: 18813

On Mon, 27 Oct 2014 12:31:01 +0900, Katsumi Yamaoka wrote:
> I see.  The image data are definitely unnecessary for a non-graphic
> display, so I'll add (display-graphic-p) to the tests.

I've added it within the gnus-mode-line-buffer-identification
function, since it should return image data when it is called in
a graphic display even if Gnus starts in a non-graphic display.

--- a/lisp/gnus.el
+++ b/lisp/gnus.el
@@ -327,7 +327,8 @@ be set in `.emacs' instead."
       (defun gnus-mode-line-buffer-identification (line)
 	(let ((str (car-safe line))
 	      (load-path (append (mm-image-load-path) load-path)))
-	  (if (and (stringp str)
+	  (if (and (display-graphic-p)
+		   (stringp str)
 		   (string-match "^Gnus:" str))
 	      (progn (add-text-properties
 		      0 5





^ permalink raw reply	[flat|nested] 9+ messages in thread

* bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance.
  2014-10-27  3:41       ` Eli Zaretskii
@ 2014-10-27  3:56         ` Katsumi Yamaoka
  0 siblings, 0 replies; 9+ messages in thread
From: Katsumi Yamaoka @ 2014-10-27  3:56 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: tsugutomo.enami, 18813

On Mon, 27 Oct 2014 05:41:02 +0200, Eli Zaretskii wrote:
>> Currently I can test it with only 24.3 and 25.0.50, and find-image
>> is fully available in both the versions with the -Q option no
>> matter what the display type is, and even in the batch mode.

> The OP built Emacs --without-x, in which case image.el is not
> preloaded, and the support code is missing.

> Try configuring --without-x.

Thanks.  It's been already cleared.





^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2014-10-27  3:56 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-10-24  6:32 bug#18813: 25.0.50; gnus start fails unless image.el is loaded in advance enami tsugutomo
2014-10-24  8:35 ` Katsumi Yamaoka
2014-10-26 23:03   ` tsugutomo.enami
2014-10-27  0:28     ` Katsumi Yamaoka
2014-10-27  1:57       ` tsugutomo.enami
2014-10-27  3:31         ` Katsumi Yamaoka
2014-10-27  3:52           ` Katsumi Yamaoka
2014-10-27  3:41       ` Eli Zaretskii
2014-10-27  3:56         ` Katsumi Yamaoka

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).