bug#9831: cause of bug found! [PATCH]

[martin rudalics]

>     Because this bug doesn't occur in Emacs 22, I compared to that code's
> version of rmail-summary:

I'm not convinced that the issue you see is related to that reported by
the OP.  But since I'm not familiar with rmail could you please explain
to me what happens and what should happen below.

> [Rmail 22]
> (defun rmail-summary ()
>   "Display a summary of all messages, one line per message."
>   (interactive)
>   (rmail-new-summary "All" '(rmail-summary) nil))
>
> [Rmail 23.3]
> (defun rmail-summary ()
>   "Display a summary of all messages, one line per message."
>   (interactive)
>   (rmail-new-summary "All" '(rmail-summary) nil)
>   (unless (get-buffer-window rmail-buffer)
>     (rmail-summary-beginning-of-message)))
>
>
>     As you can see, some well-meaning person added the functionality of
> move-to-start-of-message to the display summary command ('h') and broke
> rmail-output and associated functions.  I checked and none of the other
> summary generating functions (e.g., rmail-summary-by-labels) have this
> functionality (added).

I seem to understand that you show in some window a buffer called
rmail-buffer, presumably containing some messages you read.  Now you
want to produce a summary in a buffer called rmail-summary-buffer and do
this by invoking the command `rmail-summary'.  That command winds up by
calling `rmail-summary-show-message' which does `rmail-pop-to-buffer' on
rmail-buffer (I don't understand why it does do that).  Anyway, since
that buffer already appears on some window, `rmail-summary-show-message'
should in principle reuse that window and IIUC not change that window's
point, i.e., not change what you see in that window.

But if my summary is correct then

  (rmail-new-summary "All" '(rmail-summary) nil)

should always make sure that rmail-buffer appears in some window and the
test coming next

  (unless (get-buffer-window rmail-buffer)
    (rmail-summary-beginning-of-message)))

should always fail (unless rmail-buffer is shown on another frame) so no
such deliberate movement should occur.

However, my summary apparently fails to tell what you see, so could you
please tell me what happens instead and why?

And, as mentioned above, I don't understand how what you describe here
corresponds to the bug reported by John: His seems a problem with the
command invoked by typing `o' yours when typing `h'.

martin