From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: An anonymous IRC user's opinion Date: Thu, 10 Oct 2024 10:25:54 +0300 Message-ID: <867cag2zct.fsf@gnu.org> References: <87plodsjsd.fsf@web.de> <865xq14dwp.fsf@gnu.org> <87ldyxclix.fsf@web.de> <87wmihj60r.fsf@dataswamp.org> 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="29929"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 10 09:26:56 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 1synZY-0007bZ-6u for ged-emacs-devel@m.gmane-mx.org; Thu, 10 Oct 2024 09:26:56 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1synYd-0001ch-TY; Thu, 10 Oct 2024 03:25:59 -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 1synYb-0001c2-J0 for emacs-devel@gnu.org; Thu, 10 Oct 2024 03:25:57 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1synYb-0007fG-4H for emacs-devel@gnu.org; Thu, 10 Oct 2024 03:25:57 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=9kjItGLfWuakYVRd7IiNTKgn6zAQnqhBwAi+fmo6Noc=; b=OAfmtdjmFCBvgKA/2Wye InVYLKG5ehzVZzhksQD95USzc6SGN4tuTYcibM2Us4pl+zo1x70ZDUdORwAezOLS3e0DL/PvmSv0Z 2mOnQORpL+iZ5t+htLMnqyKPyJfJmWVi92NcD4M9lsY1C8k/jLcwXRsQVoIV1t8Fn7febr528HLMb DBS0re33MtwcuLhB8LXo5lxhvAkMgzaYi3hrDyU1EkESQyMgTYY4i7ts5XPEI8+MaoMs+G9xhZhyf 29bO++1yVjDoLmYJp5xf3jqJn541gxetv0ZJh6tDnX5Vyq2I36yO4vOa0BhP18bmPR5fRLdNjFWAW wAIiPhoJXvJKJg==; In-Reply-To: <87wmihj60r.fsf@dataswamp.org> (message from Emanuel Berg on Wed, 09 Oct 2024 23:55:16 +0200) 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:324480 Archived-At: > From: Emanuel Berg > Date: Wed, 09 Oct 2024 23:55:16 +0200 > > Hello, I was asked to send this to this list; it is from our > anonymous IRC fried. Thanks. > The implementation is mainly about 2 parts: > > 1. part1: "Getting started" (or introduction to emacs). This is basically an alternative to TUTORIAL. It describes the Emacs basics in a different order than the tutorial, and I'm not sure which one is better. The advantage of this method is that it's shorter and introduces the basic concepts right away; the disadvantage is that the description is necessarily much more abstract, and almost nothing in it requires the reader to _do_ anything, which IME tends to bore and lose the reader's attention. > 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). I'm probably missing something because in the HTML you posted this part is basically empty. It mentions Customize in general terms, but that's _how_ to customize Emacs, not _what_ to customize. How is the user supposed to know which variables/features to customize? What did I miss? > 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. That's a tough ticket. There's so much in the Emacs display that is or might be important that explaining it in a short text is hard, if not impossible. For example, the description you posted doesn't mention the scroll bars, and the description of the mode line is only hinted upon; filling that with actual information will likely make it much longer. I think we'd most welcome attempts to do what you are trying to do, but it isn't easy. > 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 an idea that has come up before, more than once. I think everyone agrees that it's a good idea. The hard part in this is to come up with a good sequence of questions, which would address different usage patterns that Emacs can support. I don't think I've seen any attempts to do this which are close to completion, I only saw this idea being described and discussed, and a few attempts to produce a starting point. If you can post the more-or-less full list of questions (which will probably be a tree or a DAG, not a linear list, since the user should be asked quite early what are his/her needs that they want to accomplish with Emacs, and perhaps also what are their UI preferences.), please do: I think this could be a very good step in the right direction. > 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 think https://emacs.amodernist.com/ is a good starting point, but IMO it is nowhere near being complete. I see the following ways to improve it: . More background information on the features it asks about, so the readers could make up their minds about using them. For example, it asks about Org without actually telling much about it: how is the reader supposed to know ehether he/she wants it? It generally assumes that the readers already know what they want and need just to be pointed to the Emacs feature which implements some functionality. A good example is "Version Control" -- are we sure everyone knows what this is about? . It leaves out many popular and important features in Emacs. One notable example is email; another is access to remote files; yet another is debugging and the built-in GDB front-end; etc. etc. . The "Miscellaneous" section at the end is a very small subset of convenience features Emacs offers, and should be greatly expanded and classified into groups (otherwise it will be a very large unsorted list of unrelated settings, which will be hard to read and understand). It also needs to describe each feature in more than just a single sentence. > 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". If you want to code a customization interface that is based on asking questions, then doing that for complex values might be difficult or cumbersome. As a simple example, how do you propose to let users to customize a face by asking questions instead of having checkboxes and fields? The basic disadvantage of asking one question at a time is that the user doesn't see the whole picture, and also that there's no easy way of going back to a previous question and answering it in a different way. > 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. If a developer already knows about LSP, and already decided LSP server is the best solution for what the developer has in mind, then yes. But what if the developer doesn't know about the alternatives Emacs provides that don't require an LSP client? Setting up an LSP server is not a trivial task, so if Emacs provides an alternative, the customization helper you describe should give enough information for the developer to consider these alternatives and make up his/her mind about the one best for him/her. E.g., many people don't know about etags and the many languages it supports, or about ElDoc and its backends other than LSP-driven Eglot. IMO, the customization wizard should mention those. > 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. We don't recommend reading the manual in its entirety anywhere. Instead, we recommend reading those chapters and sections in the manual that are relevant to the job in hand. The manuals are well indexed and organized to allow this method and to make it time-efficient for our users. Thanks again for working on these important aspects of Emacs.