From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Stephen J. Turnbull" Newsgroups: gmane.emacs.devel Subject: Re: Emacs learning curve Date: Tue, 13 Jul 2010 15:17:08 +0900 Message-ID: <87d3urj47v.fsf@uwakimon.sk.tsukuba.ac.jp> References: <4C3B6A8A.80105@gmx.de> <87wrt0e81n.fsf@telefonica.net> <62E9699C07054418AB66F9C5FCB54E5C@us.oracle.com> <87sk3oe3la.fsf@telefonica.net> <1154D96E7D2F401D849266F359E44BB9@us.oracle.com> <87ocecdzou.fsf@telefonica.net> <87hbk4i1m4.fsf@uwakimon.sk.tsukuba.ac.jp> <87bpacdpwl.fsf@telefonica.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1279002218 24508 80.91.229.12 (13 Jul 2010 06:23:38 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Jul 2010 06:23:38 +0000 (UTC) Cc: emacs-devel@gnu.org To: =?iso-8859-1?Q?=D3scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jul 13 08:23:35 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 1OYYty-0002Ay-UW for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 08:23:35 +0200 Original-Received: from localhost ([127.0.0.1]:49393 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYYtx-00030x-LQ for ged-emacs-devel@m.gmane.org; Tue, 13 Jul 2010 02:23:33 -0400 Original-Received: from [140.186.70.92] (port=58690 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OYYto-00030o-1J for emacs-devel@gnu.org; Tue, 13 Jul 2010 02:23:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OYYtm-00008s-JY for emacs-devel@gnu.org; Tue, 13 Jul 2010 02:23:23 -0400 Original-Received: from mtps01.sk.tsukuba.ac.jp ([130.158.97.223]:54465) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OYYtm-00008G-3H for emacs-devel@gnu.org; Tue, 13 Jul 2010 02:23:22 -0400 Original-Received: from uwakimon.sk.tsukuba.ac.jp (uwakimon.sk.tsukuba.ac.jp [130.158.99.156]) by mtps01.sk.tsukuba.ac.jp (Postfix) with ESMTP id D3C451537B2; Tue, 13 Jul 2010 15:23:18 +0900 (JST) Original-Received: by uwakimon.sk.tsukuba.ac.jp (Postfix, from userid 1000) id 4F8A31A2691; Tue, 13 Jul 2010 15:17:08 +0900 (JST) In-Reply-To: <87bpacdpwl.fsf@telefonica.net> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" ed3b274cc037 XEmacs Lucid (x86_64-unknown-linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) 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:127146 Archived-At: =D3scar Fuentes writes: > I think it is more reasonable to add alias, perhaps make some commands > non-interactive and add new ones with the "new" terms, and replace all > references on the Emacs manual (not the Elisp manual) to use the new > terms. Well, we already have some of that (cf the `next-line' command vs. the `forward-line' function), but I can't say I'm a big fan of it even as limited as it is. It also has the major huge defect from your point of view that it enables the COFs ("cranky old fart") to continue coding in traditional Emacs LISP, so you have the worst of both worlds: good code written in the traditional dialect which the newcomers have difficulty reading, and code of really ambiguous practicality (ie, CRAP) written by newcomers in the newfangled dialect (remember, in current LISP most commands that have very similar functionality to separate API functions are duplicated in this way because they have have DWIM-ish aspects that make them inappropriate for use in programs). > I don't see why old timers would have a problem with this. After > all, if we expect from every newcomer to learn Emacs-ish, As Drew points out, we don't have to connect Emacs-ish to LISP naming, though. Most newcomers are users who learn keybindings or discover commands via the menus, and don't program or use LISP command names at all (they refer to commands by their bindings, not by their names). Most new programmers among those new users actually use macros for almost all of their programming. Most new e-LISP programmers among those new programmers use a very small fraction of all Emacs commands. The small fraction (5%? 1%?) of all new users who actually go on to program modes etc will mostly be using existing code as a model for the arcane stuff. > we can expect from the veterans to learn that Paste means the same > as Yank (in case they still don't know.) And how do you explain to newcomers why "Paste" is on the C-y key? Currently most one-letter control chords have mnemonic names (f =3D forward, p =3D previous, y =3D yank, etc). Also, to me at least, "paste" does not mean the same thing as "yank". Yank is an operation that communicates between the Emacs kill ring and an Emacs buffer. Paste is an operation that communicates between a system data store (in my case, either the X PRIMARY selection or the Mac clipboard) and an Emacs buffer. The semantics are therefore subtly different, and in fact this is valuable to me because most of the stuff on the system clipboard is useless to my Emacs work, and similarly almost nothing on my Emacs kill ring is useful outside of Emacs. > Sure, there are technical details, none hard, although maybe a bit > controversial... Oh, wait! Oh, wait! is right. Many people have the old versions embedded in private modes, additional functions, skeletal library templates, etc, both in use and as quoted boilerplate for inserting into new code. Not to mention people who are using older versions with some backported code, as well as forked projects. While none of these are a consideration for Emacs as such, if those users or projects abandon work on Emacs or related projects, it will be a loss to Emacs. Balanced by what gain? I don't really see much gain; people who use and program Emacsen are a special breed, and I don't think it's the particular LISP dialect that puts up the largest hurdles to newcomers. > > It would be much easier to get support if you create such a pictorial > > vocabulary for use by new users and non-programmers. Bonus points for > > making it possible to create a "keyboard macro" using only the mouse, > > translate it to Lisp, and associate the pictures with the appropriate > > Lisp commands. And of course much of the relevant vocabulary will > > already be present in collections of icons provided by GNOME et al. >=20 > Not really, the long term investment should be to teach modern terms to > Emacs, instead of insisting on forcing every newcomer to learn the Emacs > terms. Please reread what I wrote. My point *is* to teach Emacs a modern vocabulary. However, the one I propose doesn't have the defects I point out for changing LISP above, because it's used in a completely different context that does not conflict with historical LISP definitions.