bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss

[Stephen Berman <Stephen.Berman@rub.de>]

On Sun, 06 Mar 2011 15:28:43 -0500 Chong Yidong <cyd@stupidchicken.com> wrote:

> Stephen Berman <stephen.berman@gmx.net> writes:
>
>> I just tested this with the doc string of help-buffer in *Help*.  There
>> are two links in this doc string: clicking on `help-xref-following'
>> shows the error message "Current buffer is not in Help mode", which is
>> certainly better than overwriting the content of the buffer; but
>> clicking on `help-mode.el' finds that file and puts point on the
>> beginning of help-buffer's definition, i.e., still does what this kind
>> of link has always done.  It is confusing to have this divergence in
>> behavior between the two kinds of links.  Instead of signalling an
>> error, couldn't the help-xref-following buttons just show the help in
>> the *Help* buffer, as in the following patch?
>
> The buffer from you pasted the button might not be *Help*; it could be
> any other buffer in Help mode.  So wouldn't it be inconsistent either
> way?

Do you mean that if the button inserted[1] into a buffer A comes from a
help-mode buffer other than *Help* -- call it B --, you expect that
clicking on the button in A would display the help in B rather than in
*Help*?  This is not my expectation; rather, I would expect the help to
be displayed in *Help*, so there would be no inconsisency.  Do you know
of any cases where it is, or is clearly intended, to be displayed in B
instead of *Help*?  If there isn't any, then maybe help-buffer should
simply always use *Help*, never current-buffer.  I found some
problematic cases in Emacs that seem to support this conclusion.

One case is strokes-help in strokes.el: it uses a help-mode buffer
called *Help with Strokes*, so this is buffer B above.  When I click on
a help link in that buffer, the help is displayed in the same buffer
(using either the original help-buffer, the one with your patch, or the
one with mine) -- but there is no back button, so the only way to see
the strokes help again is to reinvoke strokes-help (which now overwrites
the content of the previous help).  If the links used *Help* instead of
the current buffer, there would be now problem.  Two other cases are
describe-current-coding-system in mule-diag.el and r2b-help in
refbib.el.  Both of these use *Help*, but apparently do not add to
help-xref-stack: if a standard help command is called, the back and
forward buttons never return to the coding system or refbib help, so
here, too, the only way to see the help again is to reinvoke the
command.  These commands should, it seems, either use help-xref-stack or
not call their help buffer *Help*.

Footnotes: 
[1]  Not yanked, since the link property is excluded from yanked text.
Given the complications, maybe it wouldn't be such a bad idea to exclude
it also from insert-buffer, as in my first patch in this bug thread....