From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: GNU Emacs raison d'etre Date: Thu, 14 May 2020 01:55:37 +0300 Message-ID: <20897f01-122d-7f91-eac2-70f5ad75796f@yandex.ru> 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> <87h7wjsd8o.fsf@red-bean.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="120935"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 Cc: =?UTF-8?Q?Andreas_R=c3=b6hler?= , emacs-devel@gnu.org To: Karl Fogel Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 14 00:56:20 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 1jZ0IW-000VNP-52 for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 00:56:20 +0200 Original-Received: from localhost ([::1]:37268 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZ0IV-0003XY-7n for ged-emacs-devel@m.gmane-mx.org; Wed, 13 May 2020 18:56:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45164) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZ0Hv-00037W-SU for emacs-devel@gnu.org; Wed, 13 May 2020 18:55:43 -0400 Original-Received: from mail-wr1-x441.google.com ([2a00:1450:4864:20::441]:36428) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZ0Hu-0006xi-Iq for emacs-devel@gnu.org; Wed, 13 May 2020 18:55:43 -0400 Original-Received: by mail-wr1-x441.google.com with SMTP id y16so1510429wrs.3 for ; Wed, 13 May 2020 15:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fyht11I5mbcWzYGjnaJxTkeftnn+CWK81RuLcJ+kdkg=; b=CnLO9cbXog6flhnGx6RHypQ1WRlbVQB2dnr/ITzgfmTXfm0rz8MK3FX7IaGdIugiaD 0NO5L4XSjISckHq9r3YcS5+pvJ7SuZStWEvwrh2syR4ubXI8x+5uWHfRV/4H3Og7yZHX k1PxqR0qbux1xyXG0e2LvRNvxgXb0CDZBi92RCSWkk6W+4mPkDDMKIY5tpavtE9kys7R ahsUz1orSbN5IgIWeQgXDSes87BScTAgxoAb7uIX5GIlQ6wUJIzb5fHQll/OIzJT41c+ jJ1qCizFnKHxnitrxnoOaYKhxVsAPHs889gwpGKjMT+g4xu0eeRwS+N1JclaOqxQIcjp darg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fyht11I5mbcWzYGjnaJxTkeftnn+CWK81RuLcJ+kdkg=; b=fH4GUBo5Q94K8fJoJbR5OI38ioi31L7mIwQSgGOSwa5tOvKfy3mh5PKNI8D8dxdnHj tzrJ79uoEF+GbBqAoDi3FRHixyN82jMOPnt2KB/aUKMEw/Qyao30des3yAXMdKUVDrjO 7d8GHRcu4gfNVcb6qcRJ0mp2FyNNO4Qn5HFMSnagruO6btrv2/cqunSRX2zzH6h3/N5R wb+TvThKMASjBjRW/GypZacpAtKT4GH2zyCJUqForwQCRsqEDlch9eNPKzzp6mr8TOQc enkQKw2dXq83PqhU9KCq4dtoT/nc14+UXHfA6PEaB9WkEi9Z5yGwtOzRFIfujJCFzN02 jt6Q== X-Gm-Message-State: AOAM532hVqr3T+geDdFZ31J6uSodl1/O82iauhi/XSsMySDupIbv2DJP PH1zTDs9/2RZjNjpgEoY0Kf7gq84 X-Google-Smtp-Source: ABdhPJxfqNxGPwJaVAxkbNmDXbGa8qhUCwXdnHKcKNCbwgz1HFnkV4ADoawjbU7Pj0rNdGNgUr3QbA== X-Received: by 2002:adf:8403:: with SMTP id 3mr1725364wrf.186.1589410540548; Wed, 13 May 2020 15:55:40 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id d9sm13747270wmd.10.2020.05.13.15.55.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 13 May 2020 15:55:39 -0700 (PDT) In-Reply-To: <87h7wjsd8o.fsf@red-bean.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::441; envelope-from=raaahh@gmail.com; helo=mail-wr1-x441.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:250170 Archived-At: On 14.05.2020 01:04, Karl Fogel wrote: > 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). I think the mode-line is more or less average by today's standards. But of course it wins on customizability. The fringes a significantly less functional, though. :-( > 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. Yes, the tradeoff is somewhere in there, but my problem with the conclusion is that it would be really easy to misapply your principle (e.g. by saying we don't need fancier buttons, even though we probably do, or that the Getting Started guide is good enough and doesn't need improvement, and someone should go work on specialized Org-mode docs instead). Making good use of it seems difficult. The kind of person who *could* make a better judgment in this area is someone who specializes on UX. And they are rare guests around here. > 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. Are you sure that this particular aspect is _bad_ for new users, though? Nobody likes to stretch they hand too far. But I'll grant you this point, that Emacs is *somewhat* on the side of high-investment here. This part is expected of a professional tool, however, and the experience for newcomers could be improved without taking away much from the "oldies". See the 'transient' package, for example, recently proposed for inclusion on emacs-devel. >>> 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. Some of them, probably. At this point, I think, there are still a lot of decisions that would bring us closer to newcomer-friendliness while keeping no worse high-investment compatibility. >>> 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. I'm glad that we both like LSP, or at least the idea of it. But it seems these days almost everybody wants it, except for MS Word and Notepad users. > 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. There are certain aspects where LSP is not exactly perfect: the functionality it allows is limited by the protocol, and by LSP servers available currently. It's an "ecosystem amplifier", or maybe an equalizer even. I mean, it for sure is great, not to be lagging in language support for a whole number of languages where we did before. But there are different protocols that allow more powerful extensibility. nREPL, for example.