Re: An anonymous IRC user's opinion

[Emanuel Berg]

Hello, I was asked to send this to this list; it is from our
anonymous IRC fried.

-------------------------------------------------------------

Hi,

Thank you all for your interest in my message, and for taking
time to read it and time to reply. I will try to reply to all
your messages in this single message.

I first thought the implementation I proposed was obvious, so
I kept some space for your suggestions as you know emacs
better than me, but it seems that this brought a lot of
confusions, so this new message will bring all the details
about the implementation so you do not have to guess what
I meant.

I prefer that you keep in mind the main goal (and not the
implementation itself), which is: To make emacs up and running
with a useful configuration (not only as text editor, even
here many customizations can enhance emacs) in a reasonable
time, for almost every situation/scenario for everybody.

What I meant by "everybody" is any potential user, that emacs
can offer him to do what he needs to do (if emacs can do
something, and a user needs to do this thing, then he is
a potential emacs user). He can be dev/non-dev or
beginner/non-beginner, no difference between users.

Users who wants to read the manual first to use emacs, are
already taken care of, and the manual is great. But what about
all the other users ?

I stated in my previous message, that I immediately discarded
to propose the idea of a pre-configured init file
(pre-configured emacs), and this was for many reasons:

1. There are a lot of "elementary" use cases/customizations,
   which new users usually want to start with (only one task
   they need at the very moment). But what if they, just after
   that, want to mix between these to make more "complex" use
   cases/customizations? or even to change a single
   customization which does not suites them in a given
   pre-configuration? This quickly becomes unmanageable.

2. This also has a big problem which is to make everyone agree
   on what are those use cases to provide
   a pre-configuration for.

3. Another big problem is to make everyone agree on what are
   the "defaults" to put in each pre-configuration.

I think, in general, any idea which is very opinionated, will
start a long debate before it eventually fails (wasting lot of
efforts).

4. This will also need extra work to publish and maintain all
   these pre-configurations with their documentations.

Some suggested that this is a documentation problem, and emacs
needs to provide official documentations to customize emacs
for certain tasks. Even though this is a very useful
enhancement to emacs, it is very similar to the idea of
a pre-configured emacs, thus having the same drawbacks listed
above, in addition to leaving the user to do the
pre-configuration himself which brings all discussion to the
beginning (and also adding more documentations for the user to
read).

That is why I suggested the Q&A customization:

1. User can freely customize emacs for any use case (simple or
   complex/combination or even small tweaks).

2. User will customize emacs from the ground up (self cooking,
   with no magic). Hiding details he does not really need to
   know to start using emacs (he will, but this will happens
   later).

3. User will also be able to re-customize emacs (in the same
   way he did at the beginning).

4. emacs defaults are unchanged (avoiding any agreements
   problems).

5. no use cases (pre-configurations) to agree on.

6. no new defaults to be introduced or to agree on.

7. no extra effort to document, publish and maintain any
   pre-configuration (I think this implementation will help
   and encourage users to generate their own
   pre-configurations, for some specific tasks, in a very easy
   way, and start sharing them).

I wrote the implementation in HTML, which you can find at the
end of this message (all the links inside are empty and does
not link to any resources).

Please do not consider the design, fonts, colors and text
content, etc. I am not a designer and I may also have wrote
something wrong about emacs, so feel free to change or
correct anything.

If this implementation does not suites you, you can also
change it, this implementation is provided to have better view
of the main idea.

If this implementation suites you, I think it will need 3
things to be completed:

1. Fill the dots (...) and change/adapt the
   text,colors,links,... that I suggested.

2. List all the questions/customizations to be asked for user,
   and organize them in a hierarchy.

3. Write the code that will collect user input, and configure
   emacs accordingly.

It is not necessary to add all the possible
questions/customizations before making this feature available
in emacs. A useful subset is just fine, and more
questions/customizations can be added gradually later.

The implementation is mainly about 2 parts:

1. part1: "Getting started" (or introduction to emacs).

2. part2: "What is next" (or emacs customization).

For part1’s implementation, I had to modify the actual *GNU
Emacs* startup buffer, so I:

- moved some links to a new *Get Started* buffer (I have
  added).

- kept only what I guess should really be kept.

- modified/added some texts.

- added a "Get Started" link which should open the new *Get
  Started* buffer. (feel free to change the names or anything,
  as stated previously, the names I chose everywhere are only
  for demonstration).

Part1 can be added to emacs as of now, if everybody agree on
of course (with some work to fully complete it), because it is
totally independent from part2, and it enhances user first
experience with emacs. If you want, you can move part1 (part1
HTML) to a separate thread to collect everybody input on
it separately.

I added part2 also inside the same new *Get Started* buffer,
it can be easily moved to a separate *What Is Next* buffer if
needed (in this case a "What is Next" link should be added in
*Get Started* buffer to open the *What Is Next* buffer).

1. part1: Getting Started:

This part is to introduce user to emacs vocabulary/environment
in a very quick way, because emacs vocabulary is very special,
and the ui also like for example the modeline (which is useful
to start using emacs). Only things that user need to know to
start using emacs are to be shown, when the user is satisfied
he will be motivated to read further, and even read the
manual later.

Anything which is not really necessary to start using emacs
like keybindings, packages,..., better be avoided.

Even the minibuffer, that is why I only mentioned the "echo
area", new users does not need to know the difference between
the "echo area" and the minibuffer (if I am not wrong), and
previous emacs users will understand this as well (because the
minibuffer is displayed in the "echo area" anyway). New users
should also not know that they can open multiple frames, to
start using emacs, etc.

The introduction should not only be as short as possible, but
as easy, attractive, entertaining as possible, in other word
non-boring or difficult to understand.

For example when user start clicking on the links and see the
immediate result of his actions, he will continue clicking and
clicking, etc.

>From the first time user open emacs, he will be guided, and
start clicking and clicking, and in about 20 to 25
entertaining clicks and 5 to 10min reading, he will be
familiar with emacs, and feels he can do something useful,
without even noticing the time he spent there.

This part is not fully completed (almost completed), but is
enough to give you a very clear idea. This part is also needed
for the part2 ("customizations" part), as the user cannot be
asked if he wants to remember the windows positions, without
him knowing what a window is in the first place. etc (even if
user is familiar with similar softwares, emacs has a special
vocabulary, as stated above, that user needs to know before
using/customizing emacs).

2. part2: What is next (the "customization" part):

This part can be moved to a separate dedicated *What Is Next*
buffer, if it is better, as stated above.

This part is also already described in my previous message (If
you landed here directly, I encourage you to read the first
message
https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00018.html).

This part give a user a fast way to customize emacs to his
needs, by asking him questions.

This is somehow similar to the idea of the actual "Customize
Startup" link located in the actual *GNU Emacs* startup
buffer, but this actual link contains only a very limited
subset and are also not beginner friendly (lot of advanced
vocabulary that needs user to read the manual first).

This is also similar to https://emacs.amodernist.com/
I mentioned in my previous message.

I also prefer this "customization" part to be questions asked
in the minibuffer if possible, and not a a sequence of buffers
with long texts, checkboxes, buttons, fields,..., like the
"customization interface".

This is just a personal preference, if you think this is not
possible or not user friendly or any other reason, it is ok.
If this will cause agreement issues, then maybe both can be
added, and let the user choose which one he wants to use (if
the ui interface is chosen/implemented, it will be very easy
to implement the Q&A in the minibuffer anyway).

It is basically a hierarchy of questions with the top level
questions being let say around 10, so when the user click the
"Start customizing Emacs" link (I added), he needs to press
the "Enter" key 10 times to know what he can do with emacs
(ui/themes, basic editing, communication suite, development,
org, ...), and only when the user chose to customize
something, he will be asked the corresponding next level
questions, also the next level questions should be as few as
possible, and the next level questions too, etc...

Similar to the "customization interface" hierarchy but using
more generic and beginner friendly terms, and proposing
features which can be found in GNU ELPA archive packages
(without the user having to know about packages, and use the
actual "package interface" to discover new packages and
install them manually, etc.)

When the user is satisfied, he will be motivated to read the
manual later and know more about emacs.

Imagine a developer who needs a code editor with a LSP client,
and he does not know anything at all about emacs and also
about some other editor. Compare the time he needs to use
emacs as a LSP client with auto-complete, and the time he
needs to use the other editor as LSP client with
auto-complete. He needs to spend at least days, if not weeks
to understand many things about emacs and have something
useful to work with.

This is just one and a very simple example among many.

This is not to mention all the compile errors when installing
a package sometimes, ..., and if he wants to customize emacs
by editing the init file directly, how many times emacs will
start with a blank page with an error, because he forgets
a single parentheses somewhere, and he finds himself totally
blocked, ... , this is not to mention too the packages that
are really useful to first use emacs specially for beginners,
like undo-tree, vertico+orderless if they want to read about
and use the minibuffer directly, ...).

All these times spent by previous emacs users, and that will
be spent by new emacs users, can be easily avoided, and maybe
converted into contributing to emacs. The thing is that you
need to encourage users to start using emacs in the first
place, by lowering the entry barrier, and many of them will
sooner or later go and read the manual, and know more about
emacs, and contribute to add some functionalities they need
and/or correct a bug they are facing, but if users are
discarded from the beginning, this is not good.

Some users may instead be interested in (or prefer) reading
the manual first, and using the customization interface or
manually editing the init file, why not, but even here, many
do not have enough time to do that, so they let it go.

That is why I think this feature is very useful. I may be
wrong, or I may have missed something.

I am not saying that users should not use the "customization
interface" or edit the init file directly. I only think that
the entry barrier to emacs is too high (to discourage most
users), and can be easily lowered.

This will not only be for beginners, even people who are
already using emacs can use it. There will be 3 ways to
configure emacs:

- customization interface.

- editing the init file directly.

- this new feature.

This feature can contains advanced customizations of course
(for example that needs user to read emacs manual or any other
documentation before using them), but they will be hidden
behind questions like "Do you want to customize IRC client
(yes/no) ?":

- users who does not know anything about IRC and not
  interested will choose "no".

- interested users will go to read about IRC to know more
  about it and come back later. They can even choose "yes" to
  see what are the next questions (without affecting emacs).

- and users who already know about IRC, will choose "yes", and
  will know how to answer the next questions and how to use
  IRC afterwards.

Thank you all for you time,

<!DOCTYPE html>
<html>
<head>
<style>
.ui {
  background-color: lightskyblue;
  color: #fff;
  display: inline-block;
  padding: 0px 3px;
  border-radius: 3px;
}

.action {
  background-color: lightgrey;
  color: #fff;
  display: inline-block;
  padding: 0px 3px;
  border-radius: 3px;
}
</style>
</head>
<body>

<span>[*GNU Emacs* buffer START]</span>
<div id="GNU Emacs">
<hr></hr>
<h1 style="text-align:center;">[EMACS LOGO]</h1>
<h2 style="text-align:center;">Welcome to GNU Emacs</a></h2>

<p style="color: #ff0000;">Welcome to <a href="">GNU Emacs</a>, one component 
of the <a href="">GNU/Linux</a> operating system.</p>

<h3>Before getting started, you may want to check:</h3>
<ol style="list-style: none; font-size: 14px; line-height: 32px; font-weight: 
bold;">
<li> <a href="">Absence of Warranty </a> GNU Emacs comes with ABSOLUTELY NO 
WARRANTY</li>
<li> <a href="">Copying Conditions</a> Conditions for redistributing and 
changing Emacs</li>
</ol>

<h2 style="text-align:center;"><a href="">Get Started</a></h2>
<p>This is GNU Emacs version ... build ...<br/>
Copyright (C) ... Free Software Foundation, Inc.<p>
<hr></hr>
</div>
<span>[*GNU Emacs* buffer END]</span>

<br></br>
<br></br>
<br></br>

<span>[*Get Started* buffer START]</span>
<div id="Get Started">
<hr></hr>
<h2 style="text-align:center;">Getting Started</h2>

<p>You can click on the words highlighted in <span class="ui">blue</span> to 
locate the corresponding item on the screen.<br/>
You can click on the words highlighted in <span class="action">grey</span> to 
execute the corresponding action.</p>

<p>The text you are actually reading, is displayed in a <a href="" 
class="ui">window</a></p>

<p>This window is inside a <a href="" class="ui">frame</a>.</p>

<p>You can open multiple windows inside a frame. For example, to open a new 
window to the right, you can click on the menu item <a href="" 
class="action">New Window on Right</a> inside the "File" menu in the <a href="" 
class="ui">menu bar</a> located at the top of the frame. Each menu item will 
execute a specific emacs "command" to accomplish a specific task. To close a 
window you can ... . If you accidently closed this window you can .... or you 
can close and open emacs again.</p>

<p>The menu bar contains all the commands you need to accomplish all kind of 
tasks in emacs.</p>

<p>In case you changed your mind and want to cancel a command you have already 
initiated, you need to press the "g" key while pressing and holding the 
"Control" key on your keyboard (C-g). You can also press this key combination 
if you think that a command is taking too much time to complete or is making 
emacs unresponsive to other commands you are trying to initiate.</p>

<p>You may have noticed that when you opened the new window, a message was 
displayed in the bar at the bottom of the frame. This bar is called the <a 
href="" class="ui">echo area</a>. Every action in emacs results in a brief 
message so you can ... . This message will disappear after a short time or when 
... </p>

<p>Some commands you execute may need further input from your side, for example 
if you execute the search command to search for a specific word or phrase in a 
specific buffer, you need to provide the word or phrase you are are searching 
for. When you execute such commands, a brief and persistent message is 
displayed in the echo area which ends with a colon ":", showing what the 
command is expecting as input from your side. In this case it is the "Search 
for string:" message which is inviting you to enter the word or phrase you are 
searching for. You need to enter these directly after the colon ":". If you 
want to cancel the search command you need to press (C-g) as describe earlier. 
If you need to use the search command, you may want to read the documentation 
about it first in ... .</p>

<p>Each command is documented and you can find its documentation by clicking on 
... &lt;&lt;<span style="background-color:yellow">user needs a simple way to 
access this. Same as clicking on [Help->Describe->Describe Key or Mouse 
Operation] then selecting the command (he wants) in the menubar (Without using 
keybindings or using the minibuffer)</span>&gt;&gt;</p>

<p> You can work inside a single window at a time, the one having the focus, 
this is usually indicated by a blinking <a href="" class="ui">cursor.</a> The 
cursor is also known as "point" and indicates where the text you are going to 
type will be inserted.</p>

<p> Each window display a single file content which is called <a href="" 
class="ui">buffer</a>. To open a new file in the right window, you need to 
click inside the right window first, to get the focus, and then click on the <a 
href="" class="ui">"New File" icon</a> in the <a href="" 
class="ui">toolbar</a>.</p>

<p>The toolbar contains some of the menubar commands for a quick and convenient 
access.</p>

<p>To close the file displayed in the right window, you need to ... but this 
will not close the window itself, to close the window you need to repeat the 
same step described earlier. Closing a window will not close the buffer 
displayed inside, the buffer will remain opened in emacs and you can display it 
again in any other window you want.</p>

<p>You can also open some special emacs buffers in a window, like the <a 
href="" class="action">*Messages*</a> buffer which displays ... and the <a 
href="" class="action">*Errors*</a> buffer which displays ... . If you 
encounter any error you may want to search ... first, or send an email to ... 
or join the IRC channel ... , or ...</p>

<p> Emacs special buffers names are always surrounded by **. The buffer you are 
actually reading is named *Get Started* as you can see in the <a href="" 
class="ui">modeline</a>. This buffer replaced the previous buffer that was 
opened in this window when you first started emacs and which was called <a 
href="" class="action">*GNU Emacs*</a> (also known as the startup buffer).</p>

<p>Each window has its own modeline. The modeline is used to display ... <a 
href="" class="ui">flag1</a> ... <a href="" class="ui">flag2</a> ... <a href="" 
class="ui">buffer name</a> ... <a href="" class="ui">buffer modes ...</a></p>

<p>This is all you need to get started using emacs.</p>

<p>If you want to learn more, you can read the manual:</p>
<ol style="list-style: none; font-size: 15px; line-height: 32px; font-weight: 
bold;">
<li> <a href="">View Emacs Manual</a>  View the Emacs manual using Info</li>
<li> <a href="">Ordering Manuals</a>   Purchasing printed copies of manuals</li>
</ol>
<p>You may also want to check:</p>
<ol style="list-style: none; font-size: 15px; line-height: 32px; font-weight: 
bold;">
<li> <a href="">Emacs Tutorial</a>  Learn basic keystroke commands</li>
</ol>

<h2 style="text-align:center;">What is next</h2>

<p>Now that you are familiar with emacs environment, and ready to start using 
emacs, you may want to customize emacs first to suites your specific needs.</p>

<p>You can customize everything in emacs. For example you can hide the toolbar, 
the menu bar, the modeline, you can change the items displayed in the modeline, 
you can change the startup buffer, you can choose to automatically save the 
files you are editing, and choose when they got saved, you may want to 
automatically keep a backup of these files too, ...</p>

<p>The following link will help you do that, and in the same time you will be 
discovering the mostly used features in emacs, you can also have an overview of 
some of these features in the <a href="">Emacs Guided Tour</a> at gnu.org.</p>

<p>Clicking on this link will execute a command like the ones you initiate from 
the menubar or the toolbar. This command needs further input from your side for 
each customization, which you will have to enter in the echo area as usual.</p>

<p>All the customizations have a pre-selected value, you can hit the "Enter" 
key to keep this value, or you can chose another value ....</p>

<p>You can repeat this step as much as you need, to re-customize emacs, or even 
to check what are the values for certain customizations. The values in green 
are the values you have never changed (emacs defaults), the values in red are 
the ones you have already changed, in a previous run, to a non-default 
value.</p>

<p>All the customizations will be stored under .... in case you want to backup 
your customizations, or you want to use the same customizations for another 
emacs instance running on a different device, without having to repeat this 
step again.</p>

<h3 style="text-align:center;"><a href="">Start Customizing emacs</a></h3>

<p>If you need a more advanced customizations, or you want to know what other 
features emacs can offer, you may want to read the emacs manual first, and then 
use the more advanced <a href="">customization interface.</a></p>

<hr></hr>
</div>
<span>[*Get Started* buffer END]</span>

</body>
</html>

-- 
underground experts united
https://dataswamp.org/~incal