From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lennart Borgman Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Mon, 2 Aug 2010 17:50:49 +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=UTF-8 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1280766537 5357 80.91.229.12 (2 Aug 2010 16:28:57 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Mon, 2 Aug 2010 16:28:57 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , Stefan Monnier , 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 18:28:55 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 1Ofxsj-0003eS-J0 for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 18:28:54 +0200 Original-Received: from localhost ([127.0.0.1]:42997 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OfxZi-0003zy-GI for ged-emacs-devel@m.gmane.org; Mon, 02 Aug 2010 12:09:14 -0400 Original-Received: from [140.186.70.92] (port=58580 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OfxJ0-0003rP-1m for emacs-devel@gnu.org; Mon, 02 Aug 2010 11:52:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OfxIE-0005Ng-EC for emacs-devel@gnu.org; Mon, 02 Aug 2010 11:51:11 -0400 Original-Received: from mail-qw0-f41.google.com ([209.85.216.41]:56174) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OfxIE-0005NM-Bv; Mon, 02 Aug 2010 11:51:10 -0400 Original-Received: by qwk4 with SMTP id 4so1881174qwk.0 for ; Mon, 02 Aug 2010 08:51:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=FJicMWr1isEGtLXrvpmR7oPYKgvnHUk31HgbXWBGv/Y=; b=NnXvB/QS028iHrzHSIoh0YfTKIE05lox3qJxNkz0TELkCh31jAGUNiVt++lseZrne5 qT8U7R+Nq6PGwQ3qhFmHYROaYGKe7bx11QcmkDZFOzsWlHxEmXlGh7WKQ5IFHsS+t+1b 2/JGPP2KSbQtpGKguETpyRch9z+o75X12okLI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=MWZg1OLcIfwL/vUNw8bDu4X4XsnMa7ch7NJO5ifkfcPZoPmxzwqe59hgPdWD7Nx2k1 z1IPijB5RKyg+LfEanV4rjwZSY18XGQ0MlqIQK8LufW5JU2JyTwFUAjGua3M+mbqDfBC u6QN+D8Xz6KyieYlHoC1MaJ+BNKGo5h4GiAog= Original-Received: by 10.229.192.13 with SMTP id do13mr230383qcb.30.1280764269285; Mon, 02 Aug 2010 08:51:09 -0700 (PDT) Original-Received: by 10.229.9.84 with HTTP; Mon, 2 Aug 2010 08:50:49 -0700 (PDT) In-Reply-To: <201008021657.01254.tassilo@member.fsf.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) 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:128131 Archived-At: On Mon, Aug 2, 2010 at 4:57 PM, Tassilo Horn wrote= : >> >> Wouldn't that be an argument to use window/pane too, instead of >> frame/window? > > That was the first thing that came in my mind, too. =C2=A0But 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. Maybe it just requires some more thoughts? I do not think it is a blocker. > 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. Perhaps one can also say that this kind of backward compatibility blocks new creative ideas for Emacs? And it stops perhaps users from upgrading. > Either you'd need to define lots of compatibility code or use the old > name aliases. Or just say that if you want a newer version of my-module-x you need to upgrade Emacs. > Neither of those alternatives looks desirable to me, and > in any case it makes life harder for potential new developers. I think in most cases they will not care about older Emacs versions.