headers
Katsumi Yamaoka | 1 Sep 2004 02:08
X-Face
Favicon
Gravatar

Re: Use of <at> insertcopying breaks gnus-manual*.ps.gz

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

> the use of  <at> copying and  <at> insertcopying in gnus.texi breaks the built
> of gnus-manual-a4.ps.gz and gnus-manual-standard.ps.gz.

> Probably texi2latex.el has to be adjusted, but I couldn't figure out
> how.

> Could someone please look into this?

Although I'm not troubled with it because of using Emacs CVS,  I
noticed ` <at> copying' is not supported by texinfmt.el in Emacs 21.3
and lesser and XEmacs.

configure
cd texi
make MAKEINFO=no EMACS=emacs-21.3
[...]
Formatting Info file: gnus
Converting gnus.texi to Info format...
Reading included file: gnus/texi/gnus-news.texi
Reading included file: gnus/texi/gnus-faq.texi
 <at> copying is not handled by texinfo
make: *** [gnus] Error 255

It may not be a real problem since most people seem to have the
makeinfo command.

(I'm translating the Gnus manuals into Japanese.  Using
 texinfmt.el is the only way to format them, though.)
(Continue reading)

Permalink | Reply | 7 comments |
headers
Katsumi Yamaoka | 1 Sep 2004 04:06
X-Face
Favicon
Gravatar

Re: Use of <at> insertcopying breaks gnus-manual*.ps.gz

>>>>> In <b9yvfeyyhnv.fsf <at> jpl.org> Katsumi Yamaoka wrote:

> I noticed ` <at> copying' is not supported by texinfmt.el in Emacs 21.3
> and lesser and XEmacs.

Okay, I've solved it in No Gnus by adding  <at> copying and
 <at> insertcopying support to infohack.el.
Permalink | Reply | 5 comments |
headers
Katsumi Yamaoka | 1 Sep 2004 06:33
X-Face
Favicon
Gravatar

Re: Use of <at> insertcopying breaks gnus-manual*.ps.gz

>>>>> In <b9yvfeyyhnv.fsf <at> jpl.org> Katsumi Yamaoka wrote:

> In addition, I'm using makeinfo v4.6 and it complains as follows:

> gnus.texi:8543: warning: eacute is an invalid ISO code, using '.
> gnus.texi:8543: warning: agrave is an invalid ISO code, using `.

[...]

I upgraded makeinfo to v4.7 and those warnings disappeared.
Permalink | Reply | 0 comments |
headers
Kai Grossjohann | 1 Sep 2004 10:13
Picon

emacs-w3m and colors

I use emacs-w3m to display HTML messages.  Very nice.  But it doesn't
show text colors.  Is there a way to get text colors with emacs-w3m?

(People have started to say "I have inserted my comments below, in
red.".)

Kai
Permalink | Reply | 3 comments |
headers
Simon Josefsson | 1 Sep 2004 10:53

Re: S/MIME support

Ulf Stegemann <ulf <at> zeitform.de> writes:

> Regarding that, is it worth it to think about improving Gnus' S/MIME
> capabilities?  Are there plans to do so?  Or is it all a very bad idea and
> are there more important things to do?

I think it would be useful to enhance it.  However, I believe the
first step toward making the support better is to replace OpenSSL with
the S/MIME implementation in the development versions of GnuPG; gpgsm.
I don't think OpenSSL is a good idea.  I believe gpgsm can help with
the key management issues you mention as well.
Permalink | Reply | 6 comments |
headers
Katsumi Yamaoka | 1 Sep 2004 11:44
X-Face
Favicon
Gravatar

[emacs-w3m:07076] Re: emacs-w3m and colors

>>>>> In <86eklmz9rw.fsf <at> ketchup.de.uu.net> Kai Grossjohann wrote:

> I use emacs-w3m to display HTML messages.  Very nice.  But it doesn't
> show text colors.  Is there a way to get text colors with emacs-w3m?

> (People have started to say "I have inserted my comments below, in
> red.".)

Thank you for trying emacs-w3m.  Unfortunately there is no way to
show text colors.  Showing italic text cannot be done, either.
Currently emacs-w3m shows only faces defined by `defface' in w3m.el
(which see).  We will have to much improve both w3m and emacs-w3m
in order to make it possible.
Permalink | Reply | 0 comments |
headers
Daniel Pittman | 1 Sep 2004 11:39
Gravatar

Re: emacs-w3m and colors

On 1 Sep 2004, Kai Grossjohann wrote:
> I use emacs-w3m to display HTML messages.  Very nice.  But it doesn't
> show text colors.  Is there a way to get text colors with emacs-w3m?

I have not found it, sadly.  Also, italics are also lost, to my
occasional displeasure.

It would be very nice if the developers extended their semi-parsed
output to include those details, though, since that is the layer at
which the information is omitted as far as I could determine.

None of the w3m variants available in Debian[1] emit those codes, since
I actually went and checked a few months ago.

> (People have started to say "I have inserted my comments below, in
> red.".)

...this, of course, is why HTML mail is so evil.  All the world can see
the difference between arbitrary colours, right?  *sigh*

    Daniel

Footnotes: 
[1]  w3m, w3mmee, and the third variants seems to have departed these
     days. 

--

-- 
We should never create by law what can be accomplished by morality.
        -- Montesquieu
(Continue reading)

Permalink | Reply | 0 comments |
headers
Simon Josefsson | 1 Sep 2004 16:50

Re: Sync of Gnus with Emacs

Reiner Steib <4.uce.03.r.s <at> nurfuerspam.de> writes:

> - Post a message in this thread that you have checked (and installed)
>   your changes.

I've back ported a bunch of fixes from HEAD to the v5-10 branch.  I
believe the only non-trivial part was the change of canlock.el and
sha1-el.el, which mostly was done to remove the use of OpenSSL.  The
code has been untouched on HEAD for several months, so I believe it is
safe though.  Of course, if someone feels otherwise, just revert that
part.

If somebody is syncing this with Emacs CVS, I think sha1-el.el should
be renamed to sha1.el, and the callers updated.  The old name doesn't
make sense now that sha1.el isn't around.  (The story used to be that
sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
latter which used dynamically loaded Emacs modules.)

I was worried that some Emacs20->21 fixes in HEAD might accidentally
been committed to v5-10 (which should work on Emacs 20 as well, IIUC),
but I was able to build v5-10 using emacs20, so I guess it is fine.
Permalink | Reply | 0 comments |
headers
Reiner Steib | 1 Sep 2004 18:04
X-Face
Picon
Favicon

Re: Sync of Gnus with Emacs

On Wed, Sep 01 2004, Simon Josefsson wrote:

> I've back ported a bunch of fixes from HEAD to the v5-10 branch.

Thanks.

> If somebody is syncing this with Emacs CVS, I think sha1-el.el should
> be renamed to sha1.el, and the callers updated.  The old name doesn't
> make sense now that sha1.el isn't around.  (The story used to be that
> sha1.el was a generic front end to sha1-el.el and sha1-dl.el, the
> latter which used dynamically loaded Emacs modules.)

The file is already in the gnus-5_10-branch of Emacs, but not in the
trunk, yet.  Miles offered to do the merge, maybe he can consider
this.

I think renaming it is okay (but IMHO it should be renamed in Gnus'
repository, too).

Bye, Reiner.
--

-- 
       ,,,
      (o o)
---ooO-(_)-Ooo---  |  PGP key available  |  http://rsteib.home.pages.de/
Permalink | Reply | 0 comments |
headers
Oystein Viggen | 1 Sep 2004 11:04
X-Face

Re: growing nnmaildir and intolerable gnus slowness

* [David Wuertele] 

> As my nnmaildirs grow in size, gnus gets slower and slower.
> Strangely, it isn't when I enter a nnmaildir group from the Groups
> page that is slow.  It is when I *quit* the nnmaildir group to go back
> to the Groups page that things take forever.

I used to see this also in large nnml groups, and traced it to
gnus-summary-expire-articles.  My not-really-a-solution:

;; remember to run M-x gnus-group-expire-all-groups once in a while,
;; or no articles will ever be expired..
(remove-hook 'gnus-summary-prepare-exit-hook 'gnus-summary-expire-articles)

;; I also run expire from the gnus-demon, every four hour or so:
(gnus-demon-add-handler 'gnus-group-expire-all-groups 240 t)
(gnus-demon-init)

Øystein
--

-- 
Ebg13 arire tbrf bhg bs fglyr..
Permalink | Reply | 1 comment |

Gmane