From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Robert J. Chassell" Newsgroups: gmane.emacs.devel Subject: Re: Patch to disable links line in *info* buffer Date: Mon, 10 Jun 2002 16:46:23 +0000 (UTC) Sender: emacs-devel-admin@gnu.org Message-ID: References: <87bsaos1fl.fsf@orebokech.com> <200206072322.g57NMtK27277@aztec.santafe.edu> <5xbsam1tje.fsf@kfs2.cua.dk> <87wut9tppe.fsf@orebokech.com> <200206101359.g5ADx7b28021@rum.cs.yale.edu> Reply-To: bob@rattlesnake.com NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1023728998 25104 127.0.0.1 (10 Jun 2002 17:09:58 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 10 Jun 2002 17:09:58 +0000 (UTC) Cc: bob@rattlesnake.com Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17HSg2-0006Wn-00 for ; Mon, 10 Jun 2002 19:09:58 +0200 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17HT2x-0005TL-00 for ; Mon, 10 Jun 2002 19:33:39 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17HSfD-0007M8-00; Mon, 10 Jun 2002 13:09:07 -0400 Original-Received: from megalith.rattlesnake.com ([140.186.114.245] helo=localhost) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17HSJH-0007kn-00 for ; Mon, 10 Jun 2002 12:46:27 -0400 Original-Received: by rattlesnake.com via sendmail from stdin id (Debian Smail3.2.0.114) Mon, 10 Jun 2002 16:46:23 +0000 (UTC) Original-To: emacs-devel@gnu.org In-Reply-To: <200206101359.g5ADx7b28021@rum.cs.yale.edu> (monnier+gnu/emacs@rum.cs.yale.edu) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:4709 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:4709 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