Re: Gnus issues

Re: Gnus issues

[Reiner Steib]

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/

Re: Gnus issues

[Katsumi Yamaoka]

>>>>> In <v9oejorbd4.fsf@marauder.physik.uni-ulm.de> Reiner Steib wrote:

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

Re: Gnus issues

[Dave Love]

Katsumi Yamaoka <yamaoka@jpl.org> writes:

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

Re: Gnus issues

[Jesper Harder]

Dave Love <fx@gnu.org> writes:

> Katsumi Yamaoka <yamaoka@jpl.org> writes:
>
>> 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.


It was changed months ago in Gnus CVS:

2004-02-09  Jesper Harder  <harder@ifa.au.dk>

	* rfc2047.el (rfc2047-qp-or-base64): New function to reduce
	dependencies.
	(rfc2047-encode): Use it.

-- 
Jesper Harder                                <http://purl.org/harder/>

Re: Gnus issues

[Reiner Steib]

On Fri, Oct 08 2004, Jesper Harder wrote:

> Dave Love <fx@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.

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

Re: Gnus issues

[Dave Love]

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

Re: Gnus issues

[Simon Josefsson]

Dave Love <fx@gnu.org> writes:

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

I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus CVS

Re: Gnus issues

[Steve Youngs]

[-- Attachment #1: Type: text/plain, Size: 517 bytes --]

* Simon Josefsson <jas@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). 

-- 
|---<Steve Youngs>---------------<GnuPG KeyID: A94B3003>---|
|                   Te audire no possum.                   |
|             Musa sapientum fixa est in aure.             |
|----------------------------------<steve@youngs.au.com>---|

[-- Attachment #2: Type: application/pgp-signature, Size: 256 bytes --]

Re: Gnus issues

[Edward O'Connor]

 SJ> I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus
 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
ted@oconnor.cx

Ense petit placidam sub libertate quietem.

Re: Gnus issues

[Simon Josefsson]

Steve Youngs <steve@youngs.au.com> writes:

> * Simon Josefsson <jas@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"))

Re: Gnus issues

[Miles Bader]

Steve Youngs <steve@youngs.au.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). 

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)

Re: Gnus issues

[Richard Stallman]

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

    I've removed acroread, and added gpdf (GNOME PDF Viewer), in Gnus CVS

Thanks.

Re: Gnus issues

[Katsumi Yamaoka]

>>>>> In <rzqr7ojs951.fsf@albion.dl.ac.uk> Dave Love wrote:

>>> 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  <harder@ifa.au.dk>
[...]
	* rfc2047.el (rfc2047-qp-or-base64): New function to reduce
	dependencies.
	(rfc2047-encode): Use it.

Re: Gnus issues

[Reiner Steib]

On Fri, Oct 01 2004, Dave Love wrote:

> Reiner Steib <reinersteib+gmane@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.)

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

Re: Gnus issues

[Dave Love]

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

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

Re: Gnus issues

[Reiner Steib]

On Wed, Sep 29 2004, Reiner Steib wrote:

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

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

Re: Gnus issues

[Dave Love]

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

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

Re: Gnus issues

[Simon Josefsson]

Dave Love <fx@gnu.org> writes:

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