Patch to disable links line in *info* buffer

Patch to disable links line in *info* buffer

[Romain FRANCOISE]

Richard,

the change you made to info.el to make the links line show up at the top
of the *info* buffer didn't seem to be very popular, and I myself find
it quite useless, since I never ever had to copy this particular line
out of the buffer.

Following Miles Bader's suggestion, I propose the following patch, it
makes the behavior optional, and disabled by default. Does it look
reasonable to you?

Thank you.



Index: lisp/info.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/info.el,v
retrieving revision 1.302
diff -c -r1.302 info.el
*** lisp/info.el	3 Jun 2002 22:57:40 -0000	1.302
--- lisp/info.el	6 Jun 2002 18:15:09 -0000
***************
*** 86,91 ****
--- 86,99 ----
    :type 'boolean
    :group 'info)
  
+ (defcustom Info-show-links-in-buffer nil
+   "*Non-nil means to put the beginning-of-node links at the top of the buffer.
+ This is convenient if you need to copy the links line out of the buffer using
+ M-w. Please note that if you choose not to use the header line, links will
+ be showed in the buffer regardless of the state of this option."
+   :type 'boolean
+   :group 'info)
+ 
  (defface info-header-xref
    '((t (:inherit info-xref)))
    "Face for Info cross-references in a node header."
***************
*** 1034,1043 ****
      (set (make-local-variable 'Info-header-line)
  	 (buffer-substring header-beg header-end))
      (setq header-line-format 'Info-header-line)
! ;;; It is useful to be able to copy the links line out of the buffer
! ;;; with M-w.
! ;;;    (narrow-to-region (1+ header-end) (point-max))
!     ))
  \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
--- 1042,1049 ----
      (set (make-local-variable 'Info-header-line)
  	 (buffer-substring header-beg header-end))
      (setq header-line-format 'Info-header-line)
!     (when (not Info-show-links-in-buffer)
!       (narrow-to-region (1+ header-end) (point-max)))))
  \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
***************
*** 1247,1256 ****
      (save-excursion
        (save-restriction
  	(goto-char (point-min))
! ;;; 	(when Info-header-line
! ;;; 	  ;; expose the header line in the buffer
! ;;; 	  (widen)
! ;;; 	  (forward-line -1))
  	(let ((bound (point)))
  	  (forward-line 1)
  	  (cond ((re-search-backward (concat name ":") bound t)
--- 1253,1263 ----
      (save-excursion
        (save-restriction
  	(goto-char (point-min))
! 	(when (and Info-header-line (not Info-show-links-in-buffer))
! 	  ;; expose the header line in the buffer if it's
! 	  ;; not there already
! 	  (widen)
! 	  (forward-line -1))
  	(let ((bound (point)))
  	  (forward-line 1)
  	  (cond ((re-search-backward (concat name ":") bound t)


-- 
Romain FRANCOISE <romain@orebokech.com> | This is a man's man's man's
it's a miracle -- http://orebokech.com/ | world.--James Brown

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

[Kim F. Storm]

Romain FRANCOISE <romain@orebokech.com> writes:

> Richard,
> 
> the change you made to info.el to make the links line show up at the top
> of the *info* buffer didn't seem to be very popular, and I myself find
> it quite useless, since I never ever had to copy this particular line
> out of the buffer.
> 
> Following Miles Bader's suggestion, I propose the following patch, it
> makes the behavior optional, and disabled by default. Does it look
> reasonable to you?
>

I would also like to hide the entire "duplicate" header line, as the
navigation buttons are in the "real" header line, and the file and
title is in the mode-line (and printed in nice big letters in the top
of the info buffer) -- so every bit of information in the header line
is superfluous in general ... except if you want to copy it.

I would then add a command `+' to toggle the visibility of the header
line in case you really need to look at or copy it.

The following patch to info.el does this:

Index: info.el
===================================================================
RCS file: /cvs/emacs/lisp/info.el,v
retrieving revision 1.302
diff -c -r1.302 info.el
*** info.el	3 Jun 2002 22:57:40 -0000	1.302
--- info.el	6 Jun 2002 22:09:46 -0000
***************
*** 1037,1043 ****
--- 1037,1053 ----
  ;;; It is useful to be able to copy the links line out of the buffer
  ;;; with M-w.
  ;;;    (narrow-to-region (1+ header-end) (point-max))
+     (let ((buffer-read-only nil))
+       (add-text-properties (point-min) (1+ header-end) '(invisible t)))
      ))
+ 
+ (defun Info-toggle-header-visible ()
+   (interactive)
+   (let ((buffer-read-only nil))
+     (save-excursion
+       (goto-char (point-min))
+       (alter-text-property (point) (1+ (line-end-position)) 'invisible 
+ 			   #'(lambda (v) (null v))))))
  \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
***************
*** 2095,2100 ****
--- 2105,2111 ----
    (define-key Info-mode-map "9" 'Info-nth-menu-item)
    (define-key Info-mode-map "0" 'undefined)
    (define-key Info-mode-map "?" 'Info-summary)
+   (define-key Info-mode-map "+" 'Info-toggle-header-visible)
    (define-key Info-mode-map "]" 'Info-forward-node)
    (define-key Info-mode-map "[" 'Info-backward-node)
    (define-key Info-mode-map "<" 'Info-top-node)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

This change would be a change for the worse.  The link line should be
visible by default, so that the possibility of using it is
self-evident.  As an optional feature, it is worthless.

Nobody has presented a real reason why this is bad.

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> This change would be a change for the worse. 

As I read the comments, the new behaviour with two
almost identical header lines was a change to the worse.

> The link line should be
> visible by default, so that the possibility of using it is
> self-evident. 

IMO, there is no self-evident purpose of the duplicate header lines.

It never occurred to me that copying part of the header would
be useful -- and presenting two header lines for that sole
purpose doesn't warrant for the obvious unpleasant visual
appearence.


> As an optional feature, it is worthless.

IMO, the extra header line is worthless too.

> 
> Nobody has presented a real reason why this is bad.

Nobody seems to like it.  Are there really any real
reasons why this is good?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Romain FRANCOISE]

Kim F Storm writes:

> Nobody seems to like it.  Are there really any real
> reasons why this is good?

I'll second Kim's opinion. As is, this extra header line is useless,
unless one wants to copy it, but it seems like nobody ever had to. 

Kim's patch looks good to me, even though it breaks something with the
header line, and shouldn't be applied in its current state.

A better option might be to keep this links line in the buffer, but put
it at the extreme bottom of the buffer. This way, it's always available
if one wants to copy it, and it does not interfere with the existing
header line.  And it provides a way to navigate through the nodes
when you're at the bottom of the buffer, without having to use the
header line.  What do you think?

-- 
Romain FRANCOISE <romain@orebokech.com> | I'm flooded out with energy,
it's a miracle -- http://orebokech.com/ | energy and deceit.

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

[Alex Schroeder]

Romain FRANCOISE <romain@orebokech.com> writes:

> unless one wants to copy it, but it seems like nobody ever had to. 

All that ever annoyed me in info mode is that when I copied the node
name (as I often do when I help newbies), the invisible "****" stuff
got copied along as well.  I see now that in the pretest at least this
stuff is made visible.  Personally, however, I'd prefer it if the
underlining stuff was not there at all when copied.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

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

[Robert J. Chassell]

There are two orthogonal questions regarding the header/links lines
in an *info* buffer:

  1. Should Emacs Info use up extra space in an Info display by
     showing a second line, a line that many people dislike?

  2. Should it be possible to copy the file name and node name of an
     Info file from a node seen in Info.

From the comments, many people are against # 1, either because screen
space is valuable or because they dislike seeing a second line, or both.

As for # 2:  some people never seem to want to refer other people to
Info nodes.  They never tell people to RTFM, but I do.  

I set `Info-use-header-line' to `nil' in my .emacs file and copy the
lines that tell people the file name and node name.  (There is a
command for this using the fancy header lines that exist by default,
but I cannot remember it; I just copy the `non-header' line.)

Evidentally, the new-styule `header lines' are constructed to be like
mode lines, which cannot be copied and never have been able to be
copied.  (And I have never missed be unable to copy them.)  However,
since I often tell people to RTFM, I do copy the headers for Info
nodes.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Miles Bader]

"Robert J. Chassell" <bob@rattlesnake.com> writes:
> Evidentally, the new-styule `header lines' are constructed to be like
> mode lines, which cannot be copied and never have been able to be
> copied.  (And I have never missed be unable to copy them.)  However,
> since I often tell people to RTFM, I do copy the headers for Info
> nodes.

I think the Consensus on this mailing list seems to be that the
old-new-style -- node-names in header-line only, not copyable -- is
better.

Some people (at least you [Bob], but I think I've seen one or two more
comments about the issue on a mailing list somewhere) would like to copy
them, and end up frustrated by this style, but most people don't seem to
care about copying.  I suspect that the `don't care' position is also the
one that most unsophisticated users will occupy, and that you are an
unusual case since you spend more of your time helping others than is
typical.

So I'd say the `duplicated header-line' should be reverted.

That leaves the question of what people like who _do_ want easy
copyability should do.

Some suggestions:

 1) Just tell them `set Info-use-header-line to nil'

 2) Keep reminding them of the `Info-copy-current-node-name' function
    (bound to `c' in info-mode, and also in the Info menu)

 3) Perhaps add a more intuitive binding for Info-copy-current-node-name.
    For instance, how about a mouse-3 menu in the header-line that
    includes only a few commands, including that one?  Since mouse-3 for
    context-sensitive menus is fairly standard, this might be easy to
    remember.

What do you think Bob?

-Miles
-- 
"I distrust a research person who is always obviously busy on a task."
   --Robert Frosch, VP, GM Research

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

[Robert J. Chassell]

   I think the Consensus on this mailing list seems to be that the
   old-new-style -- node-names in header-line only, not copyable -- is
   better.

It is better than duplicating lines, which as Eli says, looks like a
display bug.  At this stage, the best temporary solution may be to
revert.

The ultimate solution may be more along the lines that Eli mentioned:

    ... a way to copy mode- and header-lines. 

although the design of the current node header does not list the Info
filename, only the next, previous, and up nodes.  I am not sure that
the current header format is wrong; I am only saying that it is not
useful to me as designed.

Considering what you [Miles] said:

   That leaves the question of what people like who _do_ want easy
   copyability should do.

    1) Just tell them `set Info-use-header-line to nil'

This is the way it has been for a while, and works fine for
knowledgeable people.  This feature should certainly continue.

    2) Keep reminding them of the `Info-copy-current-node-name' function
       (bound to `c' in info-mode, and also in the Info menu)

We don't need to say more than this.

    3) Perhaps add a more intuitive binding for Info-copy-current-node-name.

I think both the mouse and keyboard bindings for
`Info-copy-current-node-name' are fine as they are.

The `Info-copy-current-node-name' function produces output that is
very convenient if you know Info, since it creates a reference in a
form that `Info-goto-node' understands.

Unfortunately, I often communicate with people who don't know about
Info, or who know very little, whom I am trying to inspire.

For example, yesterday morning, a correspondent asked whether Texinfo
files are directed graphs?  After distinguishing between the
organization of a document and the @section and similar commands,
which format headers, I quoted from Texinfo manual, saying

    As the Texinfo manual says with respect to Info:

        File: texinfo,  Node: Info Files

For this person, such a long-winded reference is more informative and
inspiring than the output of the `Info-copy-current-node-name'
function,

    (texinfo)Info Files

even though the latter is more efficient for those who already know
Info. (I doubt this correspondent knows much about Info yet.  I hope
she will start using Texinfo to document her work, which is writing
programs for biological researchers, as well as make the software
free.)

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Eli Zaretskii]

On Sat, 8 Jun 2002, Robert J. Chassell wrote:

> As for # 2:  some people never seem to want to refer other people to
> Info nodes.  They never tell people to RTFM, but I do.  

Actually, many people (including myself) do refer users to RTFM.  I just 
never bother about copying the node name; instead, I use "M-/" to type 
only a small part of the name and let Emacs complete the rest.  To me, 
"M-/" is a better way, since I never need to switch buffers or move the 
mouse.

> Evidentally, the new-styule `header lines' are constructed to be like
> mode lines, which cannot be copied and never have been able to be
> copied.

Perhaps we _should_ have a way to copy mode- and header-lines.  Adding
that sounds like a valuable feature in and off itself.

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

[Stefan Monnier]

> There are two orthogonal questions regarding the header/links lines
> in an *info* buffer:
> 
>   1. Should Emacs Info use up extra space in an Info display by
>      showing a second line, a line that many people dislike?
> 
>   2. Should it be possible to copy the file name and node name of an
>      Info file from a node seen in Info.
> 
> From the comments, many people are against # 1, either because screen
> space is valuable or because they dislike seeing a second line, or both.
> 
> As for # 2:  some people never seem to want to refer other people to
> Info nodes.  They never tell people to RTFM, but I do.  
> 
> I set `Info-use-header-line' to `nil' in my .emacs file and copy the
> lines that tell people the file name and node name.  (There is a
> command for this using the fancy header lines that exist by default,
> but I cannot remember it; I just copy the `non-header' line.)
> 
> Evidentally, the new-styule `header lines' are constructed to be like
> mode lines, which cannot be copied and never have been able to be
> copied.  (And I have never missed be unable to copy them.)  However,
> since I often tell people to RTFM, I do copy the headers for Info
> nodes.

How about having a right-click on the header-line or somesuch pop-up
a menu where you can select "copy location to kill-ring" ?
The location could even be more verbose than the displayed one,
i.e. (info "(emacs)Top") or some such.
This is very much like what most browsers allow you to do on a `link',
so it might be "intuitive enough".


	Stefan

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

[Robert J. Chassell]

   How about having a right-click on the header-line or somesuch pop-up
   a menu where you can select "copy location to kill-ring" ?

In the traditional Emacs user interface, a user can copy anything
within a buffer using the same command (with keybinding and mouse
interface).  I found this traditional interface simple and satisfying.

The new suggestion *adds* a new command to what historically was an
interface that used a single command, producing an additional
keybinding and mouse interface.

This new interface is wrong.  Instead, Emacs should continue to
provide a `you can copy what you can see (or hear)' interface, but
adapt it to new circumstances.


Both the existing `Info-copy-current-node-name' and this new
suggestion place text into the kill-ring that is different from what
you see in an *info* header.

This circumstance produces a choice:

  1. Should a user be required to learn and use new copy commands for
     a particular situation?

  2. Should the interface to the traditional copy command be
     overloaded so that a new, non-`what_you_see_is_what_you_can_copy'
     interface is added for special regions of the window?

  3. Should the various applications in Emacs be designed so that a 
     single `what_you_see_is_what_you_can_copy' interface succeeds?

So far, choice # 1 has been followed.  The traditional *info* header
was replaced by a version that

         -- could not be copied in the traditional way, but 

         -- could be copied by a new command, not overloaded onto the
              previous interfaces (keybinding and mouse), that
              did not copy the text into the kill ring, but generated
              new text for the kill ring, new text that is 
              efficent for Emacs experts.

         -- however, users could set `Info-use-header-line' to nil and
              continue with the old behavior.


Another possibility is to shift to choice # 2, and to map commands
such as `Info-copy-current-node-name' to the same user interface -- to
the same keybindings and mouse actions -- as `copy-region-as-kill' and
its brethren.  This would make what is copied dependent on context.
I don't like this.


The third possibility is to design applications so that what you see
is what you can copy.  The idea behind this is powerful simplicity.

I favor this. However, this choice has implications.

The problem with a `what_you_see_is_what_you_can_copy' interface is
that we often shift between a deep structure and a surface
representation.

When you look at a Web page in a broswer, you look at the surface
representation of the deep structure of the HTML file that creates the
Web page..

In this "Patch to disable links line" situation, the surface
representation is the look (or sound, if you use Emacspeak) of the new
*info* header and the deep structure is the form that actually appears
in the Info file.

Thus, the new style Info header line for the first node for the Info
help says:

    Next: Help-P,  Prev: Help-Small-Screen,  Up: Getting Started

However, the deep structure is the Info file, which says:

    File: info,  Node: Help,  Next: Help-P,  Prev: Help-Small-Screen,  Up: Getting Started

The old style header line duplicates this deep structure.  When you
copy the old style header line, you get what appears in the Info file.
But when you copy a new style header line, you get:

    (info)Help


In Texinfo, the deep structure is what you see in a Texinfo file and
the surface representations are the Info output, the printed output,
the XML output, the plain text output, and HTML output.

(In the one case, an Info file is the deep structre; in the other case,
an Info file is a surface representation.)

The original Emacs was based on the premise that surface
representations reflect deep structure closely enough that the
differences could be ignored; or in the case of code, the surface
representation, what the code did, what in a totally different
category than different displays of a text.

Thus, in the original Emacs, what you saw in a buffer represented the
file itself, with the translations from the ASCII or such code being
one-to-one to displayed characters.  Emacs was a `WYSIWYG' editor for
fixed width font text.

Nowadays, the source-to-display transformation for text is bigger.  In
the old days, people wrote Info files as Info files.  No longer.
Nowadays, Info files are written as Texinfo files.  This change is
efficient, since Texinfo enables you to generate not only Info files,
but also XML, HTML, and printed output files. for use on Web browsers
and printing.

(I have written a (bug-ridden) prototype that enables you to regenerate
and redisplay frequently the Info, printed, and HTML surface
representations of a Texinfo file as you write the deep structure.

(This split-screen Texinfo_to_surface_representations program is
intended to make it easier to see the consequences of what you write
as you write.  It is more like writing in an interpreted computer
language, such as Emacs Lisp, than a native-code compiled language
such as C.)

I favor designing Emacs so that you can always go to a fairly basic
representation of the deep structure.  You may want to look at and use
a surface representation such as Info or a W3 buffer, but you should
be encouraged to learn to look at and understand the underlying deep
structure.  

By `encouraged' I mean, `the process made easy'.  If, for example, an
expert must leave his keyboard to find a mouse, for a command that a
mouse is not specially suited for, then the process is made hard.
People will tend to do the easy more than the hard.

The split-screen Texinfo_to_surface_representations solution is
straightforward.  I find it more diffcult to recommend to a newbie how
an Info header should look and how it should be copied.

I like the traditional Info header style: I like being told which file
I am in.  I am not too bothered by the overly wide lines that the
style often produces.  However, I can see the advantages of the new
style to sighted people who like to continue to see the next,
previous, and up pointers whereever they are in a node.

Perhaps it would be a good idea is to create a new *info* header line
based on the new style that also tells you the file name, and that
fills nicely to two lines when it is too wide to fit on one line, and
that can be copied by the usual commands.  (The useful
`Info-copy-current-node-name' command should continue, but it should
be renamed to `Info-specify-current-node-name' since the command does
not copy what you see, but instead creates an expression based on what
you see.)

Regardless of how the *info* header line question is settled, I do
think we should continue to support the simple and satisfying
principle that a user can copy anything within a buffer using the same
command (with keybinding and mouse interface).  Moreover, I think we
should use the deep-structure/surface-representations model for many
of the newly arising display issues.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Stefan Monnier]

> Perhaps it would be a good idea is to create a new *info* header line
> based on the new style that also tells you the file name, and that
> fills nicely to two lines when it is too wide to fit on one line, and
> that can be copied by the usual commands.

I haven't seen a convincing argument for why the header-line should contain
the file and/or current node name.

Based on your deep-vs-surface argument, I'd say that the best
choice is to hide the first line by scrolling (rather than by
narrow-to-region as is currently done), so that the deep info is
readily available, although it's not annoyingly in-your-face like
it is now.

> Regardless of how the *info* header line question is settled, I do
> think we should continue to support the simple and satisfying
> principle that a user can copy anything within a buffer using the same
> command (with keybinding and mouse interface).  Moreover, I think we
> should use the deep-structure/surface-representations model for many
> of the newly arising display issues.

The problem is that the header-line, just line the mode-line, the tool-bar,
the menu-bar (and probably more) is not part of the buffer.  There has
never been any way to easily copy their content (and especially not
their underlying "deep" content) with the usual keybindings.


	Stefan

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

[Robert J. Chassell]

storm@cua.dk (Kim F. Storm) writes

    You have never been able to copy what's in the mode-line.  

That is very true.  This means I cannot copy a file name for Info.
The name has been shifted from easily sharable to hard-to-share.

You point out that the mode-line tells you which file I am in.  This
is true.  But I like sharing this information with others but do not
like wasting my time doing so.  Consequently, an easily copy-able,
properly formatted line helps.

monnier+gnu/emacs@rum.cs.yale.edu writes:

   The problem is that the header-line, just line the mode-line, the
   tool-bar, the menu-bar (and probably more) is not part of the
   buffer.  There has never been any way to easily copy their content
   (and especially not their underlying "deep" content) with the usual
   keybindings.

You are right.  The new style for the header-line takes away an Emacs
feature.

I can live with being unable to copy the mode line, since it does not
have information I copy and send to people all the time like the
filename, including path, of the buffer I am visiting.  (My mode lines
have the name and path arranged in format that I personally can read
easily, but that is not good for email; I have not figured out a
format that works both for my monitoring and for my sharing at the
same time.)

I have been bothered by being unable to copy menus readily; but since
I hardly ever use or look at them, I personally don't find that much
trouble.  (People who do use their mouse frequently to open menus are
hurt by being unable to copy them.  For example, how can you
efficiently discuss variations to the `Options' menu without being
able to quote what you have?)

Eli makes a good suggestion, that you should be able to copy all of
Emacs.  I second him.

My concern is thats such copying also fit a `simple and satisfying'
criterion, which is that copying in the usual manner copies what you
see (modulo pro tem markup; i.e., the copying is of the words, which
is what you would do if copying by writing by hand, not the
typesetting).

A second type of textual generation, exemplified by the misnamed
`Info-copy-current-node-name' command, would use other commands, which
should not be bound to the same key, mouse, or other bindings use for
regular copying.  These commands would generate useful expressions for
the context.  The misnamed `Info-copy-current-node-name' command
generates a useful expression for a new-style *info* header; the
`mode-line-specify-current' command should generate a useful
expression for what a mode line says.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Thien-Thi Nguyen]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

   That is very true.  This means I cannot copy a file name for Info.
   The name has been shifted from easily sharable to hard-to-share.

if we want to optimize for ease of sharing (not a bad goal, IMHO), my guess is
the easiest way to share a mode-line-as-"link" would be a series of keystrokes
that can be used to find that node.  this:

 (fset 'help-me! [?\C-h ?i ?m ?e ?m ?a ?c ?s ?\C-m])

is more useful than

 File: emacs,  Node: Top,  Next: Distrib,  Prev: (dir),  Up: (dir)

you can tell someone to put this in *scratch* and type `C-j M-x help-me!'.
there are current-state issues to resolve of course; this is just a sketch.

the display of deep-structure info in the buffer is not necessary for this.

thi

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

[Stefan Monnier]

>    That is very true.  This means I cannot copy a file name for Info.
>    The name has been shifted from easily sharable to hard-to-share.
> 
> if we want to optimize for ease of sharing (not a bad goal, IMHO), my guess is
> the easiest way to share a mode-line-as-"link" would be a series of keystrokes
> that can be used to find that node.  this:
> 
>  (fset 'help-me! [?\C-h ?i ?m ?e ?m ?a ?c ?s ?\C-m])

This is unreadable and doesn't work if the *info* buffer is
already viewing some other manual.  Better use

	(info "(emacs)Top")

and tell people to hit C-x C-e with the cursor right after the closing paren.


	Stefan

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

[Robert J. Chassell]

   if we want to optimize for ease of sharing (not a bad goal, IMHO),
   my guess is the easiest way to share a mode-line-as-"link" would be
   a series of keystrokes that can be used to find that node.  this:

    (fset 'help-me! [?\C-h ?i ?m ?e ?m ?a ?c ?s ?\C-m])

   is more useful than

    File: emacs,  Node: Top,  Next: Distrib,  Prev: (dir),  Up: (dir)

Whether it is more useful depends on your goal.  If you are giving
some keystrokes to someone who already knows and uses Info, then yes,
this might be more useful, although I think the
`Info-copy-current-node-name' for this, `(emacs)Top', is even more
useful.

But for my primary audience, this series of keystrokes fails; it is
like a magic catenation that does the job, but you don't learn the
physics.  My audience need to learn that there is a `dir' file.  They
need to learn that you can go from the dir file to a specific Info
file; and that in the Info file, you can go to a specific node.  And
they need to be inspired to do this.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Thien-Thi Nguyen]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

   Whether it is more useful depends on your goal.

the goal is to act in an exemplery fashion, to demonstrate the path taken.

   But for my primary audience, this series of keystrokes fails; it is
   like a magic catenation that does the job, but you don't learn the
   physics.  My audience need to learn that there is a `dir' file.  They
   need to learn that you can go from the dir file to a specific Info
   file; and that in the Info file, you can go to a specific node.  And
   they need to be inspired to do this.

chunking issue: "(emacs)Top" is fine for top-level, but for deeper nodes, say
"(emacs)Mode Line", the path can be represented:

  C-h i
  m Emacs RET
  m Mode Line RET

so, to show this just requires some "info-follow-path-slowly" that does the
equivalent of

  (info "(emacs)Mode Line")

w/ a pause in between each step and a nice message saying "you can do this
yourself next time".  then, the "link data" is just ("Emacs" "Mode Line") and
you can tell people:

  (info-follow-path-slowly "Emacs" "Mode Line")

working sketch below.

(as for how to inspire people, just set the default `sit-for' values to beyond
normal patience threshold.  this is the stick part, using emacs is the carrot.
;-)

thi


___________________________________________________________
(defun info-follow-path-slowly (&rest path)
  (info)
  ;; TODO: get back to top-level somehow
  (message "this is the dir file")
  (sit-for 5)
  (while path
    (let ((name (car path)))
      (re-search-forward (concat "^* " name))
      (message "next, we're going to go to ``%s''" name)
      (sit-for 5)
      (Info-menu name)
      (message "ok, now we're at ``%s''" name)
      (sit-for 5))
    (setq path (cdr path)))
  (message "we're here -- everyone to the bathroom!"))

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

[Eli Zaretskii]

On Mon, 10 Jun 2002, Robert J. Chassell wrote:

> storm@cua.dk (Kim F. Storm) writes
> 
>     You have never been able to copy what's in the mode-line.  
> 
> That is very true.  This means I cannot copy a file name for Info.

Emacs is replete with text you cannot copy, and so do other applications.

IMHO, the need for copying the header line is greatly exaggerated in this 
thread.  As much as you never needed to copy the mode line, I (and 
probably many others) never needed to copy the Info header line.  FWIW, I 
don't find much value in telling users to go to (info)Help or some such: 
I think this cryptic notation alienates them to Info rather than helps 
them to embrace it.  But I digress.

> For example, how can you
> efficiently discuss variations to the `Options' menu without being
> able to quote what you have?)

If we want to be able to copy menus (and I agree it could be a useful 
feature), we should add a command that creates a text representation of a 
menu structure.  But it would be IMHO absurd to ask that M-w on the menu 
item would produce that effect: users understand that menus are not 
normal buffer text, so they won't be surprised by the need to type 
something special to copy a menu.

The same holds for a header line, which is a special part of the Emacs 
frame, not part of buffer text.

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

[Robert J. Chassell]

monnier+gnu/emacs@RUM.cs.yale.edu suggests

   ...  hide the first line by scrolling (rather than by
   narrow-to-region as is currently done), so that the deep info is
   readily available, although it's not annoyingly in-your-face like
   it is now.

This fails the `newbie' test.  Some years ago, when I first learned
about the `Info-top-node' command, I tried it.  (I still use it often,
to get to the main menu.)  You are suggesting that when a newbie first
looks at the beginning of an Info file, he or she not see an old style
header line in addition to its current header line ; but that when she
goes back to the beginning of an Info file, it look different from
what it was and show *two* nearly similer header lines.  

This will not work.  It will look like a bug.  Not only that, it will
be very hard to persuade people it is not a user-interface design
mistake.  It will be the kind of change that people will find wrong,
willy-nilly.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Stefan Monnier]

>    ...  hide the first line by scrolling (rather than by
>    narrow-to-region as is currently done), so that the deep info is
>    readily available, although it's not annoyingly in-your-face like
>    it is now.
> 
> This fails the `newbie' test.  Some years ago, when I first learned
> about the `Info-top-node' command, I tried it.  (I still use it often,
> to get to the main menu.)  You are suggesting that when a newbie first
> looks at the beginning of an Info file, he or she not see an old style
> header line in addition to its current header line ; but that when she
> goes back to the beginning of an Info file, it look different from
> what it was and show *two* nearly similer header lines.  

Info-top-node will not show that line either.

Look, several people (myself included) dislike having both the
header-line and the "normal" text line.  I want the header-line
because it's always accessible.  You want to be able to copy
the text of the node name easily.

I don't think someone will come up with a way to copy the text
from the mode-line and/or the header-line any time soon, because it's
simply non trivial (for the simple reason that the mapping between the
"deep" info and what is actually displayed is itself non trivial).

So if you can come up with a perfect solution, great, but I'm
willing to settle for the "scroll out of view" since it is simple
and gets most people 90% satisfied.
I still haven't heard any other concrete proposal.


	Stefan

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

[Andreas Schwab]

"Stefan Monnier" <monnier+gnu/emacs@RUM.cs.yale.edu> writes:

|> The problem is that the header-line, just line the mode-line, the tool-bar,
|> the menu-bar (and probably more) is not part of the buffer.  There has
|> never been any way to easily copy their content (and especially not
|> their underlying "deep" content) with the usual keybindings.

Another problem with all those off-buffer elements is that they are not
scrollable, and valuable information can easily get shifted out of sight.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    How about having a right-click on the header-line or somesuch pop-up
>    a menu where you can select "copy location to kill-ring" ?
> 
> This new interface is wrong.  Instead, Emacs should continue to
> provide a `you can copy what you can see (or hear)' interface, but
> adapt it to new circumstances.
> 
You have never been able to copy what's in the mode-line.  The new
header-line has the same limitation.  I don't see that as wrong (but a
general limitation on some elements of an emacs frame.)


> I like the traditional Info header style: I like being told which file
> I am in. 

That information is also shown as the buffer name in the mode-line.
What's the point of duplicating it in the header line?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    Perhaps it would be a good idea is to create a new *info* header line
    based on the new style that also tells you the file name, and that
    fills nicely to two lines when it is too wide to fit on one line, and
    that can be copied by the usual commands.

The current facilities can't do all of these things.  I wonder--would
it be useful if the header line displayed at the top of a window were
part of the buffer text, rather than a feature like the mode line?  In
other words, one could designate a part of the buffer (at the
beginning) as the header, to be always displayed at the top of the
window regardless of scrolling.  The text starting at the window-start
pointer would appear in the window beneath that header text.

When the buffer is scrolled to the top, there should only be one copy
of the header lines text.  If you move point to the beginning, it
would appear on the first header lines.  In effect, that text would
be displayed as ordinary text display, not as something like the
mode line.

With this feature, we could do all the things that you are asking for
here.  It might be a better feature for other purposes than the
existing header-line feature.

However, in one respect it would not be better than the method we used
a week ago: it would always use a screen line for the header line.
If we want to save more screen space for the text, this will not do so.
For that we would have to eliminate the header line entirely.

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

[Jason Rumney]

Richard Stallman <rms@gnu.org> writes:

> However, in one respect it would not be better than the method we used
> a week ago: it would always use a screen line for the header line.
> If we want to save more screen space for the text, this will not do so.
> For that we would have to eliminate the header line entirely.

The use of the header line for info links is one change in Emacs 21
that has *not* attracted lots of complaints of wasted screen space.  I
think most users consider that the usefulness of having navigation
links always at the top of the info window outweighs the extra space
used.

Considering that we already have the variable Info-use-header-line to
bring back the pre-21.1 behavior for those minority of users who want
to copy the info header without learning a new command, I think the
best thing to do is to restore the previous behavior, and work towards
a longer term goal of making it possible to copy information from the
header and mode lines.

-- 
Jason Rumney

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

[Kim F. Storm]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> > However, in one respect it would not be better than the method we used
> > a week ago: it would always use a screen line for the header line.
> > If we want to save more screen space for the text, this will not do so.
> > For that we would have to eliminate the header line entirely.
> 
> The use of the header line for info links is one change in Emacs 21
> that has *not* attracted lots of complaints of wasted screen space.  I
> think most users consider that the usefulness of having navigation
> links always at the top of the info window outweighs the extra space
> used.

Yes, the typical reaction on the new "sticky" header line is: very nice!

> ... and work towards
> a longer term goal of making it possible to copy information from the
> header and mode lines.

I just added a new function `format-mode-line' to CVS emacs which
returns the current mode-line or header-line of the selected (or a
specified) window as a string [without properties].

So now you can copy them from lisp; next step is to make bindings to
do this.  [any volounteers?]

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    I just added a new function `format-mode-line' to CVS emacs which
    returns the current mode-line or header-line of the selected (or a
    specified) window as a string [without properties].

Thanks.  Could you make it pass through the properties, though?

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     I just added a new function `format-mode-line' to CVS emacs which
>     returns the current mode-line or header-line of the selected (or a
>     specified) window as a string [without properties].
> 
> Thanks.  Could you make it pass through the properties, though?

This can be done, but do we really need it?

The change I made to implement format-mode-line was actually very simple,
as I could use the existing hooks that stores the title line in a C-string
rather that displaying the text.

Unfortunately, the title code does not deal with text properties, so I
have to make more changes to have format-mode-line return a propertized
string.

So again, do we really need that?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    > Thanks.  Could you make it pass through the properties, though?

    This can be done, but do we really need it?

I think it is a bug not to do that.

I think it should be possible to modify display_mode_element so that
it saves up the actual strings; then you can concatenate them after.
That might be pretty easy.

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     > Thanks.  Could you make it pass through the properties, though?
> 
>     This can be done, but do we really need it?
> 
> I think it is a bug not to do that.

Ok, I'll fix it.

> 
> I think it should be possible to modify display_mode_element so that
> it saves up the actual strings; then you can concatenate them after.
> That might be pretty easy.

Yes, that sounds like the right approach.  Thanks.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
> 
> >     > Thanks.  Could you make it pass through the properties, though?
> > 
> >     This can be done, but do we really need it?
> > 
> > I think it is a bug not to do that.
> 
> Ok, I'll fix it.

Well, it turns out to be a bigger problem than I expected to do so.  I
have most of the functionality working now, but I still have a big
problem with faces.

Consider the buffer name shown in the mode line.
It is shown in bold, but otherwise uses the mode-line face.

In the display engine, this is implemented by creating a new unnamed
face which using mode-line as the base font, but with the (:weight
bold) attribute added to it.

The problem is that there is no named face which has this appearence,
so I cannot simply put a (face mode-line-bold) property on the string
returned by format-mode-line.

Instead, I'll have to create a face specification to match the actual
appearence of the buffer name.  I guess it can be done, but it seems a
lot of work to achieve a simple goal.

Any ideas how to simplify this task?

Maybe we should reconsider whether we really want a 100% accurate
appearence.

Can we perhaps accept that face attributes in the mode-line are
ignored when we copy the mode-line to a string, i.e. the whole string
will simply have the mode-line or header-line face property?  

That's what my current code does...

BTW, it also copies the help-echo text, but the mouse doesn't work as
the help describes, since the mouse binding is like [mode-line
mouse-1], and it obviously doesn't work inside a buffer's text area.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Stefan Monnier]

> The problem is that there is no named face which has this appearence,
> so I cannot simply put a (face mode-line-bold) property on the string
> returned by format-mode-line.

Any reason why you can't use (face (mode-line bold)) ?


	Stefan

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

[Kim F. Storm]

"Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:

> > The problem is that there is no named face which has this appearence,
> > so I cannot simply put a (face mode-line-bold) property on the string
> > returned by format-mode-line.
> 
> Any reason why you can't use (face (mode-line bold)) ?

Not anymore :-)

Thanks!!

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

[Kim F. Storm]

no-spam@cua.dk (Kim F. Storm) writes:

> "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> 
> > > The problem is that there is no named face which has this appearence,
> > > so I cannot simply put a (face mode-line-bold) property on the string
> > > returned by format-mode-line.
> > 
> > Any reason why you can't use (face (mode-line bold)) ?
> 
> Not anymore :-)

Ok, I have changed format-mode-line to return a propertized string
(changes are not committed yet), but the "face merging" doesn't always
give the same result as the actual mode line:

This combination works (*Help* is bold):

(insert '#("-1:%%  *Help*  ..."
         7 13 (face (mode-line :weight bold))))

but this doesn't (*Help* isn't bold):

(insert '#("-1:%%  *Help*  ..."
         7 13 (face (mode-line-inactive :weight bold))))

I haven't investigated this further, but it could be related to
mode-line-inactive being derived from another face...?


Also, there are some visual artifacts in the following example; there
are small white lines between the bold and non-bold sections:

(insert '#("-1:**  *scratch*        ..."
         1 7 (face mode-line)
         7 19 (face (mode-line (:weight bold)))
         19 22 (face mode-line)))


In any case, I'm going to commit my changes tomorrow (or so)
-- then we'll have to look into the above issues later...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    The problem is that there is no named face which has this appearence,
    so I cannot simply put a (face mode-line-bold) property on the string
    returned by format-mode-line.

The value of the face property can include multiple faces as well as
attribute-value pairs.  It should be easy to construct something of
that form to represent whatever you need.  You can simply take the
various faces and attributes that you find in the various face
properties coming in, concatenate them all, and use the combined
value.

Is there a reason that won't work?

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

[Robert J. Chassell]

Kim F. Storm <storm@cua.dk>

    ... just added a new function `format-mode-line' to CVS emacs which
    returns the current mode-line or header-line of the selected (or a
    specified) window as a string [without properties].

This is a nice function!  But it needs a better documentation string.

Currently, the first line of the documentation string says;

    Return the mode-line of selected window as a string.

It should say something like:

  Format, according to optional arg FORMAT, the mode-line of selected WINDOW.

Then the second and subsequent lines could say:

  If neither optional argument is given, return the window's current
  mode line as a string.

  See `mode-line-format' for detailsof how to specify FORMAT.  If
  FORMAT is t, return the buffer's header-line.  Second optional arg
  WINDOW specifies a different window to use as the context for the
  formatting.


Should the word `header-line' be replaced with `Info header-line' to
make more sense to people?

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Andreas Schwab]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

|> Should the word `header-line' be replaced with `Info header-line' to
|> make more sense to people?

I don't think so, since the header line is a generic concept that is not
limited to Info.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Deutschherrnstr. 15-19, D-90429 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

[Robert J. Chassell]

   ... I wonder--would it be useful if the header line displayed at
   the top of a window were part of the buffer text, rather than a
   feature like the mode line?

That adds complexity to the notion of `buffer'.  A policy of
`buffers all the way' would add simplicity.  

Instead of remaking a buffer so it has two parts, only one of which is
a window, the `buffers all the way' idea is to make every window
within a frame be a buffer of some sort: tool bar, menu bar, mode
lines, fringes, scroll bars, Info header lines, and the windows
themselves.

For this to work, buffers would need an optional `not-copy-able'
attribute as well as the current attributes.  You need to be able to
mark a mode-line as non-copy-able (except when you want to copy it).
(I am using the word `copy' because of the sometimes ambiguous meaning
of the word `read'; a scroll-bar is `readable' by the human looking at
it; but it is not `copy-able'.)

Currently, buffers have the three attributes of 

    always copy-able
    write-able
    not-write-able

Currently, mode-lines and the various bars have the two attributes of 

    not-copy-able
    not-write-able

The `buffers all the way' idea requires, among others, four
attributes:

    copy-able
    not-copy-able
    write-able
    not-write-able

Also, buffers would have to have location constraints within frames
and between frames.  For example, a scroll bar would normally sit
beside the buffer on which it reports and be tall and thin.  Of
course, you might want sometimes to put a scroll-bar elsewhere or to
make it a different shape.  So you re-write the `scroll-bar buffer'
library.  (SCWM `contraints' might provide some ideas for location
constraints.)

A mode-line would be a buffer with these default characteristics:

    not-copy-able
    not-write-able
    dependent on another buffer
    always display when other buffer shows
    always below the other buffer
    one line high, same width as its parent
    a specified set of fonts and faces
    containing special information, such as name of buffer

If you wanted to copy a visible mode-line, you could change the
`not-copy-able' attribute to `copy-able'; if you wanted to change its
look, you would change its faces.

To save screen space, you could turn off the buffer's variable that
says `always display in this context'.  You could, for example, turn
off a scroll-bar by burying it, or by not constructing it.  Or you
could hack a tool-bar to show some of the same features as an Info
header line, and avoid the Info header line.

Of course, you can do any of this hacking now; the idea is that with a
single `buffers all the way' policy, conceptualization is easier.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Kim F. Storm]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

>    ... I wonder--would it be useful if the header line displayed at
>    the top of a window were part of the buffer text, rather than a
>    feature like the mode line?
> 
> That adds complexity to the notion of `buffer'.  A policy of
> `buffers all the way' would add simplicity.  

Sounds cool, but I think that is something for emacs 22...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    Instead of remaking a buffer so it has two parts, only one of which is
    a window,

We seem to be miscommunicating--that is not what I had in mind:

   ... I wonder--would it be useful if the header line displayed at
   the top of a window were part of the buffer text, rather than a
   feature like the mode line?

I am talking about a new display feature for how to display the text
in the buffer.  This does not mean the buffer has "two parts".

	      the `buffers all the way' idea is to make every window
    within a frame be a buffer of some sort: tool bar, menu bar, mode
    lines, fringes, scroll bars, Info header lines, and the windows
    themselves.

This is the other idea I proposed, and I still think it is an elegant
approach if we can do it.  Handling scroll bars this way might be
quite difficult, and I think it is fine for them to stay as they are.
I don't think we should try to handle fringes this way.  But it might
make sense to handle the tool bar, menu bar, mode lines and header
lines this way.

    A mode-line would be a buffer with these default characteristics:

	not-copy-able
	not-write-able
	dependent on another buffer

This would be done by updating its contents within redisplay.
We would do that in the places that now redisplay the mode line.

	always display when other buffer shows
	always below the other buffer
	one line high, same width as its parent

These three are actually a matter of setting up the window structure.
Most of the work, to change this, would be about how the window structure
is set up and what features it provides.

	a specified set of fonts and faces
	containing special information, such as name of buffer

This would be done by updating its contents within redisplay.
We would do that in the places that now redisplay the mode line.

Patch for emacs-lisp-intro.texi

[Christian Egli]

Hi Robert

I read with great joy your simple introduction to Emacs Lisp
programming. I believe to have found a small error. Below you can find
a patch.

I was't quite sure where to send this patch, since
emacs-lisp-intro.texi is not part of Emacs 21.2.1, so this isn't an
Emacs bug strictly speaking. However it comes with the CVS version of
emacs so I'm sending it to you and a cc to emacs-devel.

Index: emacs-lisp-intro.texi
===================================================================
RCS file: /cvsroot/emacs/emacs/lispintro/emacs-lisp-intro.texi,v
retrieving revision 1.15
diff -u -r1.15 emacs-lisp-intro.texi
--- emacs-lisp-intro.texi	6 Jun 2002 16:17:38 -0000	1.15
+++ emacs-lisp-intro.texi	17 Jun 2002 19:22:29 -0000
@@ -14720,7 +14720,7 @@
   '("../lisp/macros.el"
     "../lisp/mailalias.el"
     "../lisp/makesum.el"))
- '<
+ '<)
 @end group
 @end smallexample
 

-- 
Christian Egli
wyona: research & development
http://www.wyona.com

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

[Richard Stallman]

    How about having a right-click on the header-line or somesuch pop-up
    a menu where you can select "copy location to kill-ring" ?
    The location could even be more verbose than the displayed one,
    i.e. (info "(emacs)Top") or some such.
    This is very much like what most browsers allow you to do on a `link',
    so it might be "intuitive enough".

That might be a good idea.

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

[Kim F. Storm]

Romain FRANCOISE <romain@orebokech.com> writes:

> Kim F Storm writes:
> 
> > Nobody seems to like it.  Are there really any real
> > reasons why this is good?
> 
> I'll second Kim's opinion. As is, this extra header line is useless,
> unless one wants to copy it, but it seems like nobody ever had to. 
> 
> Kim's patch looks good to me, even though it breaks something with the
> header line, and shouldn't be applied in its current state.

I noticed that myself.  The following patch should fix this:

Index: info.el
===================================================================
RCS file: /cvs/emacs/lisp/info.el,v
retrieving revision 1.304
diff -c -r1.304 info.el
*** info.el	9 Jun 2002 00:18:15 -0000	1.304
--- info.el	9 Jun 2002 22:01:37 -0000
***************
*** 1031,1043 ****
  			  header-end t)
  			 (match-beginning 1)
  		       (point))))
!     (set (make-local-variable 'Info-header-line)
! 	 (buffer-substring header-beg header-end))
!     (setq header-line-format 'Info-header-line)
! ;;; It is useful to be able to copy the links line out of the buffer
! ;;; with M-w.
! ;;;    (narrow-to-region (1+ header-end) (point-max))
      ))
  \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
--- 1031,1050 ----
  			  header-end t)
  			 (match-beginning 1)
  		       (point))))
!     (let ((buffer-read-only nil))
!       (remove-text-properties (point-min) (1+ header-end) '(invisible nil))
!       (set (make-local-variable 'Info-header-line)
! 	   (buffer-substring header-beg header-end))
!       (setq header-line-format 'Info-header-line)
!       (add-text-properties (point-min) (1+ header-end) '(invisible t)))
      ))
+ 
+ (defun Info-toggle-header-visible ()
+   (interactive)
+   (let ((buffer-read-only nil))
+     (goto-char (point-min))
+     (alter-text-property (point) (1+ (line-end-position))
+ 			 'invisible #'null)))
  \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
***************
*** 2095,2100 ****
--- 2102,2108 ----
    (define-key Info-mode-map "9" 'Info-nth-menu-item)
    (define-key Info-mode-map "0" 'undefined)
    (define-key Info-mode-map "?" 'Info-summary)
+   (define-key Info-mode-map "+" 'Info-toggle-header-visible)
    (define-key Info-mode-map "]" 'Info-forward-node)
    (define-key Info-mode-map "[" 'Info-backward-node)
    (define-key Info-mode-map "<" 'Info-top-node)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

    A better option might be to keep this links line in the buffer, but put
    it at the extreme bottom of the buffer.

Alas, the place in the text where that line is present is at the
beginning of the node.  It would not be a good idea to alter the
buffer contents.

What if the links were in the mode line instead of a header line?

Someone else wrote:

    It looks like a display bug when you first see it: two identical lines,
    one below the other.

If the text put in the header line were changed so it would
not look like the line in the buffer, would that solve the problem?

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

[Eli Zaretskii]

On Mon, 10 Jun 2002, Richard Stallman wrote:

> Someone else wrote:

(That was me.)

>     It looks like a display bug when you first see it: two identical lines,
>     one below the other.
> 
> If the text put in the header line were changed so it would
> not look like the line in the buffer, would that solve the problem?

It depends on how do we change the header line.  Given that both lines 
use the same text, there aren't too many degrees of freedom here, I'm 
afraid.

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

[Richard Stallman]

    As I read the comments, the new behaviour with two
    almost identical header lines was a change to the worse.

Why do you think so?  A few people say they don't like it,
but nobody has given any reasons.

    It never occurred to me that copying part of the header would
    be useful

People complained when it was not possible.  In response, we made a
special command for doing it, but hardly anyone knows about that
command so it is not a very good solution.

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

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

> People complained when it was not possible.  In response, we made a
> special command for doing it, but hardly anyone knows about that
> command so it is not a very good solution.

Maybe people need more time.  I still see people using
font-lock-face-attributes, even though this variable has long been
obsoleted.

kai
-- 
~/.signature is: umop 3p!sdn    (Frank Nobis)

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

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     As I read the comments, the new behaviour with two
>     almost identical header lines was a change to the worse.
> 
> Why do you think so?  A few people say they don't like it,

A few?  The majority of those who commented on this dislike it:

David Ponce started by reporting the duplicate header line as a bug.
You responded that it was deliberate.
Stefan, Eli and Miles spoke against it (or at least suggested
various methods for hiding it or making it optional).
Francoise Romain send you a patch to implement Miles' suggestion.
I also spoke against it and sent a different proposal 
(adding `+' to toggle the visibility of the extra header line).
Alex Schroeder said he doesn't need it either.

> but nobody has given any reasons.

I think Eli gives the reason very clearly:  

        It looks like a display bug.

.. and it has already been reported as such a few days after it was
change in CVS.  So imagine the number of bug reports we'll get when
21.4 is released...

> 
>     It never occurred to me that copying part of the header would
>     be useful
> 
> People complained when it was not possible.  In response, we made a
> special command for doing it, but hardly anyone knows about that
> command so it is not a very good solution.

That "hardly anyone knows about that command" is hardly a good
argument to introduce a "display bug"... 
The command is right there on the Info menu.

Only Robert J. Chassell seems to really need to copy from the header
lines regularly -- and to be able to do that, he already knows that
setting Info-use-header-line to nil allows him to do that.

Can't we simply put that advice into NEWS or PROBLEMS or mention it
somewhere in info's doc string or its info file -- and remove the
extra header line.


In any case, I think it is a good idea to add a mouse-3 sub-menu/command
to header-lines and mode-lines to copy its contents to the kill-ring.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

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

[Richard Stallman]

It is not logical or good practice to jump straight to "Take out that
change" without thinking about the problem or looking for rejectionary
alternatives.  When a change was made to address one problem, and you
think it causes another problem, please make an effort to find a way
to rescue the change before you ask people to take it out.  In this
case, I am the only one who has tried to do that.

A couple of days ago, someone finally did tell me what problem he saw
in this change, so I proposed avenues for solving it.

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

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> A few people say they don't like it, but nobody has given any reasons.

Two reasons were already mentioned:

    . Two lines take more space than one; this _is_ a serious issue of
    course at the beginning of a node we have a lot of vertical
    whitespace and vertically oversized lines.  Now think about laptop
    users who cannot affort more than a 800x600 display: most of the
    time they will have to page down the first page of a node to get
    "real" info (esp. when they have done somethin like C-x 2 first).

    . For the innocent user the doubled text looks like an error (he
    will not know every line serves its own purpose) and once told
    about it he might think Emacs is strange...

> People complained when it was not possible.

IIRC, it was only one who complained.

> In response, we made a special command for doing it, but hardly anyone
> knows about that command so it is not a very good solution.

Only an expert will have to know about this command; we can ask him to
get familiar with it.

Please, revert the behavior (and try to keep the 21.x series as
consistent as possible).

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

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

[Miles Bader]

Karl Eichwalder <keichwa@gmx.net> writes:
> > People complained when it was not possible.
> 
> IIRC, it was only one who complained.

... and even he thinks the double header lines are a mistake!

-Miles
-- 
"Most attacks seem to take place at night, during a rainstorm, uphill,
 where four map sheets join."   -- Anon. British Officer in WW I

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

[Richard Stallman]

	. Two lines take more space than one; this _is_ a serious issue of
	course at the beginning of a node we have a lot of vertical
	whitespace and vertically oversized lines.

The unhidden node line only takes up space until you scroll down in
the buffer.  By contrast, the header line takes up space all the time.
If space is the concern, we should try to get rid of the header line.

	. For the innocent user the doubled text looks like an error (he
	will not know every line serves its own purpose) and once told
	about it he might think Emacs is strange...

Getting rid of the header line would solve that too.  Maybe getting
rid of the header line is an improvement all around.

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
> When a change was made to address one problem, and you
> think it causes another problem, please make an effort to find a way
> to rescue the change before you ask people to take it out.  In this
> case, I am the only one who has tried to do that.

But you also have to consider whether it's worth the effort.

You seem to be treating Bob's desire for a copyable nodes-line as
something that is extremely urgent.  It is not.  It's something that
would be nice, but which really isn't that important in the end, and
its certainly not worth screwing up an otherwise good interface for.

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.

> Getting rid of the header line would solve that too.  Maybe getting
> rid of the header line is an improvement all around.

No.

Having a constant way of seeing adjacent nodes is very valuable, I
think.  It gives you a sense of context that you don't really get with
the old only-at-the-beginning node-lines.  Morever, it's clickable, so
serves as an easy way of doing node navigation with the mouse.

I'll bet if you actually asked a bunch of newbies, they'd think you're
nuts for even suggesting this.

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin

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

[Eli Zaretskii]

On 11 Jun 2002, Miles Bader wrote:

> > Getting rid of the header line would solve that too.  Maybe getting
> > rid of the header line is an improvement all around.
> 
> No.
> 
> Having a constant way of seeing adjacent nodes is very valuable, I
> think.

Yes, I agree.

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

[Miles Bader]

Miles Bader <miles@gnu.org> 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'

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

[Robert J. Chassell]

Miles Bader <miles@lsi.nec.co.jp> suggests:

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

Yes, this should work!

The output would look like this, where the first line is the new style
*info* header line, the second line is similar to the first line of an
old-style Info file, but contains only the `File:' and `Node:' tags,
and the following visible line is the title in whatever face or voice
you have set for Info:

    Next: Printed Books,  Prev: Using Texinfo,  Up: Overview
    File: texinfo,  Node: Info Files

    Info files

      An Info file is a Texinfo file formatted so that the Info
    documentation reading program can operate on it.  (`makeinfo' and
    `texinfo-format-buffer' are two commands that convert a Texinfo file
    into an Info file.) ....


When I want to send a a long-winded, but I hope informative and
inspiring reference to someone, I copy

    File: texinfo,  Node: Info Files

as usual.  When I want to send a more efficient reference to a
knowledgeable person, I use the `Info-specify-current-node-name'
command to construct the expression:

    (texinfo)Info Files

(The `Info-specify-current-node-name' is simply the
`Info-copy-current-node-name' command renamed to make more sense than
the latter, which does *not* copy the node name, which is not
mentioned in the new style *info* header line.


[digression]

By the way, how do you fix an instance of a `plain vanilla' Emacs from
the current CVS sources so that you can move around an Info file using
the next, prev, and up key and mouse bindings?

This bug was reported some time ago but no permanent fix has been
installed in CVS; I simply cannot remember the temporary fix someone
suggested so I can use the new style *info* header lines.

I normally `(setq Info-use-header-line nil)' in my .emacs file, which
solves the problem for me, but for testing, I run

     /usr/local/bin/emacs -q --no-site-file --eval '(blink-cursor-mode 0)'

and Info fails when I type `n' in a node, with the error message:

    Info-extract-pointer: Node has no Next

(This morning's CVS snapshot, Tue, 2002 Jun 11 11:39 UTC,
GNU Emacs 21.3.50.29 (i686-pc-linux-gnu, X toolkit).)

--
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Richard Stallman]

    By the way, how do you fix an instance of a `plain vanilla' Emacs from
    the current CVS sources so that you can move around an Info file using
    the next, prev, and up key and mouse bindings?

I think the change below should fix that.  I also cleaned it up some,
to make it easier to make other changes in handling the header line
and the buffer's node line.

There are some other undesirable things in this code.  For instance,
the items in the text line have a mouse-face that works, and only
mouse-2 follows the link.  But when in the header line, there is no
mouse-face, and both mouse-1 and mouse-2 follow the link.
The discrepancy between them seems ugly.

If the links are hidden in the line in th ebufer, this discrepancy
will go away.


*** info.el.~1.304.~	Mon Jun 10 04:28:29 2002
--- info.el	Tue Jun 11 21:02:20 2002
***************
*** 999,1005 ****
  	(if Info-enable-active-nodes (eval active-expression))
  	(Info-fontify-node)
  	(if Info-use-header-line
! 	    (Info-setup-header-line)
  	  (setq Info-header-line nil)
  	  (setq header-line-format nil)) ; so the header line isn't displayed
  	(run-hooks 'Info-selection-hook)))))
--- 999,1012 ----
  	(if Info-enable-active-nodes (eval active-expression))
  	(Info-fontify-node)
  	(if Info-use-header-line
! 	    (progn
! 	      (setq Info-header-line
! 		    (get-text-property (point-min) 'header-line))
! 	      (setq header-line-format 'Info-header-line)
! ;;; It is useful to be able to copy the links line out of the buffer
! ;;; with M-w.
! ;;;           (narrow-to-region (1+ header-end) (point-max))
! 	      )
  	  (setq Info-header-line nil)
  	  (setq header-line-format nil)) ; so the header line isn't displayed
  	(run-hooks 'Info-selection-hook)))))
***************
*** 1016,1044 ****
  			") "
  			(or Info-current-node ""))))))
  \f
- ;; Skip the node header and make it into a header-line.  This function
- ;; should be called when the node is already narrowed.
- (defun Info-setup-header-line ()
-   (goto-char (point-min))
-   (let* ((case-fold-search t)
- 	 (header-end (save-excursion (forward-line 1) (1- (point))))
- 	 ;; If we find neither Next: nor Prev: link, show the entire
- 	 ;; node header.  Otherwise, don't show the File: and Node:
- 	 ;; parts, to avoid wasting precious space on information that
- 	 ;; is available in the mode line.
- 	 (header-beg (if (re-search-forward
- 			  "\\(next\\|prev[ious]*\\): "
- 			  header-end t)
- 			 (match-beginning 1)
- 		       (point))))
-     (set (make-local-variable 'Info-header-line)
- 	 (buffer-substring header-beg header-end))
-     (setq header-line-format 'Info-header-line)
- ;;; It is useful to be able to copy the links line out of the buffer
- ;;; with M-w.
- ;;;    (narrow-to-region (1+ header-end) (point-max))
-     ))
- \f
  ;; Go to an info node specified with a filename-and-nodename string
  ;; of the sort that is found in pointers in nodes.
  
--- 1023,1028 ----
***************
*** 2347,2352 ****
--- 2331,2337 ----
    (setq Info-tag-table-buffer nil)
    (make-local-variable 'Info-history)
    (make-local-variable 'Info-index-alternatives)
+   (make-local-variable 'Info-header-line)
    (set (make-local-variable 'tool-bar-map) info-tool-bar-map)
    ;; This is for the sake of the invisible text we use handling titles.
    (make-local-variable 'line-move-ignore-invisible)
***************
*** 2601,2615 ****
    ;; Only fontify the node if it hasn't already been done.  [We pass in
    ;; LIMIT arg to `next-property-change' because it seems to search past
    ;; (point-max).]
!   (unless (and (< (next-property-change (point-min) nil (point-max))
! 		  (point-max))
! 	       ;; But do put the text properties if the local-map property
! 	       ;; is inconsistent with Info-use-header-line's value.
! 	       (eq
! 		(= (next-single-property-change
! 		    (point-min) 'local-map nil (point-max))
! 		   (point-max))
! 		(null Info-use-header-line)))
      (save-excursion
        (let ((buffer-read-only nil)
  	    (case-fold-search t))
--- 2586,2593 ----
    ;; Only fontify the node if it hasn't already been done.  [We pass in
    ;; LIMIT arg to `next-property-change' because it seems to search past
    ;; (point-max).]
!   (unless (< (next-property-change (point-min) nil (point-max))
! 	     (point-max))
      (save-excursion
        (let ((buffer-read-only nil)
  	    (case-fold-search t))
***************
*** 2630,2653 ****
  				   'help-echo
  				   (concat "Go to node "
  					   (buffer-substring nbeg nend)))
! 		;; Don't bind mouse events on the header line if we
! 		;; aren't going to display the header line.
! 		(when Info-use-header-line
! 		  (let ((fun (cdr (assoc tag '(("Prev" . Info-prev)
! 					       ("Next" . Info-next)
! 					       ("Up" . Info-up))))))
! 		    (when fun
! 		      (let ((keymap (make-sparse-keymap)))
! 			(define-key keymap [header-line mouse-1] fun)
! 			(define-key keymap [header-line mouse-2] fun)
! 			(put-text-property tbeg nend 'local-map keymap)))))
! 		(if (not Info-use-header-line)
! 		    ;; In case they switched Info-use-header-line off
! 		    ;; in the middle of an Info session, some text
! 		    ;; properties may have been left lying around from
! 		    ;; past visits of this node.  Remove them.
! 		    (remove-text-properties tbeg nend '(local-map nil)))
! 		  ))))
  	(goto-char (point-min))
  	(while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*+\\|=+\\|-+\\|\\.+\\)$"
  				  nil t)
--- 2608,2641 ----
  				   'help-echo
  				   (concat "Go to node "
  					   (buffer-substring nbeg nend)))
! 		;; Always set up the text property keymap.
! 		;; It will be used either in the buffer
! 		;; or copied in the header line.
! 		(let ((fun (cdr (assoc tag '(("Prev" . Info-prev)
! 					     ("Next" . Info-next)
! 					     ("Up" . Info-up))))))
! 		  (when fun
! 		    (let ((keymap (make-sparse-keymap)))
! 		      (define-key keymap [header-line mouse-1] fun)
! 		      (define-key keymap [header-line mouse-2] fun)
! 		      (define-key keymap [header-line down-mouse-1] 'ignore)
! 		      (define-key keymap [mouse-2] fun)
! 		      (put-text-property tbeg nend 'keymap keymap))))
! 		  )))
! 	  (goto-char (point-min))
! 	  (let* ((header-end (save-excursion (end-of-line) (point)))
! 		 ;; If we find neither Next: nor Prev: link, show the entire
! 		 ;; node header.  Otherwise, don't show the File: and Node:
! 		 ;; parts, to avoid wasting precious space on information that
! 		 ;; is available in the mode line.
! 		 (header-beg (if (re-search-forward
! 				  "\\(next\\|prev[ious]*\\): "
! 				  header-end t)
! 				 (match-beginning 1)
! 			       (point))))
! 	    (put-text-property (point-min) (1+ (point-min))
! 			       'header-line
! 			       (buffer-substring header-beg header-end))))
  	(goto-char (point-min))
  	(while (re-search-forward "\n\\([^ \t\n].+\\)\n\\(\\*+\\|=+\\|-+\\|\\.+\\)$"
  				  nil t)

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

[Robert J. Chassell]

Today's CVS snapshot, Wed, 2002 Jun 12  10:20 UTC,
GNU Emacs 21.3.50.29 (i686-pc-linux-gnu, X toolkit)

       By the way, how do you fix an instance of a `plain vanilla' Emacs from
       the current CVS sources so that you can move around an Info file using
       the next, prev, and up key and mouse bindings?

   I think the change below should fix that.  

Yes, it does, at least on a short test.

(The patch partial failed.  The `(defun Info-setup-header-line ()'
segment was not removed from the updated file, but I did that manually.)

   There are some other undesirable things in this code.  For instance,
   the items in the text line have a mouse-face that works, and only
   mouse-2 follows the link.  ...

Miles' suggestion avoids this; for the text line,

    ... put _only_ the `File:' and `Node:' tags in the (displayed) buffer --

His suggestion also removes redundancy and prevents the second line
from looking like a bug.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Richard Stallman]

    Miles' suggestion avoids this; for the text line,

	... put _only_ the `File:' and `Node:' tags in the (displayed) buffer --

    His suggestion also removes redundancy and prevents the second line
    from looking like a bug.

I checked in a further change which does that and other related things.

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

[Robert J. Chassell]

Your new layout for the header line and `File:' and `Node:' tags in
the *info* buffer works fine and is excellent.  I have shifted over
to it.

-- 
    Robert J. Chassell                  bob@rattlesnake.com
    Rattlesnake Enterprises             http://www.rattlesnake.com

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

[Richard Stallman]

I am glad you appreciate it.

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

[Karl Eichwalder]

"Robert J. Chassell" <bob@rattlesnake.com> writes:

> Your new layout for the header line and `File:' and `Node:' tags in
> the *info* buffer works fine and is excellent.

It is interesting, but it is of no use to _new_ users (IMO); is it
possible to offer this tags line as a configuration option?  Only a very
small fraction of all users might be interested in this line for
cut-and-paste purposes.

> I have shifted over to it.

I'd like to get rid of it ;)  Better add page-down and page-up buttons to
the header line; useful in case the user doesn't have a scroll bar but
wants to use the mouse for paging.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

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

[Richard Stallman]

	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.

That seems like a good idea to try.  Actually editing the buffer is
undesirable, though.  Perhaps It would be better to make the links
invisible and intangible.  On the other hand, then copying it would
give peculiar results -- the links would appear in the copy.

This is leading to issues that are more bigger than just Info.

    > We already have graphical navigation buttons on the tool bar.

    Thanks for the reminder!  The header line must not appear at all if the
    tool bar is enabled.

That could be a good idea in addition to the above.

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

[Miles Bader]

Richard Stallman <rms@gnu.org> writes:
>     > We already have graphical navigation buttons on the tool bar.
> 
>     Thanks for the reminder!  The header line must not appear at all if the
>     tool bar is enabled.
> 
> That could be a good idea in addition to the above.

I'm not entirely sure I understand what's being suggested.

If it's that the header-line should only show up when there's no
tool-bar, that's a bad idea:

In addition to providing something to click on for navigation, the
header-line serves to provide context, by showing the name of the
adjacent nodes; in fact, I'd argue that this is it's most important
function.  The tool-bar, by contrast, only gives some unnamed buttons --
that's useful, but it's not nearly good enough to replace the
header-line.

-Miles
-- 
.Numeric stability is probably not all that important when you're guessing.

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

[Karl Eichwalder]

Miles Bader <miles@lsi.nec.co.jp> writes:

> If it's that the header-line should only show up when there's no
> tool-bar, that's a bad idea:

Yes, that was my idea.

> In addition to providing something to click on for navigation, the
> header-line serves to provide context, by showing the name of the
> adjacent nodes; in fact, I'd argue that this is it's most important
> function.  The tool-bar, by contrast, only gives some unnamed buttons --
> that's useful, but it's not nearly good enough to replace the
> header-line.

There is some truth about your observation (even if these labels often
are rather cryptic).

If possible I'd like to see this info added to the tool tips:

    Go to next node: Intro

Then consider to add an item to the tool-bar able to show menu
containing _all_ adjacent and same level nodes.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

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

[Alex Schroeder]

Miles Bader <miles@lsi.nec.co.jp> writes:

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

I like it.

Alex.
-- 
http://www.electronicintifada.net/diaries/index.html
http://www.us-israel.org/jsource/US-Israel/hr2506c.html

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

[Karl Eichwalder]

Richard Stallman <rms@gnu.org> writes:

> The unhidden node line only takes up space until you scroll down in
> the buffer.  By contrast, the header line takes up space all the time.
> If space is the concern, we should try to get rid of the header line.

This is what I thought at first, too.  But as Miles explained, most
people might like such a permanent navigation bar -- most web pages are
cluttered with it.

> Getting rid of the header line would solve that too.  Maybe getting
> rid of the header line is an improvement all around.

To avoid the so called "display bug" (same visible info twice) the
proposal was to make look both lines different.  We can achive this
goal replacing "Next: ", "Prev: ", and  "Up: " with graphical elements
("-> ", "<- ", and "^ " or real arrows if supported).

Arguable enhancement proposal: repeat the navigation bar at the end of
every node page.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

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

[Eli Zaretskii]

On Tue, 11 Jun 2002, Karl Eichwalder wrote:

> To avoid the so called "display bug" (same visible info twice) the
> proposal was to make look both lines different.  We can achive this
> goal replacing "Next: ", "Prev: ", and  "Up: " with graphical elements
> ("-> ", "<- ", and "^ " or real arrows if supported).

We already have graphical navigation buttons on the tool bar.  Having 
"->" and such likes in the header line might not be self-explanatory 
enough; OTOH, "Next" etc. don't take up too much space as compared to
the ASCII art you propose.

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

[Karl Eichwalder]

Eli Zaretskii <eliz@is.elta.co.il> writes:

> We already have graphical navigation buttons on the tool bar.

Thanks for the reminder!  The header line must not appear at all if the
tool bar is enabled.

> Having "->" and such likes in the header line might not be
> self-explanatory enough; OTOH, "Next" etc. don't take up too much
> space as compared to the ASCII art you propose.

Yes, but the goal was to make the header line _look_ different to
prevent the user from thinking he has encountered a display bug.

-- 
ke@suse.de (work) / keichwa@gmx.net (home):              |
http://www.suse.de/~ke/                                  |      ,__o
Free Translation Project:                                |    _-\_<,
http://www.iro.umontreal.ca/contrib/po/HTML/             |   (*)/'(*)

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

[Eli Zaretskii]

On Fri, 7 Jun 2002, Richard Stallman wrote:

> Nobody has presented a real reason why this is bad.

It looks like a display bug when you first see it: two identical lines,
one below the other.

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

[David Ponce]

Hi Kim,

I tried your patch and loved it!
It would be nice to have it installed ;-)

David
____________________________________________________________
Faites un voeu et puis Voila ! www.voila.fr 
Avec Voila Mail, consultez vos e-mails sur votre mobile Wap. 

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

[David Ponce]

Hi Kim,

I tried your patch and loved it!
It would be nice to have it installed ;-)

David


__________________________________________________________________
Your favorite stores, helpful shopping tools and great gift ideas. Experience the convenience of buying online with Shop@Netscape! http://shopnow.netscape.com/

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/