emacs-pretest-bug
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnus issues


From: Reiner Steib
Subject: Re: Gnus issues
Date: Wed, 29 Sep 2004 23:52:55 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/21.3.50 (gnu/linux)

On Mon, Sep 27 2004, Dave Love wrote:

> Most of these things are shown up by compilation warnings, which it
> seems people aren't getting attention.  (It seems more sane to bundle
> these together rather than making individual reports.)

Jesper Harder's recent changes fixed some of the issues you reported,
AFAICS.

> The use of `caddr' in gnus-diary.el should be replaced (or use CL).
>
> gnus-picon.el uses `ignore-errors' without CL.

Fixed by Jesper's change.

> gnus.el needs to require message when compiling (for macro
> `message-y-or-n-p').

This part of `gnus-read-group' is used rarely.  Wouldn't ...
  (autoload 'message-y-or-n-p "message" nil nil 'macro)
... be sufficient?

> imap.el uses `assert' incorrectly -- I guess the second arg should be
> nil.

I will replace "(assert (eq (char-after) ?\)) t" with
"(assert (eq (char-after) ?\)) nil".

> mailcap.el shouldn't define non-Lisp methods in
> `mailcap-custom-mime-data'.  They should be picked up from the system
> mailcap file, so that Emacs is consistent with other programs.
> (That's especially relevant on Debian, where /etc/mailcap reflects the
> programs actually installed.)  Then it's probably worth customizing
> the variable.  [I should have sorted this out in the past...]

There has been some discussion related to this on the Gnus list some
time ago in the thread "Disable mailcap support", see the following
references:

<URL:http://thread.gmane.org/gmane.emacs.gnus.general/54148>
<URL:http://thread.gmane.org/gmane.emacs.gnus.general/54091>

Lars did like the suggestion to remove the fall-back entries:

,----<URL:http://article.gmane.org/gmane.emacs.gnus.general/54255>
| The point of the fall-backs is that Gnus should just work.  If
| somebody sent you a jpeg, you should be able to view it without
| having to do anything in particular.
`----

> mml-smime.el needs to require cl when compiling.
>
> nnml.el and nnfolder.el call assert and error incorrectly.

Fixed by Jesper's change.

> pop3.el shouldn't use nnheader-accept-process-output, so it can be
> used outside Gnus.  It should probably define its own function as a
> copy of that.

It would need `nnheader-read-timeout', too.

> It can assume md5 is available, 

We are planning to keep the stable Gnus branch (v5-10) and Gnus in
Emacs in sync and make bugfix releases (starting with Gnus 5.10.7)
from that branch.  As Gnus 5.10.* should run on Emacs 20.7 and Emacs
21.[1-3], I think we must keep this.

> and I think its user variables should be customized.

Agreed.  Any volunteer?

> I think the bizarre `(if (> (buffer-size)...' clauses in `pop3-retr'
> can safely be removed -- I've run without them for some time.

I found nothing but the following (quite old) article on this:

,----
| From: address@hidden
| Subject: vm-pop and NTemacs heap
| newsgroups: gnu.emacs.vm.bug
| Date: 1996/12/30
| Message-ID: <address@hidden>
| reply-to: address@hidden (WJCarpenter)
`----

Maybe we should disable the `sleep-for' stuff by default, but keep the
code in case some users need it:

,----
| (defvar pop3-delay-on-large-messages nil)
| [...]
|       (when pop3-delay-on-large-messages
|         ;; address@hidden ... to save wear and tear on the heap
|         ;; uncommented because the condensed version below is a problem for
|         ;; some.
|         (if (> (buffer-size)  20000) (sleep-for 1))
|         [...]
|         (if (> (buffer-size) 500000) (sleep-for 1)))
`----

> rfc2047.el should autoload `mm-qp-or-base64'.

I cannot find `mm-qp-or-base64' in `rfc2047.el':

,----
| grep -nH -e mm-qp-or-base64 *.el
| mm-bodies.el:155:                       (mm-qp-or-base64))))
| mm-encode.el:177:                         (mm-qp-or-base64)
| mm-encode.el:184:(defun mm-qp-or-base64 ()
`----

> spam.el calls error incorrectly.

Fixed by Jesper's change.

> In mml.el, I think the second and third calls of `completing-read'
> should have t for the fourth arg (REQUIRE-MATCH) since only the listed
> completions are meaningful.  I tend to type `a RET' and expect it to
> complete to `attachment', but it just makes the mml stuff in the
> buffer invalid.

[ See my other reply. ]

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]