From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: Emacs learning curve Date: Mon, 12 Jul 2010 15:03:10 -0700 Message-ID: <62E9699C07054418AB66F9C5FCB54E5C@us.oracle.com> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1278972274 19043 80.91.229.12 (12 Jul 2010 22:04:34 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 12 Jul 2010 22:04:34 +0000 (UTC) To: "=?iso-8859-1?Q?'=D3scar_Fuentes'?=" , Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 13 00:04:32 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1OYR71-0005bC-M2 for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 00:04:32 +0200 Original-Received: from localhost ([127.0.0.1]:39125 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYR70-0003Bi-VN for ged-emacs-devel@m.gmane.org; Mon, 12 Jul 2010 18:04:31 -0400 Original-Received: from [140.186.70.92] (port=39749 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYR6v-0003Bd-G1 for emacs-devel@gnu.org; Mon, 12 Jul 2010 18:04:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYR6u-0001Qq-7e for emacs-devel@gnu.org; Mon, 12 Jul 2010 18:04:25 -0400 Original-Received: from rcsinet10.oracle.com ([148.87.113.121]:18402) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYR6u-0001Qe-0e for emacs-devel@gnu.org; Mon, 12 Jul 2010 18:04:24 -0400 Original-Received: from rcsinet15.oracle.com (rcsinet15.oracle.com [148.87.113.117]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o6CM4L3Y025035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 12 Jul 2010 22:04:22 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o6CM4I5O032499; Mon, 12 Jul 2010 22:04:19 GMT Original-Received: from abhmt003.oracle.com by acsmt354.oracle.com with ESMTP id 399103311278972191; Mon, 12 Jul 2010 15:03:11 -0700 Original-Received: from dradamslap1 (/130.35.178.194) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 12 Jul 2010 15:03:11 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcsiBFaziMQ4nAfSTK21j1qkuh+LIwAAsgPA In-Reply-To: <87wrt0e81n.fsf@telefonica.net> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090207.4C3B9164.0144:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:127125 Archived-At: > >> Obviously, there is no reason to choose words perversely > >> (e.g. use "red" when we mean green). > > > > Or use "scroll-up" where it means scroll down, or use > > "split-horizontally" where it splits vertically ;) > > Good one. Actually no, bad one. I specifically chose red/green and _not_ up/down, because up from one vantage point is down from another. _Not_ so for red/green. It is not perverse to call something "up" which someone else might naturally think of as down - it depends on the context. The question of whether to consider scrolling from the point of view of the view port / window or the point of view of the paper / data surface / buffer (which is moving?) is as old as the hills. And the answer sometimes depends on the particular application in a logical way (think cockpit); otherwise it is arbitrary. Similar considerations apply to splitting horizontally/vertically. We can all agree on which is horizontal and which is vertical between _ and |, but what happens when something is _split_ horizontally? As soon as you say "split", the ambiguity/choice goes away. A different verb choice could have been made. If the choice were to call it "duplicating" the window, then it might make sense to call what we call horizontal splitting "vertical duplicating": you duplicate a window above or below itself. But with the point of view of splitting (the verb), the answer unambiguosly agrees with Emacs terminology - you do in fact split the window horizontally. Take an axe, hold it horizontally, and split the window. Go ahead. You get two windows disposed vertically, one above the other. It is simply incorrect to say that "`split-horizontally' splits vertically". Bad one, I'm afraid. Looking at the _result_ rather than the action of splitting, you can indeed make the point that the result is a vertical configuration. That's what you see, vertical placement, and that's what you care about, so you could well argue that `vertical' should be part of the name somehow. But you could also argue that the window dividing line, which is also a result, is horizontal. It's arguably a toss-up, but I would agree that the windows and their placement are more important than the orientation of the divider. But wrt the action, if it is viewed as a splitting action (and not, say, duplicating), there is only one correct answer: the terminology that Emacs uses. Should Emacs have chosen to think about the action as splitting? Should Emacs have emphasized the verb/action and not the resulting positions? This is arguable, but it's not terribly interesting either way. What's the point? (1) The Emacs terminology for up/down vertical/horizontal (split) is not silly. (2) Some such things are arbitrary, or you can at least come up with reasonable arguments for either choice. (3) The same is not true for other things, such as red/green. And that's why I purposefully chose red/green for my example. So no, the petty put-down, trying to use `split-horizontally' to point out how Emacs chooses words perversely, is simply not well thought through. I'm sure there are some examples of poor word choice in Emacs terminology, but your argument based on the example of up/down is specious. And what might seem "natural" to you wrt what scrolling "up" means is not necessarily natural to everyone or, especially, to all contexts. Some graphical design systems have both notions of scrolling (and other view-port vs paper movements): they let you work either way, thinking either that you are moving the window over the paper or moving the paper under the window. Different contexts can make one or the other point of view (and terminology) seem more appropriate/natural. And apps that provide alternative contexts also employ both terminologies - they speak about both panning the view port left and panning the paper left, meaning opposite directions. Users can handle this degree of complexity. ;-) None of this is trivial or unimportant - words do matter. And none of it has been designed in Emacs without thought, I am sure. That's not to say that there is never room for improvement. It is to say, "a little humility, please"; you might not be the first person to think about this. And things might not be as silly or unnatural as you think. (Disclaimer: I was not involved in the Emacs choices for scroll "up" or split "horizontally".)