gnus-button face definition gnus-art.el

Revision 7.149 of gnus-art.el introduces a face definition for
`gnus-button', which causes an error when starting Gnus.  I think it's
not quite correct; I'd propose the following patch:

Greetings

--

-- 
Michael Piotrowski, M.A.                               <mxp <at> dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: gnus-button face definition gnus-art.el

>>>>> In <x6k6bft0rx.fsf <at> eurus.mag.dynalabs.de> Michael Piotrowski wrote:

> Revision 7.149 of gnus-art.el introduces a face definition for
> `gnus-button', which causes an error when starting Gnus.  I think it's
> not quite correct; I'd propose the following patch:

I confirmed it obstructs XEmacs to start Gnus.  Thank you for
the patch.  I've installed it.

Re: spam-check-spamassassin-headers with spamassasin 3.0/3.1

Reiner Steib <reinersteib+gmane <at> imap.cc> writes:
>> `spam-check-spamassassin-headers' works fine, however
>> `spam-extra-header-to-number' doesn't.
>
> Could you try both in current CVS, please?

Both function works well. Thank you.

--

-- 
IRIE Tetsuya

read saved articles

Dear all,

I want to apologize that I have to post a question that is probably a
FAQ, but I did not find anything enlightening in Google or the Gnus
manager:

When I save a message using "o" it is saved to a Rmail file. What is
the best way to read these saved messages (without all the headers and
ideally in a thread-like structure)?

Best,

Georg

Re: read saved articles

On Wed, Mar 01 2006, Georg Otto wrote:

> When I save a message using "o" it is saved to a Rmail file. 

You can customize the variable `gnus-default-article-saver':

,----[ <f1> v gnus-default-article-saver RET ]
| gnus-default-article-saver is a variable defined in `gnus-art.el'.
| 
| Documentation:
| A function to save articles in your favourite format.
| The function must be interactively callable (in other words, it must
| be an Emacs command).
| 
| Gnus provides the following functions:
| 
| * gnus-summary-save-in-rmail (Rmail format)
| * gnus-summary-save-in-mail (Unix mail format)
| * gnus-summary-save-in-folder (MH folder)
| * gnus-summary-save-in-file (article format)
| * gnus-summary-save-body-in-file (article body)
| * gnus-summary-save-in-vm (use VM's folder format)
| * gnus-summary-write-to-file (article format -- overwrite).
| 
| You can customize this variable.
`----

> What is the best way to read these saved messages (without all the
> headers and ideally in a thread-like structure)?

Re: Customizable tool bars

On Wed, Feb 22 2006, Katsumi Yamaoka wrote:

> Reiner Steib wrote:
>> I think I will enable the new tool bars by default within the next
>> days.
>
> I think making the new feature the default is a good idea.

The new tool bars are now the default if (> (display-color-cells) 256).

For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
t on the same display.  Any ideas?

ELISP> (display-color-cells)
64
ELISP> emacs-version
"21.3.3"

ELISP> (display-color-cells)
65536
ELISP> emacs-version
"22.0.50.5"

Bye, Reiner.
--

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

Re: Customizable tool bars

Reiner Steib <reinersteib+gmane <at> imap.cc> writes:

> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

See the thread starting here:

   <URL: http://lists.gnu.org/archive/html/emacs-pretest-bug/2004-02/msg00246.html>

--

-- 
Romain Francoise <romain <at> orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Customizable tool bars

Reiner Steib <reinersteib+gmane <at> imap.cc> writes:

> The new tool bars are now the default if (> (display-color-cells) 256).
>
> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

No ideas about that, but XEmacs has `device-color-cells' instead of
`display-color-cells'.  To be able to start Gnus, I changed
gmm-utils.el like this:

I don't know whether this is the best solution, but it works for me.
I noticed that it `device-color-cells' returns 256 even though I've
got 24 bit color depth, but frankly, I don't care since I'm using my
own text-only toolbar anyway 

Greetings

--

-- 
Michael Piotrowski, M.A.                               <mxp <at> dynalabs.de>
Public key at <http://www.dynalabs.de/mxp/pubkey.txt>

Re: Customizable tool bars

>>>>> In <v9r75m12rs.fsf <at> marauder.physik.uni-ulm.de> Reiner Steib wrote:

> The new tool bars are now the default if (> (display-color-cells) 256).

> For some reason Emacs 21 returns nil for that whereas Emacs 22 returns
> t on the same display.  Any ideas?

I don't have an idea, but...

ELISP> (display-color-cells)
> 64
ELISP> emacs-version
> "21.3.3"

ELISP> (display-color-cells)
> 65536
ELISP> emacs-version
> "22.0.50.5"

In my Linux box,
Emacs 21.1, 21.2 and 21.4
 => 256
Emacs 22.0.50 and 23.0.0
 => 16777216
XEmacs 21.4.19 and 21.5-b25 (using `device-color-cells')
 => 256

Are 256 colors insufficient to display Gnome icons?

Re: image-load-path/load-path function

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

> Below is the current version including this fix.  Comments?

Reiner,

Unfortunately, I haven't been able to stimulate any discussion on the
issue about modifying or not modifying image-load-path on emacs-devel.
So I haven't heard any arguments against modifying the path, let alone
arguments that are more compelling than my own. But I think that in
order to expedite getting image-load-path (the function) into image.el
so that we can use *-defun-compat to simply alias (or define) it in our
own code, I think I'll update the MH-E code to use scoped variables in
the same way that you folks do, barring dissent from the MH-E masses.

I'll work on porting your posted version back to MH-E so that they will
be as close together as possible. If you've changed it since your post
last Wednesday, please let me know (maybe sending me the URL to the file
in your repository might be a good idea, ours is
http://cvs.savannah.gnu.org/viewcvs/emacs/lisp/mh-e/mh-utils.el?root=emacs&view=markup).

(So there will be a slight delay in the 7.93 release.)

Once our two versions are the same (modulo the prefix), I'll add a
function called "image-load-path" to image.el, although maybe we should
talk about the name first.

> (defvar gmm-image-load-path nil
>   "Directory where images are found.
> See the function `gmm-image-load-path'.")