Re: Gnus issues
Reiner Steib
> 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: bi...@attmail.com
| Subject: vm-pop and NTemacs heap
| newsgroups: gnu.emacs.vm.bug
| Date: 1996/12/30
| Message-ID: <961230201...@lynxhub.ho.att.com>
| reply-to: bi...@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
| ;; bi...@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/
Katsumi Yamaoka
> On Mon, Sep 27 2004, Dave Love wrote:
>> rfc2047.el should autoload `mm-qp-or-base64'.
> I cannot find `mm-qp-or-base64' in `rfc2047.el':
Probably, Dave said `mm-qp-or-base64' is mostly equal to
`rfc2047-qp-or-base64'.
Steve Youngs
> I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus
> CVS
Just curious as to why you chose gpdf instead of xpdf? I would have
thought the latter was still more common (says he who doesn't have
gpdf).
--
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
| Te audire no possum. |
| Musa sapientum fixa est in aure. |
|----------------------------------<st...@youngs.au.com>---|
Katsumi Yamaoka
>>> rfc2047.el should autoload `mm-qp-or-base64'.
>>
>> I cannot find `mm-qp-or-base64' in `rfc2047.el':
> rfc2047-encode:
> ;; For the charsets that don't have a preferred
> ;; encoding, choose the one that's shorter.
> (save-restriction
> (narrow-to-region b e)
> (if (eq (mm-qp-or-base64) 'base64)
> 'B
> 'Q))))
You may want to CVS update Gnus.
2004-09-26 Jesper Harder <har...@ifa.au.dk>
[...]
* rfc2047.el (rfc2047-qp-or-base64): New function to reduce
dependencies.
(rfc2047-encode): Use it.
Simon Josefsson
> * Simon Josefsson <j...@extundo.com> writes:
>
> > I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus
> > CVS
>
> Just curious as to why you chose gpdf instead of xpdf? I would have
> thought the latter was still more common (says he who doesn't have
> gpdf).
xpdf was already present. Below are all pdf entries. Btw, would it
make things more reliable if the test predicate also include a
(excutable-find "xpdf") etc? Perhaps the code already do that test
elsewhere, though.
("pdf"
(viewer . "gv -safer %s")
(type . "application/pdf")
(test . window-system)
("print" . ,(concat "pdf2ps %s - | " mailcap-print-command)))
("pdf"
(viewer . "gpdf %s")
(type . "application/pdf")
("print" . ,(concat "pdftops %s - | " mailcap-print-command))
(test . (eq window-system 'x)))
("pdf"
(viewer . "xpdf %s")
(type . "application/pdf")
("print" . ,(concat "pdftops %s - | " mailcap-print-command))
(test . (eq window-system 'x)))
("pdf"
(viewer . ,(concat "pdftotext %s -"))
(type . "application/pdf")
("print" . ,(concat "pdftops %s - | " mailcap-print-command))
("copiousoutput"))
Miles Bader
> > I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus
> > CVS
>
> Just curious as to why you chose gpdf instead of xpdf? I would have
> thought the latter was still more common (says he who doesn't have
> gpdf).
I think xpdf is actually also a rather nicer program than gdpf (gpdf has
attractive widgets, I keep _wanting_ to use it -- but I always end up
going back to xpdf because it's simply more functional).
-Miles
--
Saa, shall we dance? (from a dance-class advertisement)
Edward O'Connor
SJ> CVS
SY> Just curious as to why you chose gpdf instead of xpdf? I would have
SY> thought the latter was still more common (says he who doesn't have
SY> gpdf).
Exactly my question (and predicament).
Ted
--
Edward O'Connor
t...@oconnor.cx
Ense petit placidam sub libertate quietem.
Reiner Steib
> Reiner Steib <reinerst...@imap.cc> writes:
[...]
>>> 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.
>
> I assumed that would be a pop3- variable, but I don't understand its
> purpose anyway -- why is it different on Windows?
IIRC, values lower than 1.0 didn't work on Windows. Does anyone
remember any details? (There should probably be a comment in the
source to explain the purpose.)
Richard Stallman
> programs; I spotted `acroread', but I don't know what everything in
> the list is.
I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus CVS
Thanks.
Dave Love
> Probably, Dave said `mm-qp-or-base64' is mostly equal to
> `rfc2047-qp-or-base64'.
Sorry, I don't understand that. It looks as if there was confusion
because someone had changed the source after I reported it.
Dave Love
> IIRC, values lower than 1.0 didn't work on Windows. Does anyone
> remember any details? (There should probably be a comment in the
> source to explain the purpose.)
Yes to the comment.
If this matters, there should probably be a runtime test to determine
the timing resolution, or a primitive to report it. I don't know
off-hand what's possible. Perhaps better, maybe the Windows/DOS
primitive could round up non-zero timeouts to a minimum of 1.0?
Jesper Harder
It was changed months ago in Gnus CVS:
2004-02-09 Jesper Harder <har...@ifa.au.dk>
* rfc2047.el (rfc2047-qp-or-base64): New function to reduce
dependencies.
(rfc2047-encode): Use it.
--
Jesper Harder <http://purl.org/harder/>
Reiner Steib
> Dave Love <f...@gnu.org> writes:
>> It looks as if there was confusion because someone had changed the
>> source after I reported it.
>
> It was changed months ago in Gnus CVS: [...]
Dave was looking at the version in Emacs CVS where the your fixes
weren't present at the time of his report (or they went in only one
day before).
Let's concentrate on the issues in Dave's report that are not resolved
yet.
Reiner Steib
> On Mon, Sep 27 2004, Dave Love wrote:
[...]
> This part of `gnus-read-group' is used rarely. Wouldn't ...
> (autoload 'message-y-or-n-p "message" nil nil 'macro)
> ... be sufficient?
Committed. (In the v5-10 branch of Gnus. Should appear in Emacs in
the next days.)
> I will replace "(assert (eq (char-after) ?\)) t" with
> "(assert (eq (char-after) ?\)) nil".
Committed.
[ pop3 ]
>> and I think its user variables should be customized.
Committed. I have created a new group:
(defgroup pop3 nil
"Post Office Protocol"
:group 'mail
:group 'mail-source)
I left `pop3-password' as a defvar. Could you please check if my
changes are correct (I don't use pop3)?
>> I think the bizarre `(if (> (buffer-size)...' clauses in `pop3-retr'
>> can safely be removed -- I've run without them for some time.
Committed.
Dave Love
> I left `pop3-password' as a defvar.
I think that's right, though I don't know if the code can cope with
multiple POP servers as it should.
> Could you please check if my
> changes are correct (I don't use pop3)?
I'll try to sometime. Actually, I don't usually use it these days.
It seems it still uses nnheader-accept-process-output, which it
shouldn't. A reasonable solution to that, which I should probably
have used elsewhere before, is to compile it away. nnheader could
just be required at compile time if nnheader-accept-process-output is
made a defsubst (with a comment about why).
Simon Josefsson
> It seems it still uses nnheader-accept-process-output, which it
> shouldn't. A reasonable solution to that, which I should probably
> have used elsewhere before, is to compile it away. nnheader could
> just be required at compile time if nnheader-accept-process-output is
> made a defsubst (with a comment about why).
n-a-p-o uses a variable, nnheader-read-timeout, so if it is a
defsubst, wouldn't either the user lose the ability to customize the
variable, or that nnheader.el is loaded for the variable?
Btw, I should installed a fix to make pop3.el not depend on nnheader.
I copied the nnheader code, which may be bad, though.
OTOH, I'm not sure why we bother. The entire n-a-p-o stuff seem to be
workaround for a problem on non-unix platforms. Wouldn't it be better
if the people using those platforms fix accept-process-output to do
the right thing, instead of messing up the lisp code?
I would support using accept-process-output directly in pop3.el.