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 12:00:54 +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> 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="33521"; 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 14:02:05 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 1kH4EH-0008cp-3E for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Sep 2020 14:02:05 +0200 Original-Received: from localhost ([::1]:39614 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kH4EG-0001P5-6A for ged-emacs-devel@m.gmane-mx.org; Sat, 12 Sep 2020 08:02:04 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57934) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kH4DM-0000xn-Im for emacs-devel@gnu.org; Sat, 12 Sep 2020 08:01:08 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:61204) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kH4DI-0003FG-B7; Sat, 12 Sep 2020 08:01:08 -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 08CC0v5U010306 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Sat, 12 Sep 2020 12:00:57 GMT Original-Received: (from ghe@localhost) by sdf.org (8.15.2/8.12.8/Submit) id 08CC17WF016749; Sat, 12 Sep 2020 12:01:07 GMT In-Reply-To: <838sdfdzxo.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:255313 Archived-At: >>> The snippet will only be able to show the buffer text appearance. >>> For other UI elements you will need an image. Would using an image be >>> better here? >> >> What do you mean by "other UI elements"? > > The mode line, the scroll bars, the menu and the tool bar. > 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 would be nice to have a way to select a default font here, but I >>>> don't know if that feasible.] >>> >>> I don't think I understand what you mean by that. Selection of the >>> default font _is_ possible, we have in the Options menu. >> >> Yes, but what I meant is to have a list of font names in the buffer, >> and choosing a font by clicking on the font name. > > 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. But if that's too complex to do, this part should be skipped. >>>> 2. disable tool-bar-mode >>>> 3. disable scroll-bar-mode >>> >>> I'd object to these two. We have just established that the former is >>> important for newbies. Scroll bars are presented by many >>> applications, so why is it important to offer to turn them off here? >>> let the users decide about these two. >> >> It's just an option. In the video by Yuan Fu ( >> https://youtu.be/0qMskTAR2aw ) you'll see that this screen is a list of >> checkboxes that the user can tick. > > My point is that we should not put there unimportant options, let alone > those which we recommend not to change from the defaults. > 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". 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. Note that I did not (on purpose) include menu-bar-mode here. > > There are thousands of options in Emacs that users might want to enable. > This initial guide should only show those which are very important, > recommended, and usually expected. Options that don't satisfy these > criteria should IMO not be in the list, because the list must not be too > long, or you will lose many newbies who don't have enough patience. > See above. I agree with "usually expected", but "very important" or "recommended" is from my point of view too difficult to judge. >>>> 11. (setq uniquify-buffer-name-style 'forward >>>> uniquify-min-dir-content 1024) >>> >>> Why? what's wrong with the defaults here? >>> >> >> This has been discussed earlier in another thread, but the current >> defaults (uniquify-buffer-name-style set to >> post-forward-angle-brackets) is puzzling to most users, to say the >> least. A complete file name is what most users would expect here. > > A complete file name takes too much of the screen space on the mode > line, IMO. You'd need to make the font used by the mode-line face to be > much smaller, and even then it will steal too much space. > That's your point of view, and I agree with you to some extent. OTOH there are not so many available options, and clearly the current default (only the filename) is not what users coming from another editor would expect. > >> I use icomplete-mode myself, and don't understand what you mean by >> "complex and potentially confusing UI". > > Type "C-x C-f" and try to look at the result with the newbies' eyes. > First question I have is "how to go on?" arrow doesn't work. If > the font shows the bold letters distinct enough, I'd wonder what do the > bold letters mean. The order in which the files are shown doesn't > necessarily make sense, nor does the fact that it mixes directories with > files. Etc. etc. -- the stuff I'd wonder about goes on and on. This is > not the completion I find, e.g., in a Web browser, so prior experience > will not help. > I agree with you that with newbies' eyes icomplete could be at first sight a bit surprising. But after typing a user would likely try to type something (the cursor is there and blinking) and would quickly understand how it works (I think). If there was a built-in vertical mode it would be better / more intuitive. >>>> SCREEN 6: How to find help. Short explanation about C-h C-h, C-h m, >>>> C-h p, C-h k / C-h w / C-h a, C-h l. >>> >>> This misses important help commands, we should consider the list >>> carefully with newbies in mind. IMO, the various apropos commands are >>> much more important for them than other help commands. >> >> Well, C-h C-h gives the complete list, and C-h a starts apropos. > > There are several apropos commands, and they are all very important for > discoverability. > It's one of the reasons I think offering the user the option to enable icomplete makes sense: it helps them to discover options and commands. For example M-x apropos lists the individual apropos commands. 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?