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: Sun, 17 May 2020 04:28:52 +0300 Message-ID: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="122351"; 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 Sun May 17 03:29:31 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 1ja87N-000Vja-Pj for ged-emacs-devel@m.gmane-mx.org; Sun, 17 May 2020 03:29:29 +0200 Original-Received: from localhost ([::1]:47860 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1ja87M-0006wu-Qy for ged-emacs-devel@m.gmane-mx.org; Sat, 16 May 2020 21:29:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:60654) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1ja86s-0006Sj-IK for emacs-devel@gnu.org; Sat, 16 May 2020 21:28:58 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:34785) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1ja86r-00067N-D7 for emacs-devel@gnu.org; Sat, 16 May 2020 21:28:58 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id y3so7739319wrt.1 for ; Sat, 16 May 2020 18:28:56 -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=4sluP3xSN4b+d5Oe3Pkdogde8StRn5KIQg0SnattNho=; b=bc3h7ieDoctJx2xJV5BfPoPXoolYhY1I/BwJ6fMGrJuic07zql5ReZNnrq/B9F3wEC +BiW1MRDHuroclAd7OgPaMJDzzYdv3nEE9w/biDqw3hOrwHsBaeOb7rZFUXdSxLvhF2j rGLGuUUYlTQyzWAwcDUSFwY3fbWivERnSw1NbiV+sWM9OVNky4IJJb7sQE4CmAj3TGu6 HpSP8DZjoQnDCWqKHmCRS/1GPO3kyuo7qH9OuAikIbCcTneYdyVZVFtnRIXD9G/Dheds bk425qiItRI3Wqo1vzPig38PXLPc+bOzZOnk5gl64F574EAuWXx+QNyNQNRBQXaIMWdR 7caw== 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=4sluP3xSN4b+d5Oe3Pkdogde8StRn5KIQg0SnattNho=; b=PU3UUknHE0XC7PPtWbA0WiLZza7bavOw1aPN6FptPO+op6z7ZOdFB8EJtJ3bfIHF1d VG96BQkie63OHWEI2pePjOE8eBQ/7VrwmLLAxjW+q8vQcLu0RWkolzCLC6OtMnOjxOPu uXMnnOzMXfLeo7KhHM5N9cwK/5xUPPI2bvMZ1rvfVyJ0yOfOqcLDZnDcXThcQENNB82S P92ZdZvi8YmiG8kAmIxphpGLv/5Nbn37C2kk11wcYblKLINCa5A3Ncq2zEbjUTDS7ZhC qOWvathIfTWxfViNDeva1QVIsxN49HHIteXmGotMHUFaMH9oOaV1Jvca845V99Kp56KL zY8Q== X-Gm-Message-State: AOAM533K4NEGkvqSvCxcgOO+Ow3t0YYpQmX94eenrOoS0WjYdzBp2fBW wwbV5sgqJLbcEX24i9h4HDTz2Yux X-Google-Smtp-Source: ABdhPJyGLsWDIBAF6Mp8LzRb7nk4HIPb6V2zHlurRfNIc9t0yj5W539KTJoKyGYS4Sqf26rVaRLHug== X-Received: by 2002:a5d:4d81:: with SMTP id b1mr12862674wru.55.1589678935167; Sat, 16 May 2020 18:28:55 -0700 (PDT) Original-Received: from [192.168.0.3] ([66.205.73.129]) by smtp.googlemail.com with ESMTPSA id 81sm10985412wme.16.2020.05.16.18.28.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 16 May 2020 18:28:54 -0700 (PDT) In-Reply-To: <87d077qfmm.fsf@red-bean.com> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.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:250538 Archived-At: On 14.05.2020 07:56, Karl Fogel wrote: > 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. Actually, those examples are closer to the discussions I have taken part in (let's not change xxx because existing users will complain; and the newbies will just have to get in line, the entry barrier is high anyway, who cares if they have to learn one more thing to get started). On the flip side, I don't remember anybody propose to make key bindings less "staggered". > In a reply to Christopher Lemmer Webber just now [1], I got a little bit more 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. I think we already do (the rest flocks to #1, #2 and #4 popular options). No need to try harder in that direction. > 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 videos, etc): > > * Tell newcomers up front that Emacs really starts to be worth it after a few years, not a few weeks. Set expectations right from the start. That feels like giving up. And "worth it" depends on personal expectations. From reading comments on Reddit, converts from Vim, for instance, try Spacemacs or Doom Emacs, and seemingly become satisfied in a matter of days. > * Show them some of the abilities they will eventually have, so that they can see why it's worth it to make the investment. Not sure what you have in mind here. If it's a "here's not an Emacs would solve a problem", this could turn into a useful tutorial for journeyman emacsers. > * 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 inevitably entangled with the same things that make Emacs winning in the long term. Not a bad advice, but deciding on such a list in official documentation might not be easy (people have opinions). Once we do decide, it would be better to try to improve these things first. > Ultimately, I personally find it helpful in thinking about how to teach Emacs and how to write packages. Here is the principle, reworded slightly after a suggestion from H. Dieter Wilhelm: > > "GNU Emacs's raison d'être is to be the text manipulation environment that best rewards sustained user investment." I still don't like it. It either means "you don't get much until you struggle for a while" (which just sounds discouraging) and/or "no other program comes even close at text manipulation", which is... pretty conceited and kind of limited at the same time. I mean, Emacs is great and all, but I don't have "text manipulation" as the #1 goal in my life. Or even among top 10 goals. The higher-level things one can implement with Emacs Lisp are a lot more interesting. >> 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. >> 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. > 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 i nto how we present Emacs to new users. Yes, ok. Maybe this one is harder to improve that some others. >> 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 this we're, again, similar to other professional software.