From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Mon, 02 Aug 2010 22:31:23 +0200 Message-ID: References: <10954D02-E217-49F3-8824-757DA34074AB@gmail.com> <201008021657.01254.tassilo@member.fsf.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: dough.gmane.org 1280781106 31559 80.91.229.12 (2 Aug 2010 20:31:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2010 20:31:46 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , Tom , emacs-devel@gnu.org To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 02 22:31:43 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 1Og1ff-0006NZ-0L for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 22:31:39 +0200 Original-Received: from localhost ([127.0.0.1]:54434 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og1fe-0004LE-E0 for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 16:31:38 -0400 Original-Received: from [140.186.70.92] (port=42926 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Og1fV-0004Jw-5S for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:31:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Og1fU-00025y-AR for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:31:29 -0400 Original-Received: from impaqm1.telefonica.net ([213.4.138.1]:15017) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Og1fU-00025i-2i for emacs-devel@gnu.org; Mon, 02 Aug 2010 16:31:28 -0400 Original-Received: from IMPmailhost4.adm.correo ([10.20.102.125]) by IMPaqm1.telefonica.net with bizsmtp id pXhR1e01u2iL0W201YXSqS; Mon, 02 Aug 2010 22:31:26 +0200 Original-Received: from ceviche.home ([83.61.38.247]) by IMPmailhost4.adm.correo with BIZ IMP id pYXP1e0075KwfZf1kYXQhj; Mon, 02 Aug 2010 22:31:26 +0200 X-Brightmail-Tracker: AAAAAA== X-TE-authinfo: authemail="monnier$movistar.es" |auth_email="monnier@movistar.es" X-TE-AcuTerraCos: auth_cuTerraCos="cosuitnetc01" Original-Received: by ceviche.home (Postfix, from userid 20848) id 7D08C66125; Mon, 2 Aug 2010 22:31:23 +0200 (CEST) In-Reply-To: <201008021657.01254.tassilo@member.fsf.org> (Tassilo Horn's message of "Mon, 2 Aug 2010 16:57:00 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) 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:128160 Archived-At: >> > The idea (for me anyway) is not to lure new users (I have given up >> > the hope to understand what they need/want a lot time ago), but just >> > to make Emacs better. And following standards (be they protocols, >> > libraries, terminology, behavior) is generally a good thing. So the >> > only reason not to follow standards is when we have a better story. >> > In the case of yank/paste and point/cursor, I don't think our story >> > is that much better: it's more a historical accident. >> Wouldn't that be an argument to use window/pane too, instead of >> frame/window? I guess it would, yes. I haven't heard the term "pane" used nearly as much, but "windows" is obviously a problem. So, same as for the others, I'd be willing to entertain such a change, provided someone suggests a patch. > That was the first thing that came in my mind, too. But in contrast to > copy/cut/paste, current and "modern" names are not disjunctive, so there > is no possibility to provide aliases for the old names. I wouldn't jump to conclusion. Rather than making backward compatibility impossible (which means that it can't be done since backward compatibility is an absolute requirement in this case), it just means it's yet harder to come up with such a patch. > One major problem I see with those modernization ideas is that it would > make it even harder to write packages that work on all emacs flavours. I'd expect the backward compatibility aliases to stick around for a *long* time: take a look at the aliases for "screen rather than frame", some of them are still with us (tho I think they deserve to disappear now). Stefan