Re: Gnus issues

[Dave Love <fx@gnu.org>]

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

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

Sorry, I thought I had current source.

>> 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?

Well, I'd expect all macros to be compiled out, but I see that
message-y-or-n-p calls another message function which will have to be
autoloaded, so I guess autoloading the macro is reasonable.

> 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.
> `----

My point is that that's likely not the effect it has.  Suppose I don't
have `display' or `ee' (whatever that is) installed, but do have
`xloodimage'; then I lose in Emacs (especially as mailcap doesn't test
whether a viewer is actually installed).  With another program that
doesn't override the system mailcap, viewing the image works on a
properly-configured Debian system.  Also, the viewers in mailcap.el
normally won't work under Windows.  The system mailcap is likely to be
right, and mailcap.el is likely to be wrong, as it is for me.

[Emacs isn't even internally consistent, e.g. gnus-audio.el looks for
`play', which isn't in mailcap.el.  Lisp that wants to select a
program like that should ask mailcap for one (that exists).]

By the way, the mailcap list should at least be purged of proprietary
programs; I spotted `acroread', but I don't know what everything in
the list is.

>> 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?

> 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.

Oh.  I thought support for Emacs 20 had been dropped.  I didn't
realize that branch was being maintained, either.  It was dead last
time I looked, and I couldn't get help with bugs in it.  Should
reports go to bugs@gnus or emacs-pretest-bug?

> 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:

I'm sure it should be disabled -- it made downloading a pop mailbox
pretty painful for me, and the explanation in that message doesn't
make any sense to me.  (Thanks for finding that -- I think I'd looked
for an explanation without luck.)

>> 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))))