From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Gregory Heytings via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Interactive guide for new users Date: Sat, 12 Sep 2020 13:56:11 +0000 Message-ID: References: <875z8ortot.fsf@gkayaalp.com> <83lfhjkq0r.fsf@gnu.org> <8620B5CD-CA92-46BF-80A8-DBE7052F4CA6@gmail.com> <83d02re2uk.fsf@gnu.org> <838sdfdzxo.fsf@gnu.org> <834ko3dw3e.fsf@gnu.org> Reply-To: Gregory Heytings Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=US-ASCII Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34808"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Alpine 2.22 (NEB 394 2020-01-19) Cc: casouri@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 12 15:57:15 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 1kH61j-0008xd-GV for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Sep 2020 15:57:15 +0200 Original-Received: from localhost ([::1]:54068 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kH61i-0000j8-Ib for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Sep 2020 09:57:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55808) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kH60t-0008FZ-0i for emacs-devel@gnu.org; Sat, 12 Sep 2020 09:56:23 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:52626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kH60q-0000zu-J5; Sat, 12 Sep 2020 09:56:22 -0400 Original-Received: from sdf.org (IDENT:ghe@faeroes.freeshell.org [205.166.94.9]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 08CDuE5n016232 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 12 Sep 2020 13:56:14 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08CDuQF7013727; Sat, 12 Sep 2020 13:56:26 GMT In-Reply-To: <834ko3dw3e.fsf@gnu.org> Received-SPF: pass client-ip=205.166.94.24; envelope-from=ghe@sdf.org; helo=mx.sdf.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/12 05:31:13 X-ACL-Warn: Detected OS = ??? X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no 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:255347 Archived-At: >> The effect on the mode line is show on the fly, see the video Yuan Fu >> made. For the scroll bars, the menu and the tool bar, I don't know if >> it is possible to change their appearance within Emacs. Is it >> possible? > > It depends. My point, though, is that when one needs to choose from a > large number of themes, showing how Emacs will look under a theme makes > the selection process easier. So an image sounds like a good way of > showing the effect without requiring any action on the user. Images also > make it simpler comparing the effects of several themes. > Okay, if that's feasible in a clean way that would of course be fine. One potential problem I see is that the font in the picture will likely not match the font on the system, but that's perhaps not very important. Note that I would not recommend to have a "large number of themes" here, I'd say that 20 should be an upper bound. I would separate them in two: "light mode" ones and "dark mode" ones. >>> Why? The Options menu item I've mentioned pops up the system's font >>> selection dialog, which is way nicer than selecting a font from an >>> Emacs buffer. To say nothing of being less work. What am I missing? >> >> You're not missing anything. It's just convenience for new users, >> telling them to go there and there to do this and that is more >> confusing than offering them a limited number of options during the >> guided tour. > > You don't need to tell the user do anything, you can pop up the font > selection dialog programmatically. > Again if that's feasible that would of course be fine. I did not check this in detail, I don't use any of these features myself. >> I think the criterion here is not whether an option is from our point >> of view important or unimportant, or whether we recommend or not to >> change its default value, but whether a user coming from another >> editing environment is likely to want it to feel "at home". > > Yes. But that wasn't my point. My point was that you said "it's just > an option", and I said that we should think hard about which options we > show there and which we don't. "Important" for the users we have in > mind, sure; but are you saying they expect these UI elements to be > removed? And if they do, could it be because they don't realize how > useful they can be? > FWIW, yes, I do think they expect to have these UI elements to be removed. They want a "minimal slick UI". Not everyone would tick that option of course, but having it there makes sense IMO. I don't know "how useful they can be", because I don't use them myself, for example I never found scroll bars useful in any app, and certainly not in Emacs. The tool bar could be useful, but if you look at the current toolbar from the viewpoint of a newbie it is not. Let's suppose I'm a newbie: first you have two buttons to read a file (which one should I use? let's try C-o!), then an button to launch dired (likely not something a newbie would want to do), then a button which says "Discard (kill) current buffer" (what the heck does that mean?), then "Save" (okay, that should be C-s, so I don't need that button), "Undo" (should be C-z... hey, but where is "Redo"?), "Cut" (should be C-x), "Copy" (should be C-c), "Paste" (should be C-v), "Search" (should be C-f). Oh, is that all? What's the purpose of that toolbar? (If you look at other apps they do have these things in a toolbar, but it's because the toolbar has much more buttons.) >> If Doom Emacs, Spacemacs and the like disable the tool bar and the >> scroll bar, that's an indication that it's something new users might >> want. > > We don't need to be bug-for-bug compatible with Spacemacs and DOOM. > Where we think they make a mistake, we should do better. > The discussion here is not whether something is a mistake or not, but what new users coming from another editor would likely want to see to have a positive feeling when they open Emacs. As long as it does not remove an essential feature, that's fine IMO. >> That being said, I agree with you that perhaps at this point some of >> the apropos commands could be mentioned (but not all of them). >> Perhaps apropos, apropos-command, apropos-variable, apropos-function? > > apropos-documentation is also very important. > Okay.