From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Moakt Temporary Email Newsgroups: gmane.emacs.devel Subject: Re: A new filter-based customization interface Date: Thu, 9 Jan 2025 13:46:55 +0000 Message-ID: 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="36950"; 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 Jan 09 15:14:56 2025 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 1tVtJI-0009TW-14 for ged-emacs-devel@m.gmane-mx.org; Thu, 09 Jan 2025 15:14:56 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVtIN-0000Ch-AK; Thu, 09 Jan 2025 09:13:59 -0500 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 1tVtH7-0005hz-Cy for emacs-devel@gnu.org; Thu, 09 Jan 2025 09:12:41 -0500 Original-Received: from [64.31.33.50] (helo=moakt.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tVtH4-0000bj-Sg for emacs-devel@gnu.org; Thu, 09 Jan 2025 09:12:40 -0500 Original-Received: from tm-php.tm_tm-network ([172.18.0.6] helo=localhost.localdomain) by moakt.com with esmtp (Exim 4.92) (envelope-from ) id 1tVssB-00079C-CB for emacs-devel@gnu.org; Thu, 09 Jan 2025 13:46:55 +0000 X-Mailer: PHPMailer 6.6.3 (https://github.com/PHPMailer/PHPMailer) X-Host-Lookup-Failed: Reverse DNS lookup failed for 64.31.33.50 (failed) Received-SPF: none client-ip=64.31.33.50; envelope-from=df0b35e27b55@drmail.in; helo=moakt.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.1 / 5.0 requ) BAYES_00=-1.9, FROM_LOCAL_HEX=0.006, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Thu, 09 Jan 2025 09:13:53 -0500 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:327819 Archived-At: Hi Richard, > > - make better choices: > > > many things can be done in emacs, in different ways, filtering on a > > specific topic, can show user that he has alternatives to what he is > > trying to accomplish. > > I am sure we could improve some specifics. But this goal > is abstract and gives no concrete hint of an idea. I am sure too. In fact, I didn’t provide a concrete example in all my reply, when I estimated it would be clear for a non-beginner emacs user to understand, not to make the message longer. Lets say user filters on “completion”, he would see all related options, including for example eglot and etags. (it was Eli’s suggestion to be able to put alternatives forward) > > - discover-ability: > > > emacs has many options/features (even little ones), that are of big > > help/change for users, in their daily use of emacs, and they often > > discover them (very) late. > > That too is a good goal, but it gives no concrete hint of an idea. There are many, everyday I discover a new option or feature, I say I wish I knew about it earlier, but for a fresh new user I would say which-key, undo-tree, vertico, changing theme, adding tabs, and many more. 1- This new interface (as you already saw in the image), can put them forward. 2- while filtering on some topic, user would discover options related to what he filtered on. To give a concrete example, if user filters on “modeline”, he would see all the related options, and would also discover that which-key can display the number of “shown keys” in the modeline too. (by setting the option which-key-show-remaining-keys to t) I, may be, am giving very simple example here, just to illustrate the idea, but I am sure many would understand how this intersection of options, can be useful in many other more complex/important situations. > > - self-descriptive: The interface by itself, before even using it, > > describes what emacs can do. (Yet emacs can do many other things that > > should be added to the interface) > > Same here. If you recall the image, you can see that I described what emacs can do, or in other words, what softwares, emacs can replace (that a user might be using more than one for those): basic editing (with spellcheck, completion, etc), IDE, note-taking, personal information manager, task manager, email client, agenda, reminder, etc. Any user seeing this image would understand immediately what he would have, when using emacs. (even before using it for customizing emacs) > > - navigation I find it difficult to navigate back and forth in the > > actual interface. > > If you can put your finger on a specific case, and describe > what is inconvenient, and send a bug report, people could think > about the specific issue and maybe find a way to improve it. > > But these abstract points are not easy to think about in he abstract. > > It looks like you do have a concrete idea. I couldn't understand the > way you presented it, because you didn't explain it, only showed it. > > The explanation hat is needed is about the _meanings_ of the details > that you previously just showed. I will explain it in a better way: When there is a tree to navigate/explore, user should always know where he is in the tree, and this can be accomplished in several ways. For example: 1- put the tree hierarchy on the left (or right, it does not really matter), to which a user would always refer. 2- if user is in the “sub-group3” node for example, display: group > sub-group1 > sub-group2 > sub-group3. (instead of only “sub-group3”) And it should be always visible (user should not scroll to see it). In the actual interface, when user use the “search bar” facility, this information even totally disappears. Whereas each set of options, should be preceded by the group hierarchy they belong to. For example: group > sub-group1 > sub-group2 > sub-group3 - option1 - option2 - option3 group1 > sub-group4 > sub-group5 > sub-group6 - option4 - option5 - option6 or any other suitable way, so navigating the options, would be always clear and _coherent_ from the user’s perspective. > > With the actual interface sometimes you also loose the sense of where > > you are. You can only see the direct parent group, and also sometimes > > you need to scroll to see it, other times you find multiple direct > > parent groups which can be confusing. > > I see what you mean. > > > With the new interface, we can avoid this. > > That would be desirable, but the question is _how__? Can you explain > the concrete change you envision that would (one hopes) have this > effect? If you recall the image I sent, the “filters” sections, and the “sorters” section, would be displayed in a left/right/up/down buffer (to which the user can always refer), and the resulting list of options would be displayed in a _separate_ (left/right/up/down) buffer. (The image actually shows them all in the same buffer) We can give user an option to decide which behavior he wants, in case he does not have enough room on his screen, for 2 separate buffers, or for any other reason(s). > > Most softwares have a fixed menu to the left, that is always there, to > > which you can always refer. And also sometimes tabs to the right (for > > each entry in the left menu), for which also you can always refer. > > I don't think I use any program which looks like that. > > With Emacs, having _anything_ on the left side or the right side _all > the time_ would be painful, since it would narrow the window available > to display the text you are editing. > > However, is this point solely about the customization interface? In > the customize interface it might be ok to have a column of something > always present on the left side. > > I can't understand the semantics of the "tabs" part. > If you _explain_ one concrete hypothetical example, > that might make it clear. Basically, you have a tree _permanently_ displayed in a left section , and each time you choose a node in that tree, you have the corresponding options displayed _always_ in a right section. Sometimes if the options are numerous (or for some other reasons), they would be classified under tabs (_always_ in the right section, while the tree still being _permanently_ visible in the left section). (interchanging left and right has no importance) But, I am not suggesting to copy any software, I am just saying that user having some “always visible” anchor points, is much easier for navigation. > > - beginner-friendly > > > Using terms that users may be already familiar with. Users can be > > coming from different backgrounds. > > There is an implicit contradiction between those two sentences. To > predict what terms users are familiar with, we need to know their > background. If their backgrounds are diverse, such prediction becomes > harder. I mean emacs has specific vocabulary, for which we can find a “middle-ground” terms, that “most” of the users (coming from different background) would understand. For example: - instead of using tab-bar or tab-line, we can just use tab. - command inputs, instead of, command arguments. (for non-tech users) - completion instead of in-buffer-completion and minibuffer-completion, ... - etc. These would be totally understandable by non-beginner users too. Other terms cannot be replaced and should be kept as is, even if they are emacs-specific, otherwise user would be confused when reading the manual, or any blog, or questions and answers on some platforms, etc. By the way, I am not imposing anything, I am just proposing (and only as examples to clarify the ideas), and the final decision is not mine. > > - gradually introduce users to emacs vocabulary > > That is a design goal, not an implementation plan. Realizing that > goal might be ok, or intolerable, depending on the specific way in > which the interface does that. If you recall the image, you can see for example the term “keybinding”. This will introduce the user to the term “keybinding”, in an indirect way. User would understand that this has some “special” important meaning in emacs. (User can be used to the term “keyboard shortcut” instead) The same goes for: face, keymap, kill ring, mark ring, etc. This was not really a goal by itself, when I came out with the interface idea, my goal was to make starting with emacs easier and more intuitive (specially the customization part), but it turned out that this interface has a lot of other advantages, and all point in the same direction. > Emacs has existed for 48 years. Much of its terminology has been the > same since then. By comparison, the other interfaces you are thinking > of are passing fads. There are changes we can make, but rewriting so > much documentation based on a fad would be misguided. > > We want to teach users our terminology, not try to speak in theirs. I agree. And my sentence goes in the same direction: “gradually introduce users to emacs vocabulary”, and this interface will help with that, as it puts them forward. In fact, I am not asking to change any of emacs terminology (or any other thing in emacs), in case I was misunderstood somewhere, or not clear enough. I hope all these points are more clear now, but lets not forget all the other points (I enumerated in my previous message), when evaluating the advantages/benefits of the new interface. Thank you