Re: Interactive guide for new users

[Ergus]

On Sat, Sep 12, 2020 at 01:58:27PM +0300, Eli Zaretskii wrote:
> > Date: Sat, 12 Sep 2020 10:35:06 +0000
> > From: Gregory Heytings <ghe@sdf.org>
> > cc: casouri@gmail.com, emacs-devel@gnu.org
> >
> > >> SCREEN 2: "Set the color theme", with a clickable list containing the
> > >> (currently) 16 built-in themes.  A short code snippet above that list
> > >> illustrates how code is displayed with each of these themes.
> > >
> > > 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.
>
> > >> [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?
>
> > >> 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.
We could add and extra optional SCREEN with advanced options. The user
can click next if done with the options in this page or advanced and go
for a more detailed and longer list of options.

Like a "SCREEN 2.1" to add many "unimportant" things with more
freedom. For example we can add here to enable show-trailing-whitespace,
fill-column-indicator, auto-revert-mode, visual-line-mode, ispell
dictionaries, desktop-save-mode.

All those are options not desirable in the SCREEN2, but could make sense
for users with some editing experience but not emacs experience.

WDYT?

> > >> 10. save-place-mode and desktop-save-mode
> > >
> > > desktop-save-mode slows down startup, so it might not be suitable for
> > > users who start Emacs many times a day.
> > >
> >
> > Again it's just an option, but again it's someting that users might want
> > to enable because it's a behavior that is common in text editors.
>
> 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.
>
> > >> 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.
>
> > >> 14. icomplete-mode (or fido-mode?)
> > >
> > > Not sure this is a good idea, these modes present complex and
> > > potentially confusing UI.
> > >
> >
> > Users expect to see completion mechanisms in a modern editor.  Enabling
> > completion in programming modes would be a too complex task for such an
> > initial greeting, but with this the user would become aware that
> > completion mechanisms exist in Emacs.
>
> Then perhaps we need to develop a new completion mechanism.  Which
> IDEs show completion like icomplete-mode?
Sublime and atom have a menu pretty similar to ours. A bit more
graphical oriented, but in the same "spirit".

> > 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.
There are two options here:

1) Add more bindings to icomplete (arrows, C-n and so on)
2) Go for fido-mode which is more "friendly" like ido.

BTW Eli, I am working improving icomplete and the default
*Completions*. You can check the feature branches. If you have special
suggestions for them they are very welcome.

With my changes in *Completions* the experience is actually similar to
zsh completion...

And with icomplete I enabled the vertical layout (as helm or ivy do) and
added some coherent bindings.

What do you have in mind?

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