From: Stephen Berman <stephen.berman@gmx.net>
To: Chong Yidong <cyd@stupidchicken.com>
Cc: 8147@debbugs.gnu.org
Subject: bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss
Date: Mon, 07 Mar 2011 00:58:07 +0100 [thread overview]
Message-ID: <871v2jyf74.fsf@escher.fritz.box> (raw)
In-Reply-To: <878vwryfzd.fsf@escher.fritz.box> (Stephen Berman's message of "Mon, 07 Mar 2011 00:41:10 +0100")
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....
next prev parent reply other threads:[~2011-03-06 23:58 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-01 16:02 bug#8147: 24.0.50; Inserting *Help* buffer can lead to data loss Stephen Berman
2011-03-02 17:07 ` Stefan Monnier
2011-03-05 21:10 ` Chong Yidong
2011-03-06 0:24 ` Stephen Berman
2011-03-06 16:38 ` Stephen Berman
2011-03-06 20:28 ` Chong Yidong
2011-03-06 23:41 ` Stephen Berman
2011-03-06 23:58 ` Stephen Berman [this message]
2011-03-07 16:20 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=871v2jyf74.fsf@escher.fritz.box \
--to=stephen.berman@gmx.net \
--cc=8147@debbugs.gnu.org \
--cc=cyd@stupidchicken.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).