Re: Interactive guide for new users

[Ergus <spacibba@aol.com>]

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