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 23:56:01 -0500 Message-ID: <87d077qfmm.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> <87h7wjsd8o.fsf@red-bean.com> <20897f01-122d-7f91-eac2-70f5ad75796f@yandex.ru> Reply-To: Karl Fogel Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="19925"; 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 07:01:36 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 1jZ5zz-00054u-6p for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 07:01:35 +0200 Original-Received: from localhost ([::1]:57430 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jZ5zy-0001zN-9S for ged-emacs-devel@m.gmane-mx.org; Thu, 14 May 2020 01:01:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57508) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jZ5uh-00025d-G0 for emacs-devel@gnu.org; Thu, 14 May 2020 00:56:07 -0400 Original-Received: from mail-oi1-x236.google.com ([2607:f8b0:4864:20::236]:35537) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1jZ5uf-0005Hx-Du for emacs-devel@gnu.org; Thu, 14 May 2020 00:56:06 -0400 Original-Received: by mail-oi1-x236.google.com with SMTP id o7so23542186oif.2 for ; Wed, 13 May 2020 21:56:04 -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:content-transfer-encoding; bh=Tw/1clbR90Fy21F/SQepsYdOEYGSXXcAymEGAsJUsko=; b=fRZKAP/k0h/2C2gHPHwQwc+lNU9PZMAUZ2xRTSnRi6iZz7/8FXUBwInYGnpYfI6wGg W4q/OK/7M1lOSElDoVcN5/psGE80thukbkx/qT5Lj5/z8oZS44yO6Dsp2BwF50WX2sPe zUP3/oTNl3843NR4RQjjlNER7CZaINqoozPOMoaYXwCZr5K0xgok1JY5/IUU7PNxS7sk mJeXogrMqNNglsugi0m/UJwy3cWyWynhhKuEIALvZdSd1vYmjNVAhLA4BSwGte6x9l0F f0JfJBIOri7/1yivTy5EGwz3CXMZVhVkgKMZET57FmcqhNwjqgJzY2QQzz1FNLNM9nhW V8Sw== 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 :content-transfer-encoding; bh=Tw/1clbR90Fy21F/SQepsYdOEYGSXXcAymEGAsJUsko=; b=r1c2bX4eOFi4H5vU3VZH/b0QDZPfnZEBVEO8x6YoKzSBk4MhMmrcrwESetZoXT09KQ G0VEmaGalqe08Q/+6J9xA3TxlRNHBdYAfZQvG1eFQGSPsZs8Jk8uXbSxebjXa7SUbaDT PjpaePB2jgAyCLXg9KsgEC5wmioIOK129qI8EhdlGZX+Kwr7Wfqjz6+7p3rJGLfwk1Ra Ufvi72L4shyJLCXhBGPrQXAKv0+OzOaxSiVc03SDDjL/9T4/oGdZ8c4rm1lBxUFhcYoi 5GlEY0lxlooep5JmhkD7rntGZPFJPMJM+po1fXRpQd45pWi//AHcQuBmnEJqdWM8oz5T 5XKw== X-Gm-Message-State: AGi0Pua6duY1L86st/0483yD8t+bmvp+oA0Uo/oemsttKZf8MXxzavsb RQdF4EPCNhajbMf3Mwx8QVyFxGP3 X-Google-Smtp-Source: APiQypKOU+sfxKTUcuydU7ku47n3sNBSRD7GdzBu3srgcjB1NWU45dUytYFv4BbI/7lbx9jWKUW29A== X-Received: by 2002:a54:4585:: with SMTP id z5mr30802977oib.89.1589432163195; Wed, 13 May 2020 21:56:03 -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 o17sm107098otp.79.2020.05.13.21.56.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 May 2020 21:56:01 -0700 (PDT) In-Reply-To: <20897f01-122d-7f91-eac2-70f5ad75796f@yandex.ru> (Dmitry Gutov's message of "Thu, 14 May 2020 01:55:37 +0300") Received-SPF: pass client-ip=2607:f8b0:4864:20::236; envelope-from=kfogel@gmail.com; helo=mail-oi1-x236.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: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 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, URIBL_BLOCKED=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:250188 Archived-At: On 14 May 2020, Dmitry Gutov wrote: >Yes, the tradeoff is somewhere in there, but my problem with the >conclusion is that it would be really easy to misapply your principle=20 >(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=20 >improvement, and someone should go work on specialized Org-mode docs >instead). > >Making good use of it seems difficult. Any guiding principle can be misused, but that doesn't make it useless. The particular misuses you cite above are speculative -- no one's actually = saying those things, as far as I'm aware. In a reply to Christopher Lemmer Webber just now [1], I got a little bit mo= re specific: > If we just say "Emacs should be easier for newcomers to learn", > that's not a useful rallying cry IMHO. If we say instead "Emacs > should try to attract newcomers who have a higher-than-average > probability of becoming high-investment users, and should explain > early on to those newcomers what the road ahead looks like", *then* > we have a high-level guiding principle we can actually use. So there's some concrete guidance about *how* we might seek to improve the = Getting Started guide (and other things like the Emacs web site, starter vi= deos, etc): * Tell newcomers up front that Emacs really starts to be worth it after a f= ew years, not a few weeks. Set expectations right from the start. * Show them some of the abilities they will eventually have, so that they c= an see why it's worth it to make the investment. * Also tell them about the ways in which Emacs may frustrate them along the= way, and explain that those frustrations are common and are sometimes inev= itably entangled with the same things that make Emacs winning in the long t= erm. I find it fairly easy to come up with ways in which this principle would pr= ovide guidance in certain decisions. I could try to list more of those way= s, if it would be helpful, but I just don't want to get into a sub-discussi= on about each such example. It's meant to be a high-level principle, after= all. Ultimately, I personally find it helpful in thinking about how to teach Ema= cs and how to write packages. Here is the principle, reworded slightly aft= er a suggestion from H. Dieter Wilhelm: "GNU Emacs's raison d'=C3=AAtre is to be the text manipulation environment = that best rewards sustained user investment." Apparently some other people here find it useful as well. You might or mi= ght not be one of them, but I can at least promise you that I'll never use = this principle to make bad suggestions about ways in which Emacs should be = made unfriendly to newcomers :-). >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. More UX expertise would always help, naturally, but those of us who are her= e are not wholly ignorant of the field either, nor of the questions and tra= deoffs that need to be dealt with. >Are you sure that this particular aspect is _bad_ for new users, though? Yes. I am sure. I've taught Emacs to a lot of people -- scores of them, at least; I don't k= eep track, but the sample size is large enough to be beyond merely anecdota= l at this point. I've watched newcomers run into the same obstacles over a= nd over, and this particular obstacle is always one of the first they encou= nter. >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=20 >proposed for inclusion on emacs-devel. I don't have any experience using 'transient', so I'd need more explanation= from you to understand what you meant by that part. (I tried to understan= d 'transient' from reading [2] and [3], but unfortunately -- and somewhat s= urprisingly! -- the documentation at those pages does not give a single con= crete example of transient's use.) However, your assertion that "the experience for newcomers could be improve= d without taking away much from the 'oldies'" is exactly what I'm arguing i= s not true. I actually think we can't (much) improve this particular part = of the experience for newcomers without taking away one of the things about= Emacs that most rewards investment. The newcomers who eventually *do* become experts do so in part by first stu= mbling across new commands accidentally (in that crowded keybinding space) = and then using help tools like `C-h l' to see what they just did. So one o= f the things we should prioritize is teaching newcomers how important those= help facilities are and how to use them in a smart way. I'm specifically = saying that this is *more important for Emacs than it is for other editors*= . Sure, users of (say) the Atom editor should eventually know how to use t= he built-in help there too. But it's a difference in prioritization: for E= macs users, using that built-in help is more important than it would be in = other editors, and the methods and circumstances of using the help are diff= erent too. So we should incorporate that fact into how we present Emacs to= new users. (Again, this is from at least some experience. The users I've taught who h= ave gone on to become proficient Emacs users are ones who invested very ear= ly in learning the various help facilities and when to use them.) >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=20 >keeping no worse high-investment compatibility. That could be true, though I'm a bit more skeptical than you are. In any c= ase, it does not make the principle inoperative; it is consistent with the = principle. I believe we'll make better decisions if we keep in mind that "friendly to = newcomers" is not, in itself, the primary goal. >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. Yes. High-investment users, however, see more possibilities from LSP than = low-investment users do -- they'll go farther with it. >There are certain aspects where LSP is not exactly perfect: the >functionality it allows is limited by the protocol, and by LSP servers=20 >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. Ah, that's a technical question about the suitability of LSP for a particul= ar problem space, and I'm not well-informed enough to have a useful opinion= there. If you say nREPL, I'm not going to argue! :-) Best regards, -Karl [1] https://lists.gnu.org/archive/html/emacs-devel/2020-05/msg01893.html From: Karl Fogel To: Christopher Lemmer Webber Cc: ndame , Emacs developers Subject: Re: What is the most useful potential feature which Emacs lack= s? Date: Wed, 13 May 2020 23:08:04 -0500 Message-ID: <87y2pvqhuj.fsf@red-bean.com> [2] https://github.com/magit/transient/blob/master/lisp/transient.el [3] https://emacsair.me/2019/02/14/transient-0.1/