image-load-path / tool-bar icons / dumped Emacs with images.el

image-load-path / tool-bar icons / dumped Emacs with images.el

[David Reitter]

I have an issue with image-load-path, defined in images.el.

Since the tool-bar images have been moved to data-directory/images,  
my Emacs can't find the icons any more.
The reason is that I am precompiling image.el into a dumped binary,  
and when that happens, image-load-path gets initialized. At run-time,  
the data-directory is somewhere else, however.

Before the tool-bar icons were moved, this didn't matter too much,  
since I had lisp/toolbar in the load-path (maybe because it's a  
subdir of lisp).

Of course, I can add the new location to the load-path now, but I  
think the better solution would be if image-load-path would be  
initialized at run-time, or if there was some flexible way of  
specifying something like '(load-path "/images") in image-load-path.


> (defvar image-load-path
>   (list (file-name-as-directory (expand-file-name "images" data- 
> directory))
>     'data-directory 'load-path)
>   "List of locations in which to search for image files.
> If an element is a string, it defines a directory to search.
> If an element is a variable symbol whose value is a string, that
> value defines a directory to search.
> If an element is a variable symbol whose value is a list, the
> value is used as a list of directories to search.")

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Richard M. Stallman]

    Of course, I can add the new location to the load-path now, but I  
    think the better solution would be if image-load-path would be  
    initialized at run-time, or if there was some flexible way of  
    specifying something like '(load-path "/images") in image-load-path.

I think initializing the default at run time would be a good
solution.  It doesn't make the usage of the feature any more
complicated.

The natural place to do it is in startup.el.  To make this cleaner, we
could add a facility called `at-startup' which would record a list of
expressions to be executed at startup, but do them immediately if
after startup.

(defmacro at-startup (&rest body)
  `(if too-late-already
       (progn . ,body)
     (setq before-init-hook
           (nconc before-init-hook ',(copy-sequence body))))
  nil)

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Kim F. Storm]

"Richard M. Stallman" <rms@gnu.org> writes:

> (defmacro at-startup (&rest body)
>   `(if too-late-already
>        (progn . ,body)
>      (setq before-init-hook
>            (nconc before-init-hook ',(copy-sequence body))))
>   nil)

Maybe we can avoid having another variable if we do:

(defmacro at-startup (&rest body)
  `(if (eq before-init-hook t)
       (progn . ,body)
     (setq before-init-hook
	   (nconc before-init-hook ',(copy-sequence body))))
  nil)

and set before-init-hook to t after it has been run.


This gives me a new idea:

In general, maybe we could set "run-once" hook variables to t after
they have run, and signal an error if someone tries to modify a hook
which is t.  

That might catch some user errors, and I don't see how it can harm.

Also, it would free up the value of those hooks.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Stefan Monnier]

> In general, maybe we could set "run-once" hook variables to t after
> they have run, and signal an error if someone tries to modify a hook
> which is t.

Sounds like a good idea.  But I'm wondering how many such hooks exist and
what happens to code that checks (eq foo-hook t) when Emacs changes cause
the hook to not be t any more because it may be run again later (I'm
thinking of things like term-setup-hook which currently can only be run
once but which may be run several times once we add multi-tty).


        Stefan

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Kim F. Storm]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> In general, maybe we could set "run-once" hook variables to t after
>> they have run, and signal an error if someone tries to modify a hook
>> which is t.
>
> Sounds like a good idea.  But I'm wondering how many such hooks exist and
> what happens to code that checks (eq foo-hook t) when Emacs changes cause
> the hook to not be t any more because it may be run again later (I'm
> thinking of things like term-setup-hook which currently can only be run
> once but which may be run several times once we add multi-tty).

Ok, so we have to think carefully before setting a hook to t.
But in any case, such _errors_ only need to be found once :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Richard M. Stallman]

    This gives me a new idea:

    In general, maybe we could set "run-once" hook variables to t after
    they have run, and signal an error if someone tries to modify a hook
    which is t.  

    That might catch some user errors, and I don't see how it can harm.

It could be a good idea.  But I'd rather save that for after the release.

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[David Reitter]

On 21 Oct 2005, at 08:30, Kim F. Storm wrote:
>
> Maybe we can avoid having another variable if we do:
>
> (defmacro at-startup (&rest body)
>   `(if (eq before-init-hook t)
>        (progn . ,body)
>      (setq before-init-hook
>        (nconc before-init-hook ',(copy-sequence body))))
>   nil)
>
> and set before-init-hook to t after it has been run.

OK, so the current solution initializes image-load-path correctly at  
run-time.
However, because it doesn't do so before (tool-bar-mode 1) is called  
(startup.el, line 765) for the first time, tool-bar-setup cannot load  
any images from their locations, so the tool-bar remains empty.

That is, only when you preload image.el into the dump. If you don't -  
as in the default compile - then image.el gets autoloaded at runtime  
and the image-load-path is set early enough for tool-bar-setup to  
find the images.

Maybe it would help to move (run-hooks 'before-init-hook) up before  
(frame-initialize) ?

Re: image-load-path / tool-bar icons / dumped Emacs with images.el

[Richard M. Stallman]

    Maybe it would help to move (run-hooks 'before-init-hook) up before  
    (frame-initialize) ?

That seems like a good idea.  I checked all uses of before-init-hook,
and it looks like they will work with this.

Meanwhile, it seems to me that we should preload image, and toolbar,
on systems that will use them by default.  I took care of that
and various other files that should be preloaded.  There's a bad
connection here now so I was unable to check it all in.