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

[Stephen Berman]

Sorry, I mistakenly sent my followup from a different email address.

Steve Berman

On Mon, 07 Mar 2011 00:41:10 +0100 Stephen Berman <Stephen.Berman@rub.de> wrote:

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