New GNOME icons

New GNOME icons

[Bill Wohler]

The Gnus team have updated their icons from GNOME 2.6. Previously, all
of their images were in the etc/images/gnus directory. We (the Gnus and
MH-E teams) have worked together to share more of these images to
provide a more unified user experience. That means that a number of
those images will move from the Gnus sub-directory and move into the
top-level etc/images directory or mail sub-directory where they will
also be available to other Emacs developers.

I've enclosed the Gnus README which documents the icons we propose to
update or add to the Emacs CVS repository. The GNOME names are in
parenthesis. If you would like to comment on these before we check them
in, please do!

	----- README follows -----
The following icons are from GNOME 2.6:

    attach.xpm (stock_attach)
    connect.xpm (stock_connect)
    contact.xpm (stock_contact)
    delete.xpm (stock_delete)
    describe.xpm (stock_properties)
    disconnect.xpm (stock_disconnect)
    exit.xpm (stock_exit)
    lock-broken.xpm (stock_lock_broken)
    lock-ok.xpm (stock_lock_ok)
    lock.xpm (stock_lock)
    next-page.xpm (stock_next-page)
    refresh.xpm (stock_refresh)
    sort-ascending (stock_sort-ascending)
    sort-column-ascending (stock_sort-column-ascending)
    sort-criteria (stock_sort-criteria)
    sort-descending (stock_sort-descending)
    sort-row-ascending (stock_sort-row-ascending)

    gnus/toggle-subscription.xpm (stock_task-recurring)

    mail/compose.xpm (stock_mail-compose)
    mail/copy.xpm (stock_mail-copy)
    mail/forward.xpm (stock_mail-forward)
    mail/inbox.xpm (stock_inbox)
    mail/move.xpm (stock_mail-move)
    mail/not-spam.xpm (stock_not-spam)
    mail/outbox.xpm (stock_outbox)
    mail/reply-all.xpm (stock_mail-reply-to-all)
    mail/reply.xpm (stock_mail-reply)
    mail/save-draft.xpm (stock_mail-handling)
    mail/send.xpm (stock_mail-send)
    mail/spam.xpm (stock_spam)


The following icons were contributed by Adam Sjøgren <asjo@koldfront.dk>:

    mail/preview.xpm (combining stock_mail and stock_zoom)
    mail/save.xpm    (combining stock_mail, stock_save and stock_convert) 


The following icon is from AUCTeX:

    separator.xpm (sep.xpm)


The folling icon are duplicated from Emacs 22.  They are either not present in
Emacs 21 or look different there.

    cancel.xpm
    copy.xpm
    diropen.xpm
    help.xpm
    left-arrow.xpm
    paste.xpm
    print.xpm
    redo.xpm
    right-arrow.xpm
    save.xpm
    search.xpm

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: New GNOME icons

[Bill Wohler]

Bill Wohler <wohler@newt.com> writes:

> I've enclosed the Gnus README which documents the icons we propose to
> update or add to the Emacs CVS repository. The GNOME names are in
> parenthesis. If you would like to comment on these before we check them
> in, please do!

Hi Reiner, since there weren't any objections, could you please
proceed and ACK so I can verify them in MH-E? Thanks!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Reiner Steib]

On Tue, Mar 07 2006, Bill Wohler wrote:

> The Gnus team have updated their icons from GNOME 2.6. Previously, all
> of their images were in the etc/images/gnus directory. We (the Gnus and
> MH-E teams) have worked together to share more of these images to
> provide a more unified user experience. That means that a number of
> those images will move from the Gnus sub-directory and move into the
> top-level etc/images directory or mail sub-directory

Minor correction: None of the current Gnus images will be moved (the
old icons will still be available for those who prefer the retro
look).  The Gnome icons will be placed into etc/images or
etc/images/mail (and a single icon in etc/image/gnus).

> where they will also be available to other Emacs developers.
>
> I've enclosed the Gnus README which documents the icons we propose to
> update or add to the Emacs CVS repository. The GNOME names are in
> parenthesis. If you would like to comment on these before we check them
> in, please do!

No comments, no objection so far.  So I think we can go ahead an
install the icons in Emacs CVS.

I could add the icons in Emacs CVS, but not before Monday.  Miles, as
you know, the icons are already in the trunk of Gnus repository.  Is
it better if you sync them into v5-10 and to Emacs via arch or is
there no difference for you?

BTW, I checked in the *.xpm icons as binary ("-kb").  I'm not sure if
this is necessary for xpm's.  Is it necessary?

Bill, I'd suggest that you merge the latest changes[1] in
*image-load-path-for-library from lisp/gmm-utils.el into your version
and add it to `image.el'.

Bye, Reiner.

[1]	* gmm-utils.el (gmm-image-load-path-for-library): Return single
	directory if path is t.  Add no-error.
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/

Re: New GNOME icons

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> BTW, I checked in the *.xpm icons as binary ("-kb").  I'm not sure if
> this is necessary for xpm's.  Is it necessary?

No.

> Bill, I'd suggest that you merge the latest changes[1] in
> *image-load-path-for-library from lisp/gmm-utils.el into your version
> and add it to `image.el'.

OK.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Miles Bader]

Reiner Steib <reinersteib+gmane@imap.cc> writes:
> I could add the icons in Emacs CVS, but not before Monday.  Miles, as
> you know, the icons are already in the trunk of Gnus repository.  Is
> it better if you sync them into v5-10 and to Emacs via arch or is
> there no difference for you?

Well, either is OK, but I need some warning if you do it, so I can make
sure things are consistent with Gnus.

If you want me to do it, just give me a list of the files to be copied.

Thanks,

-Miles
-- 
o The existentialist, not having a pillow, goes everywhere with the book by
  Sullivan, _I am going to spit on your graves_.

*image-load-path-for-library update

[Bill Wohler]

[-- Attachment #1: Type: text/plain, Size: 566 bytes --]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> Bill, I'd suggest that you merge the latest changes[1] in
> *image-load-path-for-library from lisp/gmm-utils.el into your version
> and add it to `image.el'.

Reiner,

I liked these changes. Thanks!

I edited the docstrings a bit, replaced the gmm-message with just
message for both MH-E and Emacs, and made the return code more explicit
in the case when no-error is t and there is an error. Hope those look
good to you. I've checked in these changes to CVS Emacs.

Here's a patch for your review and convenience.


[-- Attachment #2: image-load-path-for-library patch --]
[-- Type: text/plain, Size: 1983 bytes --]

--- mh-compat.el.orig	2006-03-10 17:36:49.000000000 -0800
+++ mh-compat.el	2006-03-10 17:54:48.000000000 -0800
@@ -124,12 +124,12 @@
 well as in `image-load-path' and `load-path'.
 
 This function returns the value of `load-path' augmented with the
-path to IMAGE.  If PATH is given, it is used instead of
-`load-path'.  If PATH is t, return a single image directory
-instead of a path.
+directory containing IMAGE. If PATH is given, it is used instead
+of `load-path'. If PATH is t, just return the directory that
+contains IMAGE.
 
-If NO-ERROR is non-nil, don't signal an error if no suitable path
-for can be found.
+If NO-ERROR is non-nil, return nil if a suitable path can't be
+found rather than signaling an error.
 
 Here is an example that uses a common idiom to provide
 compatibility with versions of Emacs that lack the variable
@@ -184,16 +184,19 @@
                        dir (expand-file-name "../" dir)))
                (setq image-directory dir)))))
      (no-error
-      ;; In this case we will return a nil element
-      (gmm-message 1 "Could not find image %s for library %s" image library))
+      ;; In this case we will return nil.
+      (message "Could not find image %s for library %s" image library))
      (t
       (error "Could not find image %s for library %s" image library)))
 
-    ;; Return augmented `image-load-path' or `load-path'.
-    (cond ((eq path t)
-	   image-directory)
-	  ((and path (symbolp path))
-	   (nconc (list image-directory)
+    ;; Return the directory, nil if no-error was non-nil and a
+    ;; suitable path could not be found, or an augmented
+    ;; `image-load-path' or `load-path'.
+    (cond ((or (null image-directory)
+               (eq path t))
+           image-directory)
+          ((and path (symbolp path))
+           (nconc (list image-directory)
                   (delete image-directory
                           (if (boundp path)
                               (copy-sequence (symbol-value path))

[-- Attachment #3: Type: text/plain, Size: 199 bytes --]


-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: *image-load-path-for-library update

[Reiner Steib]

On Sat, Mar 11 2006, Bill Wohler wrote:

> I edited the docstrings a bit, replaced the gmm-message with just
> message for both MH-E and Emacs, and made the return code more explicit
> in the case when no-error is t and there is an error. Hope those look
> good to you. 
[...]
> -If NO-ERROR is non-nil, don't signal an error if no suitable path
> -for can be found.

s/for //

> +If NO-ERROR is non-nil, return nil if a suitable path can't be
> +found rather than signaling an error.

I think "return nil" is not correct:

(gmm-image-load-path-for-library "gnus" "baz/zab" nil t) returns (nil
old-load-path).  And this is how it should be, because else we'd get a
completely useless nil [image-]load-path.

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Reiner Steib]

On Sat, Mar 11 2006, Miles Bader wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> writes:
>> I could add the icons in Emacs CVS, but not before Monday.  Miles, as
>> you know, the icons are already in the trunk of Gnus repository.  Is
>> it better if you sync them into v5-10 and to Emacs via arch or is
>> there no difference for you?
>
> Well, either is OK, but I need some warning if you do it, so I can make
> sure things are consistent with Gnus.
>
> If you want me to do it, just give me a list of the files to be copied.

If you find time to do it before Monday, please go ahead.  Else I will
do on Monday or Tuesday.

The list is in [Gnus trunk]/etc/image/README.  All icons from
attach.xpm to separator.xpm should be added:

--8<---------------cut here---------------start------------->8---
$ sed -ne 's|^    \([^ ]*.xpm\).*$|\1|p;/separator.xpm/q' < README
attach.xpm
connect.xpm
contact.xpm
delete.xpm
describe.xpm
disconnect.xpm
exit.xpm
lock-broken.xpm
lock-ok.xpm
lock.xpm
next-page.xpm
refresh.xpm
sort-ascending.xpm
sort-column-ascending.xpm
sort-criteria.xpm
sort-descending.xpm
sort-row-ascending.xpm
gnus/toggle-subscription.xpm
mail/compose.xpm
mail/copy.xpm
mail/forward.xpm
mail/inbox.xpm
mail/move.xpm
mail/not-spam.xpm
mail/outbox.xpm
mail/reply-all.xpm
mail/reply.xpm
mail/save-draft.xpm
mail/send.xpm
mail/spam.xpm
mail/preview.xpm
mail/save.xpm
separator.xpm
--8<---------------cut here---------------end--------------->8---

From these icons, the following already exist in Emacs:

exit.xpm             (Unused in Emacs, IIRC.  Update to larger image)
mail/compose.xpm     (Used by MH-E.  Update to GNOME style.)
mail/reply-all.xpm   (Ditto)
mail/reply.xpm       (Ditto)
mail/send.xpm        (Ditto)
refresh.xpm          (No real change, see [1])

Bye, Reiner.

[1]
@@ -2 +2 @@
-static char * refresh_xpm[] = {
+static char * stock_refresh_xpm[] = {
-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: *image-load-path-for-library update

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Sat, Mar 11 2006, Bill Wohler wrote:
> 
> > I edited the docstrings a bit, replaced the gmm-message with just
> > message for both MH-E and Emacs, and made the return code more explicit
> > in the case when no-error is t and there is an error. Hope those look
> > good to you. 
> [...]
> > -If NO-ERROR is non-nil, don't signal an error if no suitable path
> > -for can be found.
> 
> s/for //
> 
> > +If NO-ERROR is non-nil, return nil if a suitable path can't be
> > +found rather than signaling an error.
> 
> I think "return nil" is not correct:
> 
> (gmm-image-load-path-for-library "gnus" "baz/zab" nil t) returns (nil
> old-load-path).  And this is how it should be, because else we'd get a
> completely useless nil [image-]load-path.

Whoops, you're right. Will fix the function (and now the documentation).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: *image-load-path-for-library update

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Sat, Mar 11 2006, Bill Wohler wrote:
> 
> > I edited the docstrings a bit, replaced the gmm-message with just
> > message for both MH-E and Emacs, and made the return code more explicit
> > in the case when no-error is t and there is an error. Hope those look
> > good to you. 
> [...]
> > -If NO-ERROR is non-nil, don't signal an error if no suitable path
> > -for can be found.
> 
> s/for //
> 
> > +If NO-ERROR is non-nil, return nil if a suitable path can't be
> > +found rather than signaling an error.
> 
> I think "return nil" is not correct:
> 
> (gmm-image-load-path-for-library "gnus" "baz/zab" nil t) returns (nil
> old-load-path).  And this is how it should be, because else we'd get a
> completely useless nil [image-]load-path.

Initially, I thought that having the nil in the path might cause
problems; it certainly looks messy. But on second thought, if we ever
wanted to commit to having image-directory as the first element, we'd
need that nil in the first spot.

Since I haven't heard back from anyone regarding this committal, I'll
assume everyone is indifferent on it. I'll just go ahead and commit to
having the image-directory in the first spot, which might be nil if
no-error is t, and update the example as you had previously suggested.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: *image-load-path-for-library update

[Bill Wohler]

Before I check this in, any comments?

Index: image.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/image.el,v
retrieving revision 1.57
diff -u -u -r1.57 image.el
--- image.el	11 Mar 2006 02:04:08 -0000	1.57
+++ image.el	12 Mar 2006 01:58:14 -0000
@@ -85,21 +86,20 @@
 well as in `image-load-path' and `load-path'.
 
 This function returns the value of `load-path' augmented with the
-directory containing IMAGE. If PATH is given, it is used instead
-of `load-path'. If PATH is t, just return the directory that
-contains IMAGE.
-
-If NO-ERROR is non-nil, return nil if a suitable path can't be
-found rather than signaling an error.
+directory containing IMAGE at the beginning of the list. If PATH
+is given, it is used instead of `load-path'. If PATH is t, just
+return the directory that contains IMAGE.
+
+If NO-ERROR is non-nil and a suitable path can't be found, don't
+signal an error. Instead, return nil if PATH is t or an augmented
+path with nil at the beginning of the list.
 
 Here is an example that uses a common idiom to provide
 compatibility with versions of Emacs that lack the variable
 `image-load-path':
 
-  (let ((load-path
-         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\"))
-        (image-load-path
-         (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\" 'image-load-path)))
+  (let* ((load-path (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\"))
+         (image-load-path (cons (car load-path) image-load-path)))
     (mh-tool-bar-folder-buttons-init))"
   (unless library (error "No library specified"))
   (unless image   (error "No image specified"))
@@ -142,16 +142,14 @@
                        dir (expand-file-name "../" dir)))
                (setq image-directory dir)))))
      (no-error
-      ;; In this case we will return nil.
       (message "Could not find image %s for library %s" image library))
      (t
       (error "Could not find image %s for library %s" image library)))
 
-    ;; Return the directory, nil if no-error was non-nil and a
-    ;; suitable path could not be found, or an augmented
+    ;; Return the directory (or nil if no-error was non-nil and a
+    ;; suitable path could not be found), or an augmented
     ;; `image-load-path' or `load-path'.
-    (cond ((or (null image-directory)
-               (eq path t))
+    (cond ((eq path t)
            image-directory)
           ((and path (symbolp path))
            (nconc (list image-directory)

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <v9fylp4zwh.fsf@marauder.physik.uni-ulm.de>
>>>>>	Reiner Steib wrote:

> [1]	* gmm-utils.el (gmm-image-load-path-for-library): Return single
> 	directory if path is t.  Add no-error.

Because of the `no-error' argument[1], I needed to modify the
`gmm-defun-compat' macro as follows since I'm using Emacs 23.
It will become unnecessary soon (when the `emacs-unicode-2'
branch is synch'd with the trunk), though.

--8<---------------cut here---------------start------------->8---
--- gmm-utils.el~	2006-03-07 22:01:08 +0000
+++ gmm-utils.el	2006-03-13 11:51:18 +0000
@@ -285,8 +285,19 @@
   "Create function NAME.
 If FUNCTION exists, then NAME becomes an alias for FUNCTION.
 Otherwise, create function NAME with ARG-LIST and BODY."
-  (let ((defined-p (fboundp function)))
-    (if defined-p
+  (let ((definition (and (fboundp function)
+			 (symbol-function function))))
+    ;; FIXME: If a function which is not a byte compiled one might be
+    ;; given as FUNCTION, we'll have to use `ad-arglist' or equivalent.
+    (if (and definition
+	     (or (not (byte-code-function-p definition))
+		 (eq (length arg-list)
+		     (ignore-errors
+		       (length (if (fboundp 'compiled-function-arglist)
+				   ;; XEmacs
+				   (eval (list 'compiled-function-arglist
+					       definition))
+				 (aref definition 0)))))))
         `(defalias ',name ',function)
       `(defun ,name ,arg-list ,@body))))
 
--8<---------------cut here---------------end--------------->8---

[1] image-load-path-for-library is a compiled Lisp function in `image.el'.
(image-load-path-for-library LIBRARY IMAGE &optional PATH)

Re: New GNOME icons

[Bill Wohler]

[Taking emacs-devel off the cc list since they don't need to be bothered
by this. Or do they?]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> >>>>> In <v9fylp4zwh.fsf@marauder.physik.uni-ulm.de>
> >>>>>	Reiner Steib wrote:
> 
> > [1]	* gmm-utils.el (gmm-image-load-path-for-library): Return single
> > 	directory if path is t.  Add no-error.
> 
> Because of the `no-error' argument[1], I needed to modify the
> `gmm-defun-compat' macro as follows

Why? The arguments to *-defun-compat shouldn't make any difference. What
problems were you seeing?

>                                     since I'm using Emacs 23.

What's that?

> It will become unnecessary soon (when the `emacs-unicode-2'
> branch is synch'd with the trunk), though.

Please document that.

Your patch is completely undecipherable to me. I'd like to see some
documentation regarding the motivation for it, as well as what it is
doing.

> --8<---------------cut here---------------start------------->8---
> --- gmm-utils.el~	2006-03-07 22:01:08 +0000
> +++ gmm-utils.el	2006-03-13 11:51:18 +0000
> @@ -285,8 +285,19 @@
>    "Create function NAME.
>  If FUNCTION exists, then NAME becomes an alias for FUNCTION.
>  Otherwise, create function NAME with ARG-LIST and BODY."
> -  (let ((defined-p (fboundp function)))
> -    (if defined-p
> +  (let ((definition (and (fboundp function)
> +			 (symbol-function function))))
> +    ;; FIXME: If a function which is not a byte compiled one might be
> +    ;; given as FUNCTION, we'll have to use `ad-arglist' or equivalent.
> +    (if (and definition
> +	     (or (not (byte-code-function-p definition))
> +		 (eq (length arg-list)
> +		     (ignore-errors
> +		       (length (if (fboundp 'compiled-function-arglist)
> +				   ;; XEmacs
> +				   (eval (list 'compiled-function-arglist
> +					       definition))
> +				 (aref definition 0)))))))
>          `(defalias ',name ',function)
>        `(defun ,name ,arg-list ,@body))))
>  
> --8<---------------cut here---------------end--------------->8---
> 
> [1] image-load-path-for-library is a compiled Lisp function in `image.el'.
> (image-load-path-for-library LIBRARY IMAGE &optional PATH)
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting language
> that extends applications into web and mobile media. Attend the live webcast
> and join the prime developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> mh-e-devel mailing list
> mh-e-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mh-e-devel
> 

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <3861.1142268982@olgas.newt.com> Bill Wohler wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> wrote:

>>>>>>> In <v9fylp4zwh.fsf@marauder.physik.uni-ulm.de>
>>>>>>>	Reiner Steib wrote:
>>
>>> [1]	* gmm-utils.el (gmm-image-load-path-for-library): Return single
>>> 	directory if path is t.  Add no-error.
>>
>> Because of the `no-error' argument[1], I needed to modify the
>> `gmm-defun-compat' macro as follows

> Why? The arguments to *-defun-compat shouldn't make any difference. What
> problems were you seeing?

I'm sorry in the insufficient explanation.

The specification of the `image-load-path-for-library' function
contained in Emacs 23 that I had checked out on yesterday
morning (in Japan) was:

(image-load-path-for-library LIBRARY IMAGE &optional PATH)

It caused the `wrong-number-of-arguments' error since Gnus
specifies the fourth argument NO-ERROR to the
`gmm-image-load-path-for-library' function which is an alias to
`image-load-path-for-library'.  So, I had to modify the macro so
as to use the one that has been defined in gmm-utils.el.  But
now the problem is solved because image.el contained in Emacs 23
has been synch'd with the Emacs CVS trunk (i.e., Emacs 22.0.50).

>>                                     since I'm using Emacs 23.

> What's that?

Emacs 23 is being developed in the `emacs-unicode-2' branch of
the Emacs CVS repository.  It fully uses Unicode internally for
multilingual text, and merges the changes made in the trunk.
(You can check it out using the `-r emacs-unicode-2' option).

>> It will become unnecessary soon (when the `emacs-unicode-2'
>> branch is synch'd with the trunk), though.

> Please document that.

> Your patch is completely undecipherable to me. I'd like to see some
> documentation regarding the motivation for it, as well as what it is
> doing.

I presented what is needed to generalize the `gmm-defun-compat'
more, though it is not necessary for the moment.

Re: New GNOME icons

[Bill Wohler]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> >>>>> In <3861.1142268982@olgas.newt.com> Bill Wohler wrote:
> 
> > Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> 
> >>>>>>> In <v9fylp4zwh.fsf@marauder.physik.uni-ulm.de>
> >>>>>>>	Reiner Steib wrote:
> >>
> >>> [1]	* gmm-utils.el (gmm-image-load-path-for-library): Return single
> >>> 	directory if path is t.  Add no-error.
> >>
> >> Because of the `no-error' argument[1], I needed to modify the
> >> `gmm-defun-compat' macro as follows
> 
> > Why? The arguments to *-defun-compat shouldn't make any difference. What
> > problems were you seeing?
> 
> I'm sorry in the insufficient explanation.
> 
> The specification of the `image-load-path-for-library' function
> contained in Emacs 23 that I had checked out on yesterday
> morning (in Japan) was:
> 
> (image-load-path-for-library LIBRARY IMAGE &optional PATH)
> 
> It caused the `wrong-number-of-arguments' error since Gnus
> specifies the fourth argument NO-ERROR to the
> `gmm-image-load-path-for-library' function which is an alias to
> `image-load-path-for-library'.

Ah! I see. It was actually the image-load-path-for-library function that
was at fault, not gmm-defun-compat.

By the way, Richard had a few comments about our
image-load-path-for-library function. He didn't like that "path" was a
symbol. He preferred to pass the value. Also, he didn't like it that we
weren't always returning a list, such as when "path" was t. I think he's
right. Indeed, fixing these things simplified the final cond to just:

    (nconc (list image-directory)
           (delete image-directory (copy-sequence (or path load-path))))))

Note that we now document that the directory is first, so the "path ==
t" feature can be achieved with (car (image-load-path-for-library ...)).

I've made the changes that Richard suggested, but I'd like to get
confirmation from you folks that they are OK with you too before
committing them. At that time, you can copy the changes from
image-load-path-for-library into gmm-image-load-path-for-library and
remove your changes to gmm-defun-compat.

> >>                                     since I'm using Emacs 23.
> 
> > What's that?
> 
> Emacs 23 is being developed in the `emacs-unicode-2' branch of
> the Emacs CVS repository.  It fully uses Unicode internally for
> multilingual text, and merges the changes made in the trunk.
> (You can check it out using the `-r emacs-unicode-2' option).

Ah, that's what they're calling the Unicode branch now. I heard about
that. Is the plan to release Emacs 22, and then merge the Unicode stuff
into the trunk immediately after that? The Unicode changes would be the
major change to Emacs 23, right? I'm looking forward to that.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <22907.1142318606@olgas.newt.com> Bill Wohler wrote:

> By the way, Richard had a few comments about our
> image-load-path-for-library function. He didn't like that "path" was a
> symbol. He preferred to pass the value. Also, he didn't like it that we
> weren't always returning a list, such as when "path" was t. I think he's
> right. Indeed, fixing these things simplified the final cond to just:

>     (nconc (list image-directory)
>            (delete image-directory (copy-sequence (or path load-path))))))

> Note that we now document that the directory is first, so the "path ==
> t" feature can be achieved with (car (image-load-path-for-library ...)).

> I've made the changes that Richard suggested, but I'd like to get
> confirmation from you folks that they are OK with you too before
> committing them. At that time, you can copy the changes from
> image-load-path-for-library into gmm-image-load-path-for-library and
> remove your changes to gmm-defun-compat.

Well, I have currently no idea about that since I didn't follow
the whole story.  But I have an unsophisticated doubt.

When Emacs didn't have new image files, I programmed my shell
script which builds and installs Gnus so that it installs image
files to the "/usr/local/share/emacs/etc/images/" directory, and
I added it to `image-load-path' as the first element.  The
reason I did so is I don't want to modify image files that Emacs
provides though I want Gnus to display new icon images.

(The default directory in which Emacs' image files are
installed is "/usr/local/share/emacs/VERSION/etc/images/".
Normally Emacs doesn't care "/usr/local/share/emacs/etc/images/"
which I made.)

My doubt is that there seems to be no way to tell the
`(gmm-)image-load-path-for-library' function that my image files
are in "/usr/local/share/emacs/etc/images/".  Of course, it is
not a matter since Emacs provides new image files now, though.

> Is the plan to release Emacs 22, and then merge the Unicode stuff
> into the trunk immediately after that? The Unicode changes would be the
> major change to Emacs 23, right? I'm looking forward to that.

I don't know at all.  Maybe RMS (or possibly Kenichi Handa) has
an answer. :)

Re: New GNOME icons

[Reiner Steib]

On Tue, Mar 14 2006, Bill Wohler wrote:

> By the way, Richard had a few comments about our
> image-load-path-for-library function. He didn't like that "path" was a
> symbol. He preferred to pass the value. Also, he didn't like it that we
> weren't always returning a list, such as when "path" was t. I think he's
> right. Indeed, fixing these things simplified the final cond to just:
>
>     (nconc (list image-directory)
>            (delete image-directory (copy-sequence (or path load-path))))))
>
> Note that we now document that the directory is first, so the "path ==
> t" feature can be achieved with (car (image-load-path-for-library ...)).
>
> I've made the changes that Richard suggested, but I'd like to get
> confirmation from you folks that they are OK with you too before
> committing them. 

Please do.  For now, I have changed `gmm-utils.el' to use `defun'
instead of `gmm-defun-compat' until the API changes are finished.

> At that time, you can copy the changes from
> image-load-path-for-library into gmm-image-load-path-for-library and
> remove your changes to gmm-defun-compat.

BTW, one thing about `gmm-defun-compat' I don't like is that the
`gmm-utils.el' link in...

,----[ <f1> f gmm-image-search-load-path RET ]
| gmm-image-search-load-path is a compiled Lisp function in `gmm-utils.el'.
| (gmm-image-search-load-path FILE &optional PATH)
| 
| Emacs 21 and XEmacs don't have `image-search-load-path'.
| This function returns nil on those systems.
`----

... leads to "Cannot find definition of `gmm-image-search-load-path'
in library `gmm-utils.el'" instead of jumping to "(gmm-defun-compat
gmm-image-search-load-path ...)" in `gmm-utils.el'.

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Bill Wohler]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> >>>>> In <22907.1142318606@olgas.newt.com> Bill Wohler wrote:
> 
> > By the way, Richard had a few comments about our
> > image-load-path-for-library function. He didn't like that "path" was a
> > symbol. He preferred to pass the value. Also, he didn't like it that we
> > weren't always returning a list, such as when "path" was t. I think he's
> > right. Indeed, fixing these things simplified the final cond to just:
> 
> >     (nconc (list image-directory)
> >            (delete image-directory (copy-sequence (or path load-path))))))
> 
> > Note that we now document that the directory is first, so the "path ==
> > t" feature can be achieved with (car (image-load-path-for-library ...)).
> 
> > I've made the changes that Richard suggested, but I'd like to get
> > confirmation from you folks that they are OK with you too before
> > committing them. At that time, you can copy the changes from
> > image-load-path-for-library into gmm-image-load-path-for-library and
> > remove your changes to gmm-defun-compat.
> 
> Well, I have currently no idea about that since I didn't follow
> the whole story.  But I have an unsophisticated doubt.
> 
> When Emacs didn't have new image files, I programmed my shell
> script which builds and installs Gnus so that it installs image
> files to the "/usr/local/share/emacs/etc/images/" directory, and
> I added it to `image-load-path' as the first element.  The
> reason I did so is I don't want to modify image files that Emacs
> provides though I want Gnus to display new icon images.
> 
> (The default directory in which Emacs' image files are
> installed is "/usr/local/share/emacs/VERSION/etc/images/".
> Normally Emacs doesn't care "/usr/local/share/emacs/etc/images/"
> which I made.)
> 
> My doubt is that there seems to be no way to tell the
> `(gmm-)image-load-path-for-library' function that my image files
> are in "/usr/local/share/emacs/etc/images/".  Of course, it is
> not a matter since Emacs provides new image files now, though.

Just add your directory to image-load-path (or load-path if
image-load-path isn't bound) before calling the function and it will be
found, assuming that the image passed to image-load-path-for-library is
in your directory. This is what the Debian MH-E package does in its
site-init.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Tue, Mar 14 2006, Bill Wohler wrote:
> 
> > I've made the changes that Richard suggested, but I'd like to get
> > confirmation from you folks that they are OK with you too before
> > committing them. 
> 
> Please do.

Thanks. I've committed the updated image-load-path-for-library so please
grab it at your leisure.

>             For now, I have changed `gmm-utils.el' to use `defun'
> instead of `gmm-defun-compat' until the API changes are finished.

Hopefully, that'll be it ;-).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Reiner Steib]

On Tue, Mar 14 2006, Bill Wohler wrote:

> Thanks. I've committed the updated image-load-path-for-library 

I've seen your changes on emacs-diffs:

,----
| ;; Avoid errors on Emacsen without `image-load-path'.
| (if (not (boundp 'image-load-path)) (defvar image-load-path nil))
`----

Please don't recommend to bind `image-load-path'.  Other packages
might test if `image-load-path' is bound only in Emacs versions that
really use it:

,----
| ELISP> (if (not (boundp 'image-load-path)) (defvar image-load-path nil))
| 
| image-load-path
| ELISP> (boundp 'image-load-path)
| t
`----

I'd suggest the following where the `image-load-path' won't be bound
outside the let expression.

(let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
       (image-load-path (cons (car load-path)
			      (when (boundp 'image-load-path)
				image-load-path))))
  (mh-tool-bar-folder-buttons-init))

,----
| ELISP> emacs-version
| "21.3.1"
| ELISP> (boundp 'image-load-path)
| nil
| ELISP> (defun image-load-path-for-library (&rest ignore)
| 	 load-path)
| image-load-path-for-library
| ELISP> (let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
| 	      (image-load-path (cons (car load-path)
| 				     (when (boundp 'image-load-path)
| 				       image-load-path))))
| 	 image-load-path)
| ("/usr/share/emacs/site-lisp/xslide")
| 
| ELISP> (boundp 'image-load-path)
| nil
`----

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> I'd suggest the following where the `image-load-path' won't be bound
> outside the let expression.
> 
> (let* ((load-path (image-load-path-for-library "mh-e" "mh-logo.xpm"))
>        (image-load-path (cons (car load-path)
> 			      (when (boundp 'image-load-path)
> 				image-load-path))))
>   (mh-tool-bar-folder-buttons-init))

How would you fix this, then?

    While compiling mh-folder-mode in file
    /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-folder.el:
      ** reference to free variable image-load-path

Would this be acceptable?

  (eval-when-compile (defvar image-load-path))

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <1183.1142359136@olgas.newt.com> Bill Wohler wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> wrote:

[...]

>> My doubt is that there seems to be no way to tell the
>> `(gmm-)image-load-path-for-library' function that my image files
>> are in "/usr/local/share/emacs/etc/images/".  Of course, it is
>> not a matter since Emacs provides new image files now, though.

> Just add your directory to image-load-path (or load-path if
> image-load-path isn't bound) before calling the function and it will be
> found, assuming that the image passed to image-load-path-for-library is
> in your directory. This is what the Debian MH-E package does in its
> site-init.

I exactly did so.  However, `image-load-path-for-library'
doesn't take notice of

"/usr/local/share/emacs/etc/images/gnus/toggle-subscription.xpm"

if

"/usr/local/share/emacs/22.0.50/etc/images/gnus/toggle-subscription.xpm"

exists.  It suggests there's no way that she uses her favorite
images instead of the ones Emacs provides.

image-load-path
 => ("/usr/local/share/emacs/etc/images/"
     "/usr/local/share/emacs/22.0.50/etc/images/"
     data-directory
     load-path)

(file-exists-p
 "/usr/local/share/emacs/etc/images/gnus/toggle-subscription.xpm")
 => t

(file-exists-p
 "/usr/local/share/emacs/22.0.50/etc/images/gnus/toggle-subscription.xpm")
 => t

(let ((dirs (image-load-path-for-library
	     "gnus"
	     "gnus/toggle-subscription.xpm"
	     nil t)))
  (or (member "/usr/local/share/emacs/etc/images/" dirs)
      (member "/usr/local/share/emacs/etc/images" dirs)))
 => nil

Re: New GNOME icons

[Katsumi Yamaoka]

[-- Attachment #1: Type: text/plain, Size: 340 bytes --]

>>>>> In <yamaokairqgeatp.fsf@jpl.org> Katsumi Yamaoka wrote:

> It suggests there's no way that she uses her favorite images instead
> of the ones Emacs provides.

An alternative plan is here:

	* gmm-utils.el (gmm-image-load-path-for-library): Look for the
	most preferred directory which may be specified in image-load-path
	by a user.


[-- Attachment #2: Type: application/emacs-lisp, Size: 3678 bytes --]

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <yamaokay7zcjh4f.fsf@jpl.org> Katsumi Yamaoka wrote:

>> It suggests there's no way that she uses her favorite images instead
>> of the ones Emacs provides.

> An alternative plan is here:

> 	* gmm-utils.el (gmm-image-load-path-for-library): Look for the
> 	most preferred directory which may be specified in image-load-path
> 	by a user.

Oops, we should use `file-truename' to check directories a user
added to `image-load-path'.  Here's a part in question:

[...]
	(let ((image-load-path
	       (butlast
		(symbol-value 'image-load-path)
		(length (member (file-truename
				 (file-name-as-directory image-directory))
				(mapcar
				 (lambda (dir)
				   (if (stringp dir)
				       (file-truename
					(expand-file-name
					 (file-name-as-directory dir)))
				     dir))
				 (symbol-value 'image-load-path)))))))
[...]

Re: New GNOME icons

[Reiner Steib]

On Tue, Mar 14 2006, Bill Wohler wrote:

> How would you fix this, then?
>
>     While compiling mh-folder-mode in file
>     /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-folder.el:
>       ** reference to free variable image-load-path
>
> Would this be acceptable?
>
>   (eval-when-compile (defvar image-load-path))

Yes.  IIRC `eval-when-compile' isn't necessary:

(defvar image-load-path)

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Reiner Steib]

On Tue, Mar 14 2006, Bill Wohler wrote:

> How would you fix this, then?
>
>     While compiling mh-folder-mode in file
>     /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-folder.el:
>       ** reference to free variable image-load-path
>
> Would this be acceptable?
>
>   (eval-when-compile (defvar image-load-path))

Yes.  IIRC `eval-when-compile' isn't necessary:

(defvar image-load-path)

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: New GNOME icons

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Tue, Mar 14 2006, Bill Wohler wrote:
> 
> > How would you fix this, then?
> >
> >     While compiling mh-folder-mode in file
> >     /usr/local/src/mh-e/src/emacs/lisp/mh-e/mh-folder.el:
> >       ** reference to free variable image-load-path
> >
> > Would this be acceptable?
> >
> >   (eval-when-compile (defvar image-load-path))
> 
> Yes.  IIRC `eval-when-compile' isn't necessary:

Thanks.

Not necessary, but better no? Since it's only needed during compilation,
doesn't putting it in an eval-when-compile produce one less form to
evaluate during run-time? I also find it self-documenting.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

defvars at compile time (was: New GNOME icons)

[Reiner Steib]

On Wed, Mar 15 2006, Bill Wohler wrote:

> Reiner Steib <reinersteib+gmane@imap.cc> wrote:
>> On Tue, Mar 14 2006, Bill Wohler wrote:
[...]
>> >   (eval-when-compile (defvar image-load-path))
>> 
>> Yes.  IIRC `eval-when-compile' isn't necessary:
>
> Thanks.
>
> Not necessary, but better no? Since it's only needed during compilation,
> doesn't putting it in an eval-when-compile produce one less form to
> evaluate during run-time? I also find it self-documenting.

,----[ http://article.gmane.org/gmane.emacs.devel/42998 ]
| From: Stefan Monnier
| Subject: Re: defvars at compile time
| 
| [...]
| 
| The form (defvar foo) was specifically designed as a byte-compiler
| directive, so please make use of it.
`----

,----[ http://article.gmane.org/gmane.emacs.devel/43027 ]
| From: Richard M. Stallman
| Subject: Re: defvars at compile time
|
| The only effect of a defvar with no initial value
| is to silence the compiler.  So it is superfluous
| to put it inside eval-when-compile.
`----

We should shift this to emacs-devel if more discussion is necessary
(Mail-Followup-To: emacs-devel).

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


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: defvars at compile time

[Bill Wohler]

Reiner Steib <reinersteib+gmane@imap.cc> wrote:

> On Wed, Mar 15 2006, Bill Wohler wrote:
> 
> > Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> >> On Tue, Mar 14 2006, Bill Wohler wrote:
> [...]
> >> >   (eval-when-compile (defvar image-load-path))
> >> 
> >> Yes.  IIRC `eval-when-compile' isn't necessary:
> >
> > Thanks.
> >
> > Not necessary, but better no? Since it's only needed during compilation,
> > doesn't putting it in an eval-when-compile produce one less form to
> > evaluate during run-time? I also find it self-documenting.
> 
> ,----[ http://article.gmane.org/gmane.emacs.devel/42998 ]
> | From: Stefan Monnier
> | Subject: Re: defvars at compile time
> | 
> | [...]
> | 
> | The form (defvar foo) was specifically designed as a byte-compiler
> | directive, so please make use of it.
> `----
> 
> ,----[ http://article.gmane.org/gmane.emacs.devel/43027 ]
> | From: Richard M. Stallman
> | Subject: Re: defvars at compile time
> |
> | The only effect of a defvar with no initial value
> | is to silence the compiler.  So it is superfluous
> | to put it inside eval-when-compile.
> `----
> 
> We should shift this to emacs-devel if more discussion is necessary
> (Mail-Followup-To: emacs-devel).

None necessary ;-).

I had missed that discussion. Vielen dank for forwarding it!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.

Re: New GNOME icons

[Katsumi Yamaoka]

>>>>> In <yamaokairqgeatp.fsf@jpl.org> Katsumi Yamaoka wrote:

> It suggests there's no way that she uses her favorite images instead
> of the ones Emacs provides.

Didn't you all understand my funny English?  Does Gnus demand
that users use only images that Gnus (or Emacs) provides?  Isn't
it a policy of Gnus that all are fully customizable?  Or did I
miss something?

In the present way of Gnus, there is almost no room for
unprivileged users to customize the directory in which Gnus
finds image files.  For instance, if a user wants Gnus to use
images installed in the ~/images directory even if the ones Gnus
provides are in "gnus/../../etc/images" or "gnus/../etc/images",
how does a user tell Gnus about it?  Although there might be no
such users and I'm not an unprivileged user, I stated a principle.

If users are allowed to modify `image-load-path' like
`load-path', Gnus should respect it (and I presented a way to
achieve it).  Otherwise, Gnus should provide some variable by
which users tell Gnus where to find images.

Regards,


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

gmm-image-load-path-for-library redux (was: New GNOME icons)

[Bill Wohler]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> >>>>> In <yamaokairqgeatp.fsf@jpl.org> Katsumi Yamaoka wrote:
> 
> > It suggests there's no way that she uses her favorite images instead
> > of the ones Emacs provides.
> 
> An alternative plan is here:
> 
>       * gmm-utils.el (gmm-image-load-path-for-library): Look for the
>       most preferred directory which may be specified in image-load-path
>       by a user.

Rats, that's why we had the mh-image-directory variable...

>       ;; Check for another directory that is specified in
>       ;; image-load-path and preferred than image-directory.
>       ((and image-directory
>             (boundp 'image-load-path))
>        (let ((image-load-path
>               (butlast
>                (symbol-value 'image-load-path)
>                (length (member (file-name-as-directory image-directory)
>                                (mapcar
>                                 (lambda (dir)
>                                   (if (stringp dir)
>                                       (file-name-as-directory dir)
>                                     dir))
>                                 (symbol-value 'image-load-path)))))))
>          (setq dir (image-search-load-path image))))
>

Oh boy, that took me about an hour to figure out ;-). Assuming I've
understood correctly, I think I see a couple of problems.

I don't see how (butlast) can be right. That code is stripping away the
directory found in .../etc/images *plus* all of the directories that
follow it which could include the user's directory. Most likely
.../etc/images won't be in image-load-path at all, so the last directory
in image-load-path will be stripped (which could be the user's
directory if they preferred to use the system images but provided images
as a fall-back).

I'm not quite sure of the whole point of that exercise anyway. Why not
just call (image-search-load-path image)?

But still, this isn't correct. If the user does *not* have a preferred
version, and you're running an external package, you'd prefer the
.../etc/images version over the one already in image-load-path. But this
code would give you the directory already in image-load-path.

A minor point, but why use (symbol-value 'image-load-path)? Why not just
the simpler and clearer image-load-path?

What I think might work is that we call (image-search-load-path image)
and use it instead of .../etc/images if and only if it isn't the system
image directory. The system image directory is (concat data-directory
"images"), right?

Here is a reworked function that seems to do what everybody wants (and
hopefully doesn't take an hour to understand ;-). What do you think?


(defun image-load-path-for-library (library image &optional path no-error)
  "Return a suitable search path for images relative to LIBRARY.

First it searches for IMAGE in a path suitable for LIBRARY, which
includes \"../../etc/images\" and \"../etc/images\" relative to
the library file itself, followed by `image-load-path' and
`load-path'.

Then this function returns a list of directories which contains
first the directory in which IMAGE was found, followed by the
value of `load-path'. If PATH is given, it is used instead of
`load-path'.

If NO-ERROR is non-nil and a suitable path can't be found, don't
signal an error. Instead, return a list of directories as before,
except that nil appears in place of the image directory.

Here is an example that uses a common idiom to provide
compatibility with versions of Emacs that lack the variable
`image-load-path':

    ;; Shush compiler.
    (defvar image-load-path)

    (let* ((load-path (image-load-path-for-library \"mh-e\" \"mh-logo.xpm\"))
           (image-load-path (cons (car load-path)
                                  (when (boundp 'image-load-path)
                                    image-load-path))))
      (mh-tool-bar-folder-buttons-init))"
  (unless library (error "No library specified"))
  (unless image   (error "No image specified"))
  (let (image-directory image-directory-load-path)
    ;; Check for images in image-load-path or load-path.
    (let ((img image)
          (dir (or
                ;; Images in image-load-path.
                (image-search-load-path image)
                ;; Images in load-path.
                (locate-library image)))
          parent)
      ;; Since the image might be in a nested directory (for
      ;; example, mail/attach.pbm), adjust `image-directory'
      ;; accordingly.
      (when dir
        (setq dir (file-name-directory dir))
        (while (setq parent (file-name-directory img))
          (setq img (directory-file-name parent)
                dir (expand-file-name "../" dir))))
      (setq image-directory-load-path dir))

    ;; If `image-directory-load-path' isn't Emacs' image directory,
    ;; it's probably a user preference, so use it. Then use a
    ;; relative setting if possible; otherwise, use
    ;; `image-directory-load-path'.
    (cond
     ;; User-modified image-load-path?
     ((and image-directory-load-path
           (not (equal image-directory-load-path
                       (file-name-as-directory
                        (expand-file-name "images" data-directory)))))
      (setq image-directory image-directory-load-path))
     ;; Try relative setting.
     ((let (library-name d1ei d2ei)
        ;; First, find library in the load-path.
        (setq library-name (locate-library library))
        (if (not library-name)
            (error "Cannot find library %s in load-path" library))
        ;; And then set image-directory relative to that.
        (setq
         ;; Go down 2 levels.
         d2ei (file-name-as-directory
               (expand-file-name
                (concat (file-name-directory library-name) "../../etc/images")))
         ;; Go down 1 level.
         d1ei (file-name-as-directory
               (expand-file-name
                (concat (file-name-directory library-name) "../etc/images"))))
        (setq image-directory
              ;; Set it to nil if image is not found.
              (cond ((file-exists-p (expand-file-name image d2ei)) d2ei)
                    ((file-exists-p (expand-file-name image d1ei)) d1ei)))))
     (image-directory-load-path
      (setq image-directory image-directory-load-path))
     (no-error
      (message "Could not find image %s for library %s" image library))
     (t
      (error "Could not find image %s for library %s" image library)))

    ;; Return an augmented `path' or `load-path'.
    (nconc (list image-directory)
           (delete image-directory (copy-sequence (or path load-path))))))


-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: gmm-image-load-path-for-library redux

[Katsumi Yamaoka]

It takes time to me to read and write English, so I'll write a
full replay later. ;-)

>>>>> In <9172.1142473306@olgas.newt.com> Bill Wohler wrote:

> A minor point, but why use (symbol-value 'image-load-path)? Why not just
> the simpler and clearer image-load-path?

The purpose is just the same as (defvar image-load-path) you
did; i.e., avoiding a compiler warning that Emacs 21 issues.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: gmm-image-load-path-for-library redux

[Katsumi Yamaoka]

My conclusion is that your new code is wonderful. :)

>>>>> In <9172.1142473306@olgas.newt.com> Bill Wohler wrote:

>>       ;; Check for another directory that is specified in
>>       ;; image-load-path and preferred than image-directory.
>>       ((and image-directory
>>             (boundp 'image-load-path))
>>        (let ((image-load-path
>>               (butlast
>>                (symbol-value 'image-load-path)
>>                (length (member (file-name-as-directory image-directory)
>>                                (mapcar
>>                                 (lambda (dir)
>>                                   (if (stringp dir)
>>                                       (file-name-as-directory dir)
>>                                     dir))
>>                                 (symbol-value 'image-load-path)))))))
>>          (setq dir (image-search-load-path image))))

> Oh boy, that took me about an hour to figure out ;-).

I might have had to fill up that section with thorough comments.
Sorry.

> Assuming I've understood correctly, I think I see a couple of
> problems.

> I don't see how (butlast) can be right. That code is stripping away
> the directory found in .../etc/images *plus* all of the directories
> that follow it which could include the user's directory.

I assumed users will add preferred directories to the beginning
of the list, and I also thought that the directory
"gnus/../../etc/images" (or "gnus/../etc/images") in which an
image has already been found and the directories following it
should be ignored.  Even if an image exists in one of
directories which are stripped from the list, we can ignore it
since the directory is not supposed to be preferred than
"gnus/../../etc/images" (or "gnus/../etc/images").  In
connection with this, I didn't expand variable symbols which are
contained in `image-load-path' into lists since I assumed users
won't add image directories to `load-path' in the system that
provides `image-load-path'.

> Most likely .../etc/images won't be in image-load-path at all,

No, it won't be.  By Emacs' default, Gnus will be installed
in "${PREFIX}/share/emacs/${VERSION}/lisp/gnus", images will be
in "${PREFIX}/share/emacs/${VERSION}/etc/images", and the
default value of `image-load-path' will be:

("${PREFIX}/share/emacs/${VERSION}/etc/images/" data-directory load-path)

In addition, if Gnus is installed separately, it will be
installed in "${PREFIX}/share/emacs/site-lisp/gnus" and
"${PREFIX}/share/emacs/etc/images" by default...

Oops, I noticed another problem right now.  In the later case,
the code I revised will choose the first element of
`image-load-path', not the one installed with Gnus separately.
After all, the variable like `gnus-image-directory' (which
defaults to "gnus/../../etc/images" or "gnus/../etc/images")
might be necessary to respect user's taste.

(I didn't notice this until now since I installed Gnus in
"${PREFIX}/share/emacs/${VERSION}/site-lisp/gnus" and
"${PREFIX}/share/emacs/etc/images".)

> so the last directory in image-load-path will be stripped (which
> could be the user's directory if they preferred to use the system
> images but provided images as a fall-back).

If "gnus/../../etc/images" (or "gnus/../etc/images") is not in
`image-load-path', nothing will be stripped because:

(eq image-load-path (butlast image-load-path 0)) => t

> I'm not quite sure of the whole point of that exercise anyway. Why not
> just call (image-search-load-path image)?

> But still, this isn't correct. If the user does *not* have a preferred
> version, and you're running an external package, you'd prefer the
> .../etc/images version over the one already in image-load-path. But this
> code would give you the directory already in image-load-path.

Exactly.  This is just what I noticed now.

> A minor point, but why use (symbol-value 'image-load-path)? Why not just
> the simpler and clearer image-load-path?

(I mentioned it in my last message as:
The purpose is just the same as (defvar image-load-path) you
did; i.e., avoiding a compiler warning that Emacs 21 issues.)

> What I think might work is that we call (image-search-load-path image)
> and use it instead of .../etc/images if and only if it isn't the system
> image directory. The system image directory is (concat data-directory
> "images"), right?

I believe it.

> Here is a reworked function that seems to do what everybody wants (and
> hopefully doesn't take an hour to understand ;-). What do you think?

That's skillful!  But it was easy to understand.  It also solves
the problem I mentioned above (the case that Gnus is installed
separately with the default configuration).  Could you install
it in Emacs?

Thanks and thanks in advance.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: gmm-image-load-path-for-library redux

[Bill Wohler]

Katsumi Yamaoka <yamaoka@jpl.org> wrote:

> (eq image-load-path (butlast image-load-path 0)) => t

For some reason, I made 0 == nil, which does trim the last item.

> > A minor point, but why use (symbol-value 'image-load-path)? Why not just
> > the simpler and clearer image-load-path?
> 
> (I mentioned it in my last message as:
> The purpose is just the same as (defvar image-load-path) you
> did; i.e., avoiding a compiler warning that Emacs 21 issues.)

While experimenting, I got a compiler warning with (symbol-value
'image-load-path)...

> > Here is a reworked function that seems to do what everybody wants (and
> > hopefully doesn't take an hour to understand ;-). What do you think?
> 
> That's skillful!  But it was easy to understand.  It also solves
> the problem I mentioned above (the case that Gnus is installed
> separately with the default configuration).  Could you install
> it in Emacs?

I'll do that first thing in the morning, California time. Thanks for
pointing out this problem in the code and for reviewing my code.

> >>>>> In <yamaokairqgeatp.fsf@jpl.org> Katsumi Yamaoka wrote:
> 
> > It suggests there's no way that she uses her favorite images instead
> > of the ones Emacs provides.
> 
> Didn't you all understand my funny English?

It's not as bad as my Japanese ;-). Having lived in Germany for four
years, I have grown to appreciate the efforts of non-native speakers, so
don't worry. We would not get too far on my Japanese which is Please,
Thank You, Excuse Me, and the symbol on the men's toilet.

Domo!

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

Re: gmm-image-load-path-for-library redux

[Bill Wohler]

Bill Wohler <wohler@newt.com> wrote:

> Katsumi Yamaoka <yamaoka@jpl.org> wrote:
> 
> > > Here is a reworked function that seems to do what everybody wants (and
> > > hopefully doesn't take an hour to understand ;-). What do you think?
> > 
> > That's skillful!  But it was easy to understand.  It also solves
> > the problem I mentioned above (the case that Gnus is installed
> > separately with the default configuration).  Could you install
> > it in Emacs?
> 
> I'll do that first thing in the morning, California time. Thanks for
> pointing out this problem in the code and for reviewing my code.

Done. Thanks again for the feedback.

I hope it's finished now ;-).

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD
Maintainer of comp.mail.mh FAQ and MH-E. Vote Libertarian!
If you're passed on the right, you're in the wrong lane.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642