Re: Interactive guide for new users

[Gregory Heytings]

> > 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.