From: Reiner Steib <reinersteib+gmane@imap.cc>
Cc: emacs-pretest-bug@gnu.org, Ding List <ding@gnus.org>
Subject: Re: Gnus issues
Date: Wed, 29 Sep 2004 23:52:55 +0200 [thread overview]
Message-ID: <v9oejorbd4.fsf@marauder.physik.uni-ulm.de> (raw)
In-Reply-To: <rzqmzzbv1y2.fsf@albion.dl.ac.uk>
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: bill@attmail.com
| Subject: vm-pop and NTemacs heap
| newsgroups: gnu.emacs.vm.bug
| Date: 1996/12/30
| Message-ID: <9612302016.AA22907@lynxhub.ho.att.com>
| reply-to: bill@attmail.com (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
| ;; bill@att.com ... 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/
next parent reply other threads:[~2004-09-29 21:52 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <rzqmzzbv1y2.fsf@albion.dl.ac.uk>
2004-09-29 21:52 ` Reiner Steib [this message]
2004-09-30 3:33 ` Katsumi Yamaoka
2004-10-08 17:03 ` Dave Love
2004-10-08 17:31 ` Jesper Harder
2004-10-08 21:59 ` Reiner Steib
2004-09-30 22:07 ` Dave Love
2004-09-30 22:51 ` Simon Josefsson
2004-10-01 0:38 ` Steve Youngs
2004-10-01 2:02 ` Edward O'Connor
2004-10-01 9:14 ` Simon Josefsson
2004-10-01 13:26 ` Miles Bader
2004-10-03 14:33 ` Richard Stallman
2004-10-01 6:36 ` Katsumi Yamaoka
2004-10-02 19:09 ` Reiner Steib
2004-10-08 17:09 ` Dave Love
2004-10-10 17:50 ` Reiner Steib
2004-10-14 21:33 ` Dave Love
2004-10-14 22:46 ` Simon Josefsson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=v9oejorbd4.fsf@marauder.physik.uni-ulm.de \
--to=reinersteib+gmane@imap.cc \
--cc=Reiner.Steib@gmx.de \
--cc=ding@gnus.org \
--cc=emacs-pretest-bug@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).