From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>
Cc: 27574@debbugs.gnu.org
Subject: bug#27574: 25.2; `Info-use-header-line' documentation
Date: Sun, 21 Jul 2019 08:53:22 -0700 (PDT) [thread overview]
Message-ID: <b62ee6a2-2689-4243-9c21-e518e2e1b787@default> (raw)
In-Reply-To: <8736iz5s2m.fsf@mouse.gnus.org>
> > The doc should say that toggling the value has no effect if Info has
> > already been opened. It's not even enough to quit Info. Apparently
> you
> > must kill any `Info-mode' buffers and then open Info again, to see
> the
> > change. This is not obvious.
>
> This doesn't seem to be the case on the trunk, at least -- following
> any
> link in the Info buffer then gives you a display that respects this
> variable.
>
> I think that's acceptable, and doesn't need clarification in the
> variable doc string.
Yes, and no.
The behavior is correct now, in the sense that the
header line is no longer used by Info.
But there is still/now a bug that the header line
is still present. The bug report is still correct
that to get rid of it you need to kill Info buffers
and reopen Info.
IOW, the bug is almost fixed - the important failure
has been fixed. A residual problem is that if you
change the option value we do not remove the (now
empty, no longer used for Info) header line from
existing Info buffers.
Using `q' to quit Info does not kill the buffer
(thank goodness). Changing the value of this option
to turn it off should actually remove the header
line. Info "not using" a header line means a bit
more than just not using it for Info purposes
(navigation etc.). It should mean that Info uses
a header line. If the option is off then Info
buffers should not have a header line.
---
On the other hand, to be really clear, they should
not use a header line created for Info. Ideally,
we should keep track of whether a given header line
was created for/by Info, and remove only that when
the option is turned off.
IOW, some other code/library could add its own
header line (there can even be more than one, IIRC).
Ideally, Info should not just remove _a_ header
line. It should remove a header line that it
created.
---
In any case, most of this bug has been fixed.
The problem that remains is minor compared to the
problem that existed.
prev parent reply other threads:[~2019-07-21 15:53 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-04 19:24 bug#27574: 25.2; `Info-use-header-line' documentation Drew Adams
2019-07-21 15:24 ` Lars Ingebrigtsen
2019-07-21 15:53 ` Drew Adams [this message]
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=b62ee6a2-2689-4243-9c21-e518e2e1b787@default \
--to=drew.adams@oracle.com \
--cc=27574@debbugs.gnu.org \
--cc=larsi@gnus.org \
/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).