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                  address@hidden
    Rattlesnake Enterprises             http://www.rattlesnake.com