From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Wed, 13 May 2020 17:04:39 -0500 Message-ID: <87h7wjsd8o.fsf@red-bean.com> References: <5230692c-c665-a330-7a12-e59fa25d97dd@gmail.com> <70bb51fd-447d-928c-4d69-1c9673a44471@online.de> <871rnnvmdx.fsf@red-bean.com> <87pnb7sira.fsf@red-bean.com> <06bcddd4-6991-e4f7-e944-93de14af263d@yandex.ru> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="37723"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Andreas =?utf-8?Q?R=C3=B6hler?= , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 14 00:05:46 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jYzVa-0009iF-5D for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 00:05:46 +0200 Original-Received: from localhost ([::1]:40690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jYzVZ-0006IU-5x for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 18:05:45 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jYzUa-0005lU-1L for emacs-devel@gnu.org; Wed, 13 May 2020 18:04:44 -0400 Original-Received: from mail-oi1-x230.google.com ([2607:f8b0:4864:20::230]:42980) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jYzUY-0002AZ-U5 for emacs-devel@gnu.org; Wed, 13 May 2020 18:04:43 -0400 Original-Received: by mail-oi1-x230.google.com with SMTP id i13so22837298oie.9 for ; Wed, 13 May 2020 15:04:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:reply-to:date:in-reply-to :message-id:user-agent:mime-version; bh=noKlk/v75lxaWQbR4u5Wc6SBwGhHOIp1e8HPFNq2614=; b=Xlms79oWqeCyCilnXFNu/ehlJgucqCZepalSwG/O1FZly1x77oj/sqSy+PSfmN2bIg 1yIldO7rrxAa8mqeh0N4AywNUEARHHWLQXrIcIeqjCPQVSg4dnsrp+1hlRt5QjD7wyIZ zjxra7TJ3oAG8UF1qdwq9Bg0TlL1/f2uz3Ti+nzNWgQsOm7kGgrjnXvCjLGhbv8C588W 5LhYf+omQ9ccsHLSyZlPMj4l9pNtFOxTIj5oPtdza+RME8PZF8B3P3KhhOnPHWSnoc/Y Y2nBlTXJc3cLajJxHl6ZatwU32IKUkff/TstiVb64aYD2CRZPybRWx5UexJxOLVfrSsR yTFw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:reply-to :date:in-reply-to:message-id:user-agent:mime-version; bh=noKlk/v75lxaWQbR4u5Wc6SBwGhHOIp1e8HPFNq2614=; b=CzZe/UJMP5u7mvKlo4bXDPTv8hxmk00F3R9G3aTbsIL/AtkE6FEk2KgXt/5N5fui0b 3ZyutpW83jsnG1YcblGV4st0K44hjw7NtBgTSOSjZAeF9CpAqVgJQ+oGHSWPbXXsLmsw alpzxUa5YjHKHUoug/gPZcSrDglsBs7YUuUmMwDGCGwpqboXoHoPpOjrPSvdbdvspatN oNNo+41DOeJT0Zo5VLGFtJJwR2o0XVV+W6naNiJjQ1q+r7iUep32jYLcg/eDaSjXEBl3 aO2EOQ7sQtJLNeo4if2LmuW/vCWOk2vsaCeIau0MOZ1V5hCCcS1rcRNVhoN2RvjdSt9A vjJA== X-Gm-Message-State: AGi0PuaVGi6o9+VLfEBwrOF/Le24aOoIsbxF/tyWKolG4vKpcJJ2qcRW HnyIxBheDphH7j2vDlYhF0oA+iUb X-Google-Smtp-Source: APiQypJ8ACzMDiw66auqH/LOmNdaBGyI2cz4xDYlU6lU7e+Lp1OBlAPPJOJbmVpG1UVPxwEzn9ghpw== X-Received: by 2002:a05:6808:b0c:: with SMTP id s12mr28464640oij.163.1589407481348; Wed, 13 May 2020 15:04:41 -0700 (PDT) Original-Received: from floss (99-112-125-163.lightspeed.cicril.sbcglobal.net. [99.112.125.163]) by smtp.gmail.com with ESMTPSA id l196sm1239208oih.25.2020.05.13.15.04.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 15:04:40 -0700 (PDT) In-Reply-To: <06bcddd4-6991-e4f7-e944-93de14af263d@yandex.ru> (Dmitry Gutov's message of "Wed, 13 May 2020 23:52:56 +0300") Received-SPF: pass client-ip=2607:f8b0:4864:20::230; envelope-from=kfogel@gmail.com; helo=mail-oi1-x230.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001 autolearn=_AUTOLEARN X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:250166 Archived-At: On 13 May 2020, Dmitry Gutov wrote: >I might with agree with you principle, but both examples seem suspect. > >First, the "low investment" editors frequently have higher density of >information in the UI elements that correspond to our mode-line and >fringe, margins, etc. Largely thanks to their technical capabilities >(various-sized fonts, graphics, being able to fit different kinds of >indicators together on a "fringe"). So it appears at least in this >area Emacs has been overtaken purely on technical grounds. *nod*. There might be room for improvement in how Emacs uses various visual areas, though, having watched many different programmers using many different kinds of editors, I think Emacs's mode line actually scores pretty well on the indicator front (once one learns how to interpret it). But in any case, note that these other editors also face this same tradeoff. You can see it in Microsoft Word, for example: in recent versions, its default startup control panel looks like the cockpit of Boeing 747. Experienced users complain noisily about it (you can find various blog posts and other chatter about this on the Net), but this UI change was made so that *new* users could find a visual path to anything they might be looking for. The tradeoff will always be there, even if sometimes there is room for Emacs to improve -- i.e., room for Emacs to "get to the tradeoff point", so to speak. >Regarding the key combinations and the minibuffer, there is no hard >evidence that our current behavior is supremely optimal. In fact, I'm >fairly sure that by being risk-averse and resistant to change, and by >having no UX experts around, Emacs loses out on some possible >advancements in usability. Even expert-friendly ones. > >So I would recommend not becoming complacent, or becoming assured that >workflows you have spent some time getting accustomed to, can't be >improved. Absolutely. But the particular *way* in which we've crowded the keybinding space is independent of the fact that the space is crowded, and necessarily must be crowded if it is to offer experts the quick access to functionality that they want. Crowding the keybinding space is good for high-investment users and bad for newcomers (that's why newcomers to Emacs so often trip accidentally over unexpectedly combustible key sequences). That tradeoff will always be there, no matter what the particular mapping of key sequences to functionality is. So I think my example there holds up pretty well. >> I could go on. I've taught many newcomers to Emacs, and often the things that are hardest for them are exactly the things that are*good* for the experienced user. >> These design tradeoffs cannot be avoided. It would be a fallacy to >> think that it's always possible to be*both* maximally >> newcomer-friendly and investor-friendly. > >The last sentence is sensible, but it's generally beside the point: >I'm sure we still have a long way to go in both directions. Very good point: there are some things we could that would get us closer to the point where tradeoff decisions are necessary. But not everything we contemplate doing will be in that category. Some of the things we want to do will already *be* at the tradeoff point, and then we will have a decision to make. >> This also suggests that the sorts of features that highly-invested >> users tend to want -- for example, LSP-based features > >LSP is a high-investment feature? > >Reminder: it came to us from VS Code, Microsoft's text editor for >programmers. Not quite. What I wrote, exactly, is that it is the sort of feature that highly-invested users tend to want. That is different in a subtle way. By not supplying the sorts of things that LSP would enable, we signal to high-investment users that there is an entire area of improvement that Emacs is not going to explore. So while lack of LSP hurts both newcomers and experts, it discourages the experts more, because they are looking for signals that continued investment will lead to increased reward. Put another way: LSP is the sort of thing that enables highly-invested users -- the kinds of people who write or would consider writing Elisp -- to build new functionality into Emacs, perhaps even functionality we cannot predict today. While LSP is a good thing for all users, newcomers and experts alike, it specifically *rewards* further investment by users who are motivated to make (and capable of making) investments based on LSP's availability. It is an expertise amplifier. When we fail to include an expertise amplifier like that, we "bend the curve" -- in the wrong direction. Best regards, -Karl