From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Emanuel Berg Newsgroups: gmane.emacs.devel Subject: Re: An anonymous IRC user's opinion Date: Wed, 09 Oct 2024 23:55:16 +0200 Message-ID: <87wmihj60r.fsf@dataswamp.org> References: <87plodsjsd.fsf@web.de> <865xq14dwp.fsf@gnu.org> <87ldyxclix.fsf@web.de> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24132"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) To: emacs-devel@gnu.org Cancel-Lock: sha1:x2PwoFODRydw6swEcv07Yw6Q20w= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 10 06:34:47 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1syksw-00068e-KS for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Oct 2024 06:34:46 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1syksk-0002uq-0t; Thu, 10 Oct 2024 00:34:34 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1syeeY-0002Ar-B7 for emacs-devel@gnu.org; Wed, 09 Oct 2024 17:55:30 -0400 Original-Received: from ciao.gmane.io ([116.202.254.214]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1syeeV-0005rZ-1M for emacs-devel@gnu.org; Wed, 09 Oct 2024 17:55:30 -0400 Original-Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1syeeQ-00049y-Ih for emacs-devel@gnu.org; Wed, 09 Oct 2024 23:55:22 +0200 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Mail-Copies-To: never Received-SPF: pass client-ip=116.202.254.214; envelope-from=ged-emacs-devel@m.gmane-mx.org; helo=ciao.gmane.io X-Spam_score_int: -15 X-Spam_score: -1.6 X-Spam_bar: - X-Spam_report: (-1.6 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 10 Oct 2024 00:34:31 -0400 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:324469 Archived-At: 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, [*GNU Emacs* buffer START]

[EMACS LOGO]

Welcome to GNU Emacs

Welcome to GNU Emacs, one component of the GNU/Linux operating system.

Before getting started, you may want to check:

  1. Absence of Warranty GNU Emacs comes with ABSOLUTELY NO WARRANTY
  2. Copying Conditions Conditions for redistributing and changing Emacs

Get Started

This is GNU Emacs version ... build ...
Copyright (C) ... Free Software Foundation, Inc.

[*GNU Emacs* buffer END]





[*Get Started* buffer START]

Getting Started

You can click on the words highlighted in blue to locate the corresponding item on the screen.
You can click on the words highlighted in grey to execute the corresponding action.

The text you are actually reading, is displayed in a window

This window is inside a frame.

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 New Window on Right inside the "File" menu in the menu bar 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.

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

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.

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 echo area. Every action in emacs results in a brief message so you can ... . This message will disappear after a short time or when ...

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

Each command is documented and you can find its documentation by clicking on ... <<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)>>

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

Each window display a single file content which is called buffer. 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 "New File" icon in the toolbar.

The toolbar contains some of the menubar commands for a quick and convenient access.

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.

You can also open some special emacs buffers in a window, like the *Messages* buffer which displays ... and the *Errors* 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 ...

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

Each window has its own modeline. The modeline is used to display ... flag1 ... flag2 ... buffer name ... buffer modes ...

This is all you need to get started using emacs.

If you want to learn more, you can read the manual:

  1. View Emacs Manual View the Emacs manual using Info
  2. Ordering Manuals Purchasing printed copies of manuals

You may also want to check:

  1. Emacs Tutorial Learn basic keystroke commands

What is next

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.

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

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 Emacs Guided Tour at gnu.org.

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.

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

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.

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.

Start Customizing emacs

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

[*Get Started* buffer END] -- underground experts united https://dataswamp.org/~incal