Re: Interactive guide for new users

[Gregory Heytings via "Emacs development discussions." <emacs-devel@gnu.org>]

>>> 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?"  <RIGHT> 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 <right> 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?