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

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: New GNOME icons

[Miles Bader]

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

Ok, I've done it.

-miles

-- 
"Though they may have different meanings, the cries of 'Yeeeee-haw!' and
 'Allahu akbar!' are, in spirit, not actually all that different."

Re: New GNOME icons

[Bill Wohler]

Miles Bader <miles@gnu.org> writes:

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

Thank you.

> "Though they may have different meanings, the cries of 'Yeeeee-haw!' and
>  'Allahu akbar!' are, in spirit, not actually all that different."

ROTFL!

-- 
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 <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: defvars at compile time

[Katsumi Yamaoka]

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

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

>> (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

I usually do this:

  (when (boundp 'image-load-path)
    (symbol-value 'image-load-path))

Re: defvars at compile time

[Kevin Rodgers]

Katsumi Yamaoka wrote:
>>>>>>In <7035.1142372131@olgas.newt.com> Bill Wohler wrote:
> 
> 
>>Reiner Steib <reinersteib+gmane@imap.cc> wrote:
> 
> 
>>>(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
> 
> 
> I usually do this:
> 
>   (when (boundp 'image-load-path)
>     (symbol-value 'image-load-path))

Would using this also quiet the compiler?

(defmacro symbol-value-safe (symbol)
   "Return SYMBOL's value, but avoid signaling an error if it is void.
If SYMBOL is void, return nil."
   (let ((temp-symbol (make-symbol "temp-symbol")))
     `(let ((,temp-symbol ,symbol))
        (if (boundp ,temp-symbol)
            (symbol-value ,temp-symbol)))))

(macroexpand '(symbol-value-safe 'image-load-path))
=>
(let ((temp-symbol (quote image-load-path)))
   (if (boundp temp-symbol) (symbol-value temp-symbol)))

-- 
Kevin Rodgers

Re: defvars at compile time

[Johan Bockgård]

Kevin Rodgers <ihs_4664@yahoo.com> writes:

> (defmacro symbol-value-safe (symbol)
>   "Return SYMBOL's value, but avoid signaling an error if it is void.
> If SYMBOL is void, return nil."
[...]

,----[ C-h f bound-and-true-p RET ]
| bound-and-true-p is a Lisp macro in `bindings.el'.
| (bound-and-true-p VAR)
| 
| Return the value of symbol VAR if it is bound, else nil.
`----

-- 
Johan Bockgård

Re: defvars at compile time

[Bill Wohler]

bojohan+news@dd.chalmers.se (Johan Bockgård) writes:

> Kevin Rodgers <ihs_4664@yahoo.com> writes:
>
>> (defmacro symbol-value-safe (symbol)
>>   "Return SYMBOL's value, but avoid signaling an error if it is void.
>> If SYMBOL is void, return nil."
> [...]
>
> ,----[ C-h f bound-and-true-p RET ]
> | bound-and-true-p is a Lisp macro in `bindings.el'.
> | (bound-and-true-p VAR)
> | 
> | Return the value of symbol VAR if it is bound, else nil.
> `----

Nice. Too bad it's not available in XEmacs (21).

Funny name. Seems like value-if-bound would be more accurate.

-- 
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: defvars at compile time

[Miles Bader]

Bill Wohler <wohler@newt.com> writes:
> Funny name. Seems like value-if-bound would be more accurate.

Yeah.  Or "bound-value".

Emacs is full of slightly bizarre function names, typically where the
original creator only thought of one particular special usage (and named
the function accordingly) but the actual users turned out to treat it
more generally.

Luckily we've got "defalias" to make renaming less painful...

-Miles
-- 
"Unless there are slaves to do the ugly, horrible, uninteresting work, culture
and contemplation become almost impossible. Human slavery is wrong, insecure,
and demoralizing.  On mechanical slavery, on the slavery of the machine, the
future of the world depends." -Oscar Wilde, "The Soul of Man Under Socialism"

Re: defvars at compile time

[Richard Stallman]

    > Funny name. Seems like value-if-bound would be more accurate.

    Yeah.  Or "bound-value".

The name was not chosen carefully because this was not intended as
an advertised facility.

If we want to make it one, I suggest the name symbol-value-safe.  Like
car-safe.

Re: defvars at compile time

[Stefan Monnier]

>>> (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

How/when do you see this?  Emacs-21 should complain indeed, but Emacs-CVS
shouldn't (because it recognizes the (if (boundp ..) ..) form).

> I usually do this:
>   (when (boundp 'image-load-path)
>     (symbol-value 'image-load-path))

Since (symbol-value 'foo) is equivalent to just `foo' the change may work
for some versions of the byte-compiler (which doesn't optimize one form into
the other) but not for others.  I.e. it's a bad solution.


        Stefan

Re: defvars at compile time

[Katsumi Yamaoka]

>>>>> In <87fyldk4tx.fsf-monnier+emacs@gnu.org> Stefan Monnier wrote:

>>>> (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

> How/when do you see this?

This is continuation of the thread:

http://news.gmane.org/group/gmane.emacs.gnus.general/thread=62179

And I esteemed Reiner Steib's `Mail-Followup-To: emacs-devel'
(http://article.gmane.org/gmane.emacs.gnus.general/62266).

> Emacs-21 should complain indeed, but Emacs-CVS
> shouldn't (because it recognizes the (if (boundp ..) ..) form).

Yes it is.  But Gnus CVS supports Emacs 21 and XEmacs, so we
have to do something to avoid a compile warning.

>> I usually do this:
>>   (when (boundp 'image-load-path)
>>     (symbol-value 'image-load-path))

> Since (symbol-value 'foo) is equivalent to just `foo' the change may work
> for some versions of the byte-compiler (which doesn't optimize one form into
> the other) but not for others.

It relies on just Emacs 21's compiler and XEmacs' compiler.

> I.e. it's a bad solution.

I think the reason it is bad is only that it might take more
time than directly referring the value of the variable.
Therefore, we should not use such a countermeasure if a program
uses it frequently.  However, if not, I feel it is not very ugly
rather than putting `(eval-when-compile (defvar variable))' here
and there.  Did I overlook something?

Re: defvars at compile time

[Stefan Monnier]

>> Emacs-21 should complain indeed, but Emacs-CVS
>> shouldn't (because it recognizes the (if (boundp ..) ..) form).

> Yes it is.  But Gnus CVS supports Emacs 21 and XEmacs, so we
> have to do something to avoid a compile warning.

Well, I'd have to strongly disagree with "have to".  Nothing forces you to
remove all compilation warnings for all supported emacsen.

>> I.e. it's a bad solution.
> I think the reason it is bad is only that it might take more
> time than directly referring the value of the variable.

It's much worse than that.  It's fundamentally wrong to make code less
readable for the sake of compiler warnings.  Compiler warnings are there to
help you find bad code and improve it.  Not to make code uglier and harder
to maintain.  The primacy should be with the code, not with the
compiler warnings.


        Stefan

Re: defvars at compile time

[Bill Wohler]

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

>>> Emacs-21 should complain indeed, but Emacs-CVS
>>> shouldn't (because it recognizes the (if (boundp ..) ..) form).
>
>> Yes it is.  But Gnus CVS supports Emacs 21 and XEmacs, so we
>> have to do something to avoid a compile warning.
>
> Well, I'd have to strongly disagree with "have to".  Nothing forces you to
> remove all compilation warnings for all supported emacsen.

Not in Emacs perhaps, but MH-E conventions require it. And I'd argue
that it should be required in Emacs as well.

>>> I.e. it's a bad solution.
>> I think the reason it is bad is only that it might take more
>> time than directly referring the value of the variable.
>
> It's much worse than that.  It's fundamentally wrong to make code less
> readable for the sake of compiler warnings.  Compiler warnings are there to
> help you find bad code and improve it.

Assuming you find the warning. The problem with a forest of compiler
warnings is that warnings you might want to see are hidden. Because
MH-E code compiles clean, if an error or warning appears, it stands
out loud and clear.

Asking how to write code that doesn't generate compiler warnings is a
legitimate question. If you can suggest a clean way to do this, we'll
do 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: defvars at compile time

[Stefan Monnier]

>> Well, I'd have to strongly disagree with "have to".  Nothing forces you to
>> remove all compilation warnings for all supported emacsen.
> Not in Emacs perhaps, but MH-E conventions require it.

Well, that's your choice, of course.

> And I'd argue that it should be required in Emacs as well.

I'd strongly oppose it.  I could OTOH accept a policy that Emacs packages
should not output any warning when compiled with the Emacs version that they
come with.  Because then we have a lot more freedom to fix the problematic
warning either in the package, or in byte-compiler, or ...

>> It's much worse than that.  It's fundamentally wrong to make code less
>> readable for the sake of compiler warnings.  Compiler warnings are there to
>> help you find bad code and improve it.
> Assuming you find the warning.  The problem with a forest of compiler
> warnings is that warnings you might want to see are hidden.  Because
> MH-E code compiles clean, if an error or warning appears, it stands
> out loud and clear.

That doesn't contradict what I said.

> Asking how to write code that doesn't generate compiler warnings is a
> legitimate question. If you can suggest a clean way to do this, we'll
> do it.

As mentioned, for your original problem, the byte-compiler was fixed so it
doesn't generate a warning for this code any more.  For that particular
problem, it is *the* clean way to fix the warning.  If you want to eliminate
the warning without allowing yourself this clean fix (e.g. by insisting
dogmatically that all warnings must go, even when compiling with some older
byte-compiler), you'll end up with uglier and less maintainable code.


        Stefan

Re: defvars at compile time

[Richard Stallman]

      It's fundamentally wrong to make code less
    readable for the sake of compiler warnings.  Compiler warnings are there to
    help you find bad code and improve it.  Not to make code uglier and harder
    to maintain.  The primacy should be with the code, not with the
    compiler warnings.

Hear, hear!

Re: defvars at compile time

[Richard Stallman]

    I'd strongly oppose it.  I could OTOH accept a policy that Emacs packages
    should not output any warning when compiled with the Emacs version that they
    come with.

We are more or less aiming for that, with the help of with-no-warnings
(which I added for this purpose), and we have removed nearly all of
the warnings that we used to have.  However, there are a few warnings
that are rather hard to remove.  And a few files use obsolete
constructs for backward compatibility.

    As mentioned, for your original problem, the byte-compiler was fixed so it
    doesn't generate a warning for this code any more.  For that particular
    problem, it is *the* clean way to fix the warning.  If you want to eliminate
    the warning without allowing yourself this clean fix (e.g. by insisting
    dogmatically that all warnings must go, even when compiling with some older
    byte-compiler), you'll end up with uglier and less maintainable code.

I agree with you.