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, 20 May 2020 17:00:14 -0500 Message-ID: <87y2pmw9ld.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> <87d077qfmm.fsf@red-bean.com> 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="59198"; 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 21 00:01:09 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 1jbWlx-000FJM-Ed for ged-emacs-devel@m.gmane-mx.org; Thu, 21 May 2020 00:01:09 +0200 Original-Received: from localhost ([::1]:54252 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jbWlw-0004ZX-Fd for ged-emacs-devel@m.gmane-mx.org; Wed, 20 May 2020 18:01:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:53064) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbWl8-00042M-Q4 for emacs-devel@gnu.org; Wed, 20 May 2020 18:00:18 -0400 Original-Received: from newsp.red-bean.com ([45.79.25.59]:48684) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jbWl7-0005Sw-6U for emacs-devel@gnu.org; Wed, 20 May 2020 18:00:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=red-bean.com; s=202005newsp; h=Content-Type:MIME-Version:Message-ID: In-Reply-To:Date:Reply-To:References:Subject:Cc:To:From:Sender: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vh7kcyyVGOrARcWacj1wRP+/rETEko2WlS/uIB6XPpM=; t=1590012016; x=1591221616; b=l0ZrBucaCeBw3UT4P/IWkEe2hRkOHakFz87DVOLeEHXDbWWpyL74qp9axmSNV0fO5eGjeLc0F0 5+fTSDbcXBuPg03nzYEN269XvQ4w5pZG8T5mZjceNjHqB3WPecusIfkqRvzflhVt7zeFVvBxK8PL9 1w1k+Fz1xW9IeRY0t29rR8u6AV/DoXXoMImex0qyoNWxO0xqyF7EwbHIzqGxWpAy4tp2IHol6ilc5 xYSwLufAwWxsigS1LzzaORq2yAo1seJPNSLDmukthHjhXjrfdYUmyQumH7PX+cR+3Zn453T3z6gl3 JRDp3uQYLSLulBQKN2G6+J10as1ETTelPQfzw==; Original-Received: from 99-112-125-163.lightspeed.cicril.sbcglobal.net ([99.112.125.163]:59424 helo=floss) by newsp.red-bean.com with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jbWl5-0002JE-8E; Wed, 20 May 2020 22:00:15 +0000 In-Reply-To: (Dmitry Gutov's message of "Sun, 17 May 2020 04:28:52 +0300") Received-SPF: pass client-ip=45.79.25.59; envelope-from=kfogel@red-bean.com; helo=newsp.red-bean.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/05/20 17:36:56 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_PASS=-0.001, 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:251123 Archived-At: On 17 May 2020, Dmitry Gutov wrote: >>> 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 keep track, but the sample size is large enough to be beyond >> merely anecdotal at this point. I've watched newcomers run into the >> same obstacles over and over, and this particular obstacle is always >> one of the first they encounter. > >Okay, but is it still a problem after they've tried Emacs for a day, >for instance? For a week? > >These periods of time would of course suggest Emacs is not ideal for >total newbies, but they're not the kind of "sustained investment" you >described either. The nature and variety of a newcomer's problems with Emacs depends a lot on how much coaching the newcomer is getting from someone with more experience. But even with good coaching, it takes a long time for Emacs to become "worth it", by which I mean "better for that user than the J. Random Popular Text Editor they might have gone with instead". >>> 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 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 understand 'transient' from reading [2] and [3], but >> unfortunately -- and somewhat surprisingly! -- the documentation at >> those pages does not give a single concrete example of transient's >> use.) > >You press 'C-x', wait a while - and it pops up a window with the >descriptions of all commands whose bindings start with 'C-x'. Same for >all other "incomplete" key sequences. Looks pretty handy for beginners. Thanks for the explanation. I haven't used it myself nor seen anyone else use it, so I don't feel confident in saying one way or the other whether it would help beginners. Next time I'm teaching someone, maybe I should try it, though. >> However, your assertion that "the experience for newcomers could be >> improved without taking away much from the 'oldies'" is exactly what >> I'm arguing is 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 stumbling 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 of 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 the >> built-in help there too. But it's a difference in prioritization: >> for Emacs 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 different too. So we should incorporate that >> fact into how we present Emacs to new users. > >Yes, ok. Maybe this one is harder to improve that some others. Thanks -- glad that helped. >>> 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. >> That could be true, though I'm a bit more skeptical than you are. >> In any case, 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. > >It's not like extreme user-friendliness was ever a guiding principle >here. :-) In another message I sent a moment ago, I replied to the above (via someone else who was quoting you), so I'll repeat that part of my response here: > While "friendly to newcomers" means something on its own, > "user-friendliness" only means something after one has characterized > the users in question. That's the main point I've been trying to > make: that there is no such thing as a generic user, so we have to > make decisions about which kinds of users to optimize for. > > In most UI/UX conversations (not necessarily here, but on the Net in > general), most of the time people unconsciously say "user-friendly" > as a synonym for "easy for newcomers to pick up quickly" -- without > realizing that it also implies "tends not to reward sustained > investment", since these two qualities inevitably trade off. > > So if we characterize our users as "those who see, or who have the > potential to see, the value of making a sustained investment in > their text manipulation environment", *then* yes, by all means Emacs > should be user-friendly. But if we're saying "user-friendly" in the > colloquial sense that most people use the term in, then no, I think > it would be a mistake for Emacs to aim for that. I wish that the first thing they would teach in UX school is to stop using the term "user-friendly" :-), much as medical professionals are (I'm told) taught to stop saying "throw it away" because there's no such thing as "away" in a hospital -- each kind of medical waste needs to be disposed of by a specific & suitable method. >In this we're, again, similar to other professional software. Well, I'm not sure exactly what "professional software" means in this context, but if it means "expects the user to make sustained investment", then I agree. Best regards, -Karl