Re: Patch to disable links line in *info* buffer

[Miles Bader]

Miles Bader <address@hidden> writes:
> Now, perhaps your solution of duplicate header lines _is_ the best
> compromise -- it avoids screwing up the nice interface, and it makes
> Bob happy (I guess), even if it slightly confuses users and makes the
> info buffer uglier.
> 
> Perhaps it would be possible to add some sort of header-line hackery so
> that the header-line is only displayed when the buffer-resident
> nodes-line has scrolled out of view.

Here are two possibilities that come to mind for an improved (less
confusing or `bug like') display:

(1) I tried some experiments, and it's possible to do something like this:

      (setq header-line-format
           '(:eval (and (> (window-start) (point-min)) 'Info-header-line)))

    which has the effect of making the header-line blank (I couldn't find
    any way to make it actually disappear) if the `in file' nodes-line is
    visible.  As soon as the screen scrolls so that the first line of the
    node isn't visible anymore, the header-line becomes non-blank (so it
    looks a bit like the in-file version "shifts" into the header-line).

(2) The header-line contains only the `Next:', `Prev:' and `Up:' tags
    (to save space) whereas the the in-file nodes-line contains `File:'
    and `Node:' tags as well.

    If the general point of copying is to identify the current node, we
    could keep the `Next:' &c tags in the header-line, and put _only_ the
    `File:' and `Node:' tags in the (displayed) buffer -- that way, there
    wouldn't be any redundancy, and the string that people most commonly
    might want to copy is available in the buffer for copying.

    This would also have the advantage that the first line usually
    wouldn't wrap, as it often does currently.

Personally I think (2) is a good compromise.

Thoughts?

-Miles
-- 
`Life is a boundless sea of bitterness'