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: Apologia for bzr Date: Tue, 7 Jan 2014 01:02:53 +0100 Message-ID: References: <20140103152117.GA16679@c3po> <20140104082857.GA22010@thyrsus.com> <52CB12DE.7040905@dancol.org> <87lhysu0t9.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b874d8278737e04ef561b02 X-Trace: ger.gmane.org 1389053018 2613 80.91.229.3 (7 Jan 2014 00:03:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 7 Jan 2014 00:03:38 +0000 (UTC) Cc: Emacs-Devel devel To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jan 07 01:03:46 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1W0K92-0004ud-Lb for ged-emacs-devel@m.gmane.org; Tue, 07 Jan 2014 01:03:44 +0100 Original-Received: from localhost ([::1]:38145 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0K92-0003uT-69 for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 19:03:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0K8w-0003uM-EJ for emacs-devel@gnu.org; Mon, 06 Jan 2014 19:03:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0K8v-0001gy-B8 for emacs-devel@gnu.org; Mon, 06 Jan 2014 19:03:38 -0500 Original-Received: from mail-wi0-x230.google.com ([2a00:1450:400c:c05::230]:33328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0K8t-0001gg-9x; Mon, 06 Jan 2014 19:03:35 -0500 Original-Received: by mail-wi0-f176.google.com with SMTP id hq4so3488934wib.3 for ; Mon, 06 Jan 2014 16:03:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=RP6vUsg0R6RPxXVYgi4jV+SNPMmhLYWQMQpQ8MUHupU=; b=BNPEa1WZlNROlLPoZGn8M88JzwR93maRXmCi1f3cErDuK2ZHYw3rqeLfETY0VxLTYm pVIT5CL8YQoDSN5my1XIF9HAc875jbiNBWshFMhYL9AkZt5u/H7bw2XNz90fKkv8/XlR WYs8zxA/sGqhHBf3230bRCGXZHDSKZTN3w/r5xa9DSKC3DiaUUM/RarySojA4QsC/lb5 VZ6XzLSb399/NQEy52+Ra/HsVZyxeRnpBFve4EzTyRDeOv157SV8UW8nCQMToRBimx2m wBrYIB61yorNtwALT5Jf8NeGeDIi9HEYVWLBTmQqL1gg9yupNHZPev6Bq4tepoUYUixR tr0w== X-Received: by 10.180.21.244 with SMTP id y20mr14674561wie.37.1389053013945; Mon, 06 Jan 2014 16:03:33 -0800 (PST) Original-Received: by 10.194.216.227 with HTTP; Mon, 6 Jan 2014 16:02:53 -0800 (PST) In-Reply-To: <87lhysu0t9.fsf@fencepost.gnu.org> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::230 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167549 Archived-At: --047d7b874d8278737e04ef561b02 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 7, 2014 at 12:50 AM, David Kastrup wrote: > Lennart Borgman writes: > > > On Mon, Jan 6, 2014 at 9:32 PM, Daniel Colascione > wrote: > > > >> On 01/06/2014 12:27 PM, Richard Stallman wrote: > >> > >>> Conceivably we could rename "window" to "pane" and "frame" to "window". > >>> I think the two renamings would have to be done in two different > releases, > >>> perhaps a year or two apart. > >>> > >> > >> I don't think we could pull off this renaming. At least on the lisp > level, > >> we would have to maintain compatibility aliases effectively forever, > >> doubling the number of lisp symbols dealing with these concepts. One > does > >> not simply rename a function that's been in constant use for 20 years. > >> Sure, you might argue, we could change the labels we assign these > concepts > >> in the UI and leave lisp alone, but the lisp symbols are too closely > tied > >> to the UI (with respect to keybindings and M-x) to change the two > >> independently. > >> > >> The best thing we can do is explain in the tutorial and manual the > >> correspondence between Emacs and common terms. > >> > > > > We are talking about the user level. Interactive function names can be > > duplicated. > > That's a bad idea since a fundamental part of the "interactive" user > interface is completion, so if you are trying to find some > functionality, getting two names in the set of completions that look > like they might do different things because of using different terms, > this will not help the user figuring out what to do. > > There are trade offs, but it is bad logic to say it is a bad idea just because of that of course. --047d7b874d8278737e04ef561b02 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jan 7, 2014 at 12:50 AM, David Kastrup <= dak@gnu.org> wrote:
Lenn= art Borgman <lennart.borgman@gmail.com> write= s:

> On Mon, Jan 6, 2014 at 9:32 PM, Daniel Colascione <dancol@danco= l.org> wrote:
>
>> On 01/06/2014 12:27 PM, Richard Stallman wrote:
>>
>>> Conceivably we could rename "window" to "pane&q= uot; and "frame" to "window".
>>> I think the two renamings would have to be done in two differe= nt releases,
>>> perhaps a year or two apart.
>>>
>>
>> I don't think we could pull off this renaming. At least on the= lisp level,
>> we would have to maintain compatibility aliases effectively foreve= r,
>> doubling the number of lisp symbols dealing with these concepts. O= ne does
>> not simply rename a function that's been in constant use for 2= 0 years.
>> Sure, you might argue, we could change the labels we assign these = concepts
>> in the UI and leave lisp alone, but the lisp symbols are too close= ly tied
>> to the UI (with respect to keybindings and M-x) to change the two<= br> >> independently.
>>
>> The best thing we can do is explain in the tutorial and manual the=
>> correspondence between Emacs and common terms.
>>
>
> We are talking about the user level. Interactive function names can be=
> duplicated.

That's a bad idea since a fundamental part of the "int= eractive" user
interface is completion, so if you are trying to find some
functionality, getting two names in the set of completions that look
like they might do different things because of using different terms,
this will not help the user figuring out what to do.

=C2=A0
There are trade offs, but it is bad logic to say it is = a bad idea just because of that of course.=C2=A0

--047d7b874d8278737e04ef561b02--