GNU bug report logs - #9831
24.0.90; o and c-o in RMAIL change buffer

Previous Next

Package: emacs;

Reported by: john ffitch <jpff <at> codemist.co.uk>

Date: Sat, 22 Oct 2011 11:11:01 UTC

Severity: normal

Found in version 24.0.90

Fixed in version 24.0.92

Done: Glenn Morris <rgm <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: mark.lillibridge <at> hp.com
Cc: 9831 <at> debbugs.gnu.org, jpff <jpff <at> codemist.co.uk>
Subject: bug#9831: cause of bug found!  [PATCH]
Date: Mon, 24 Oct 2011 11:31:59 +0200
>     Sorry, more background.  The bug OP and I am reporting is as
> follows: we have two Rmail buffers, say A and B, each with summary
> buffers.  However, only A and it's summary are displayed in windows.  We
> then output the current message from A to B via 'o'.  The bug is that at
> this point the summary for B becomes displayed when it should not.

I'm probably too silly to understand.  John was talking about "o" not
doing the right thing, but IIUC "o" calls `rmail-output' and not
`rmail-summary-output' in his case.  At least that's what I deduct from
his "When reading mail o writes the message to another file, or buffer
if it is loaded" and the doc-string of `rmail-output' saying "Append
this message to mail file FILE-NAME".  Then John says that "It also
changes to that buffer and this seriously interferes with work flow, as
it is inconsistent with when the file is not in a buffer" but
unfortunately I don't understand what "changes to that buffer" means in
this context.

Moreover, John was saying that "This seems fairly recent behaviour and
is causing significant problems" but I don't find any recent reference
to a change of `rmail-summary' in the Logs.  Finally, John nowhere
talked about point moving to some inconvenient position.  John could you
please clarify these issues?

>     Why?  The filing code updates the summary for the buffer the
> messages being filed to (e.g., B) so that it shows the message just
> added to that buffer if appropriate.  This should not cause that summary
> to be displayed but it does due to the bug.
>
>     Why?  The summary is updated via (rmail-update-summary).
> Historically, this does not cause the updated buffer to be displayed,

Can you tell me when and where this was changed?

> but because of the bug if this summary was produced by rmail-summary, it
> will be displayed.
>
>     Why? rmail-update-summary makes a saved function call (depending on
> the filtering requested, a different call is necessary to rebuild the
> summary) to update the summary.  If the summary was originally created via
> rmail-summary, then the saved call is (rmail-summary), which because of
> the bug displays the summary.
>
>     Why?  Because someone incorrectly added code to display the summary
> buffer on summary update to rmail-summary.

According to our Logs `rmail-update-summary' hasn't been changed for
many years.

>     I changed the code so that rmail-summary when called by the user
> (e.g., via 'h') does always display the summary but does not do so when
> called via rmail-update-summary.
>
>     Is this more clear?  I think the part you were unclear about is that
> there are two Rmail buffers involved, each with their own summary.

I still suppose your's is a different bug.  But I suspect that any of
these bugs may have its cause in a recent change of the buffer display
routines.  Unfortunately, I'm not of much help here since I don't use
rmail.

martin




This bug report was last modified 13 years and 249 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.