all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* A new filter-based customization interface
@ 2024-12-09  3:37 Moakt Temporary Email
  2024-12-10 19:56 ` Philip Kaludercic
  2024-12-24  4:51 ` Richard Stallman
  0 siblings, 2 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2024-12-09  3:37 UTC (permalink / raw)
  To: emacs-devel

Hi everyone,

I am proposing a new beginner-friendly customization interface, which would make emacs more attractive for newcomers, be it actual developers, future developers to be, and even non-developers (writers, students, professors, teachers, etc.), and any lambda person having interest in using emacs.

I added a screenshot of what such an interface might look like (which is better than words).
https://justpaste.it/fdau4.

The main idea of this customization interface is to help users quickly and easily customize emacs for the actual task(s) they need, by providing familiar filters so they can quickly select and access the relevant customizations.

For example, they can select “irc”, “ide”, “agenda”, “completion”, “version control”, “c++”, etc, to filter the customizations relevant to use emacs as an IRC client, IDE, etc.

Today this not possible, and would require new users days and weeks to configure emacs, which would discourage and thus discard lot of them from using emacs.

Do you think this is something achievable in emacs ?
Do you think the actual customization interface can be enhanced to include these changes ? Or should it be a new separate interface ?

I have added all the details about this idea here:
https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00174.html
(It is too long to read, that is why I am sending this separate message).

Thank you




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2024-12-16 22:02 Moakt Temporary Email
  2024-12-31  4:43 ` Richard Stallman
  0 siblings, 1 reply; 36+ messages in thread
From: Moakt Temporary Email @ 2024-12-16 22:02 UTC (permalink / raw)
  To: emacs-devel

Hi Richard,


> I looked at the image you sent.  I supposed it is supposed to be
> self-explanatory, but as often happens for graphical interfaces, I
> can't tell the meaning of what I see.
> 
> 
> In order for a graphica interface to be natural and self-evident,
> it should to be clear just by looking what each visual item means.
> Is it an alternative you can select?
> Is it a heading which describes the role of whatever follows?
> Is it a command you can click on to control the interface?
> These things are not clear to me.
> 
> Here are some of the visuak aspects for which the meaning is not clear to me.
> 
> * There is a bunch of lines at the top which start with
>     Filter by
>     1. categoryL 
>     interfaceL modeline tookbar,..
>     general: startup quit backup...
> 
> What do tese names mean?  Are they related to custom group names?
> Some of them sare names of custom groups, but some are not.
> What does each of these names mean?


Each name is a filter that user can select to filter on the corresponding user options. I tried to classify them using the most beginner-friendly terms, just to show the main idea I want yo communicate.

When the user sees such an interface, he will also have a quick idea of what he can do with emacs, he can also immediately start discovering/trying different options.


> * Is that an exhaustive list of all "categories"?


I added only some, just to show the main idea.

I can also think about other non-”by category” filters, for example:
1. by state: [customized] [non-customized (default)]
2. by version: .. [27] [28] [29] [to be removed in future versions (deprecated)]


> * If so, are you supposed to click on one to select it?
> * Or are some categories someho selexted now, and this is a list of the
> ones that are selected right now?


Yes, user can select a single filter, or combine (AND) multiple filters.
For example user can select “completion”+”auto-save”.

Each time the user select an additional filter, the list of filters should decrease, leaving only the ones that are meaningful to additionally select.

And maybe also making other sub-filters (sub-categories) appear to help further narrowing the list of customizations (under “Selected Customizations:”).
For example “auto-completion” filter can appear if “completion” filter is selected.

With this, user can precisely find what he is exactly looking for, with few easy and understandable clicks, even with a huge number of options.


> * How does the fact that a category is selected
> affect what happens in the rest of this display?


Each time the user select an additional filter, the list of customizations under “Selected Customizations:” will also decrease. The purpose is to quickly find the customizations relevant to a given task/behavior.


> The next thing it says is
> 
>   Sort by: package
> 
> What does that mean?  Is "package" one of several psople choices?  If
> so, what are the other possible choices and how do you specify another choice?


This should sort the list of customizations (under “Selected Customizations:”) by certain criteria. One example is “package”, another can be to list the already customized (non-default) first, etc.

I added it only to keep it in mind when implementing the interface, in case it turned out to be useful to the user later on. But I can’t see it is real added value for the moment.


> Then it says
> 
>   Selected Customizations:
> 
> What does that expression "selected customizations" mean?  What
> determines which customizations are selected?  How do you control
> which ones are selected?  And what do you achieve by controlling that?


The list under "Selected Customizations", are the customizations user selected by applying one or more filter(s) from the above.

Their is no filter selected in this image, but we can image that when user selects the “modeline” filter for example, we can either:
- replace it in-place by a “modeline[X]”.
- or remove it, and add a “modeline” or “modeline[X]” to a separate list of “selected filters” for example.
- or keep it in place, but change its appearance (color, etc…)
- etc.

With this, user can know what filters he already selected, and can unselected them one by one by clicking on them again.

Maybe it can also be implemented it differently.


> How does this relate to M-x customize...?
> It looks like the names of these things do NOT match names of user options.
> 
> Each item and value seem to be followed by some sort of classification,
> but what do they mean?  They do not seem to be custom groups.
> Where are they defined?  For instance, two say :modeline:,  What does
> that indicate?


Each item is a customization/option to show to the user.

The value is only a single choice (I added it for demonstration), but it can be replaced by its corresponding UI element (checkbox, dropdown menu, ...)

The classifications to the right are not part of the interface. I may have hidden them. I used them to “tag”/relate each entry to its corresponding filters/categories. These classifications are also not exhaustive (only some for demonstration).

All the options that are related to the modeline, would be tagged as “modeline”, and will be selected/filtered when user select the “modeline” filter.

Some classifications might (not) match with the actual custom groups, I tried to list them from another POV. they can be modified/adapted as needed.

This interface will require each option to have multiple groups/tags.

And maybe the user could be given the possibility to add his own tags (to each option, and to the interface), so he can categories, and quickly access his favorite options.

> What does [X] mean?  Does it mean "this is enabled"?

Yes, it represents a “checked” checkbox.


> If so, what indicates "this is not enabled"?
An “unchecked” checkbox would be represented by [ ].
But this is not how it might look like in the final interface, it is only for demonstration.
I also explained everything in details in this message https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00174.html.

I also proposed a quick “Get Started” introduction to emacs (frame, window, modeline, command, etc.), so user can directly use this interface.
This introduction can be added to emacs independently from the interface, because it already enhances user first experience with emacs, I post it under a different thread https://lists.gnu.org/archive/html/emacs-devel/2024-12/msg00064.html.

Thank you




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2024-12-31 11:49 Moakt Temporary Email
  2025-01-02  4:36 ` Richard Stallman
                   ` (4 more replies)
  0 siblings, 5 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2024-12-31 11:49 UTC (permalink / raw)
  To: emacs-devel

Hi Richard,


Thank you for taking my proposition into consideration.


> Would you like to familiarize yourself with M-x configure and related
> commands, see what it does and what it doesn't do, and describe
> your idea in terms of how it differs from what we already have?
>
> Do the differences concern manner of display, or the semantics
> of the customization methods?

I listed below some of the differences that come to my mind first:


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



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



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



- navigation
I find it difficult to navigate back and forth in the actual interface.

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.

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.

With the new interface, we can avoid this.
we can display all the filter section in a buffer, and all the resulting options in another buffer, which gives the user a more pleasant navigation (although we are comparing two different concept for finding the options).



- beginner-friendly
Using terms that users may be already familiar with.  Users can be coming from different backgrounds.



- gradually introduce users to emacs vocabulary
While most of the filters would use familiar terms, there are some that are emacs-specific.  This makes users realize that these words are important/special in emacs.
For example: face, overlay, minibuffer, keybinding, keymap, font-lock, narrowing, mark, region, kill ring, mark ring, etc.

User should have been already introduced to the other more important ones (modeline, frame, window, echo area, buffer, command, etc.), which are _really_ needed to start using emacs. (check the side note below)



- intuitive
emacs has a huge number of options, for which some are candidate to more than one group, and can have also some side effects on other things happening in emacs or on the user system, etc.  So the most intuitive way I can think of is to use tags.



- visually
I did not add anything special to the interface, yet it already looks nicer.
With little modifications it can be even better, we can for example use some colors, icons, etc.



- important options when starting with emacs:
There are somehow “known” options that user would normally add/change first when starting with emacs, we can put them forward, when the user opens the interface for the first time, or group them together under a specific filter.



- extensible/flexible
The interface can be extended to include any sort of filters.
For example, we can let user filter on options depending on emacs versions [...] [27] [28] [29] [30] [deprecated], or if option is safe or not, etc.



- help/learn:
I can see the same questions are being asked from emacs users, on platforms, (how can I do this ?, etc.), while in there very question, you can find the necessary keywords, that if they use in this interface, they would easily find what they are looking for.



- help/troubleshoot:
many questions are also related to problems, (having this behavior when doing this action, or emacs became very slow, etc.). These keywords can also be used to find the corresponding responsible option(s).



- attractive
Users are often attracted by what they see first, if an image of the new interface (yet to be enhanced/modified) is posted on emacs website, or on some platforms, will be more appealing to users, than an image of the actual interface.


- more informative
We can instead of displaying filters like this:
 [modeline]  [window]  [frame]  [tab]

we can add a counter of the underlying options like this:
 [modeline(30)]  [window(25)]  [frame(10)]  [tab(15)]



- user’s tags/filters:
We can give user the possibility to tag the options himself. (by workflow, project, task, work, home, friend, favorite, check later, laptop, etc.)
These tags would automatically appear in the interface.



- accurate results
doing a text search might not find the option user is looking for, maybe because the keyword is not included, or the keyword is wrongly written, or written differently, for example “modeline”/“mode line”, or maybe a synonym of the keyword was used.

Sometimes, user may get options he was not looking for, because it happened that the keyword is present in the text.



- possible search keyword(s)
new users often don’t really know what to search for.  For example, user should search for “auto-completion” or “auto-fill”, “cut” or “kill”, “paste” or “yank”, “region” or “selection”, “cursor” or “point”, “color” or “font” or “face” or “theme” or “appearance” or “visual”, etc.

while trying different keywords in the actual interface, user will get some results (and mostly different each time), which bring more confusion.

And even though, it happens that user chose the correct keyword(s) from the first time, and as the results are not guaranteed to be accurate (check previous section), this might bring even more confusion.



- excluding tags:
This interface would normally filter on intersection ([a] AND [b]) between selected filters.
But sometimes user would need to select [a] AND [b] AND ![c].
I don’t see the usefulness of doing a union [a] OR [b], but it can also be implemented using this interface, if needed.



- task-oriented
When users choose emacs (or any other software), it is to accomplish a given task first (agenda, spellcheck, irc, etc.), this interface (a) will enable users to quickly find the options related to the given task.

If someone may find that these tags should be represented in another way (b), or someone else prefers (c).

We can give the user an option to choose between interface (a), (b) or (c), with one of them being the default.



-package integration: [^1]
we can also integrate packages, so user can easily find the needed package(s), and install them (their corresponding options would be then added).
It would be somehow similar to what “M-x finder-by-keyword RET” does.

This will also be a nice and straight-forward way to gradually introduce user to package ecosystem in emacs.



- user’s commands integration: [^2]
We can also tag the commands in the same go, so user can easily find the command(s) he needs to accomplish a certain task, the same advantages above would apply here.



- other symbols integration: [^3]
Also tagging the other api functions, variables, hooks, macros, etc, which will be a great help for users/developers trying to learn and/or write their own: (the same advantages above would apply here too)
+ to see if it already exists, before doing so.
+ to search which api they can use, for a certain task, in their own functions.
+ to find some similar functions, as an example/inspiration to what they are trying to accomplish (if the “exact” functionality is not already implemented).
+ to “discover” the available api gradually.



- other
tagging the options might have other usefulness than for using them for this interface.  Some tags can be more internally oriented, and not intended to be used/shown to user.




[^1], [^2], [^3]:
For these, they can be in a separate interface, or we can add them to the same interface, for example as below:
- filter by type: [option] [command] [variable] [function] [macro] [hook] [package]




Side Note:
----------
I wrote a “Get Started” introduction to emacs, and showed how it can be nicely integrated in the current Startup buffer, to guide the user when opening emacs for the first time (or even referring to it later as needed), and I would like to know your opinion on it.  It is the HTML code at the very end of the following message: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00245.html.



I am proposing a global idea to make starting with emacs much easier and intuitive for newcomers and deferring any (long) reading material to later on. (this will also be useful for everyone)



Thank you




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2025-01-09 13:46 Moakt Temporary Email
  2025-01-10  3:24 ` Richard Stallman
                   ` (2 more replies)
  0 siblings, 3 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2025-01-09 13:46 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2025-01-13 23:39 Moakt Temporary Email
  2025-01-14 12:58 ` Eli Zaretskii
  0 siblings, 1 reply; 36+ messages in thread
From: Moakt Temporary Email @ 2025-01-13 23:39 UTC (permalink / raw)
  To: emacs-devel

Hi Eli,



> Since we already have customization groups and commands to present
> them and allow users to look for the group(s) they need and customize
> the relevant aspects, I feel that improving our groups (which
> currently look not very rational or even helpful).  The next step
> would be to support intersection	s of groups.
> 
> WDYT?



I am glad, you got the idea I am trying to communicate.

The groups definitely need to be improved, but wouldn’t that break backward compatibility for users that might be using the current interface, and/or the associated commands and groups ?

Maybe also some user’s code exits today, to auto-manipulate these groups, that might break ?

It may also take non-negligible amount of time, that can be put towards the new interface ?

Another important question is that, can we really use the groups for “tagging” options ?

If, for every option, we add the corresponding potential tags, as groups, the actual customization interface tree can explode in size, and become unmanageable and difficult to find the option, and groups might even finally have a higher number of options for the user to go through.

And if we don’t do so, we loose the ability on doing the intersection between options later on, which is at the heart of the new interface, and which allow user to quickly/easily find and also discover options.

If we also make an option appears in too many places in the tree, which is meant initially to be navigated/browsed as such, it can be tedious and confusing for users.

I maybe have missed something ? WDYT ?


What about adding the packages ?
The actual interface does not show the options of unavailable packages.

To make up for that, we can at least, in the new interface, let users also easily browse/find/discover the packages, and install the ones they need, and then the corresponding options would appear in the interface (so they do not miss some potentially useful features, they can add, while filtering on a given topic).


Does this make sense ?



Thank you




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2025-01-13 23:44 Moakt Temporary Email
  0 siblings, 0 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2025-01-13 23:44 UTC (permalink / raw)
  To: emacs-devel

Hi Richard,



> Your idea has both "filters" and "categories".  I gather that both
> filters and categories select subsets of the set of all the options.
> 
> What is the difference between these two kinds of subset?
> Which subsets should be "filters" and which should be "categories"?
>
>   > 1- This new interface (as you already saw in the image), can put them
>   > forward.
> 
> I understand the general goal here, but _how_, concretely, does this
> interface do that?
> 
> You talk about general goals, and they make sense as goals.
> But in order to be an idea that is possible to consider,
> it has to explain _how_ it will make certain options
> more discoerable.



I think, the message I just sent to Eli, can bring more insights to your questions ?
If it is not the case, please let me know.


I wish if you can also take some time, and read the introduction to emacs, I proposed, and let me know what do you think about it.

It is the html code at the end of the following message: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00245.html.



Thank you




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2025-01-14  0:01 Moakt Temporary Email
  0 siblings, 0 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2025-01-14  0:01 UTC (permalink / raw)
  To: emacs-devel

Hi Björn,


Thank you for your interest in the topic.



> I don't want change any term either but Moakt's explanation is very
> valid. Just shrugging and call of an argument is not good I think.
> 
> Language, terminologies evolve and change over time so do interfaces.
> I think it's inevitable that even Emacs has to go with the time
> in some shape or form. Requiring or expecting users to learn 48 old
> language with outdated legacy term is very off putting.



You might be right.  But changing the terminology of a software that existed for such a long time, can be a tedious task.  There are also many documentations, blogs, books, videos, etc, that would get obsolete.

The question that can come up, is it worth to be done ? Or in other words, what this would “really” bring “vs” the things that it would break ?

Wouldn’t it be better to put all these efforts in other places, which can make emacs easier to start with, like the new customization interface for example, which might be a bigger obstacle, and might have a bigger impact on new users ?

These terms might not finally be the real obstacle for new users to chose emacs, if they are well presented and explained.  I thought about it for a while, and proposed a “Get started” introduction to emacs (to be accessed from the very startup buffer).

It will introduce users to some of these terms that are really needed to start using emacs. And the new interface can take care of the remaining terms.

I would be glad if you can take some time and read it, and let me know what do you think.  It is the HTML at the end of the following message: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00245.html.



Thank you again




^ permalink raw reply	[flat|nested] 36+ messages in thread
* Re: A new filter-based customization interface
@ 2025-01-14  0:07 Moakt Temporary Email
  0 siblings, 0 replies; 36+ messages in thread
From: Moakt Temporary Email @ 2025-01-14  0:07 UTC (permalink / raw)
  To: emacs-devel

Hi Björn,


Thank you for your interest in the topic.



> I don't want change any term either but Moakt's explanation is very
> valid. Just shrugging and call of an argument is not good I think.
> 
> Language, terminologies evolve and change over time so do interfaces.
> I think it's inevitable that even Emacs has to go with the time
> in some shape or form. Requiring or expecting users to learn 48 old
> language with outdated legacy term is very off putting.



You might be right.  But changing the terminology of a software that existed for such a long time, can be a tedious task.  There are also many documentations, blogs, books, videos, etc, that would get obsolete.

The question that can come up, is it worth to be done ? Or in other words, what this would “really” bring “vs” the things that it would break ?

Wouldn’t it be better to put all these efforts in other places, which can make emacs easier to start with, like the new customization interface for example, which might be a bigger obstacle, and might have a bigger impact on new users ?

These terms might not finally be the real obstacle for new users to chose emacs, if they are well presented and explained.  I thought about it for a while, and proposed a “Get started” introduction to emacs (to be accessed from the very startup buffer).

It will introduce users to some of these terms that are really needed to start using emacs. And the new interface can take care of the remaining terms.

I would be glad if you can take some time and read it, and let me know what do you think.  It is the HTML at the end of the following message: https://lists.gnu.org/archive/html/emacs-devel/2024-10/msg00245.html.



Thank you again




^ permalink raw reply	[flat|nested] 36+ messages in thread
end of thread, other threads:[~2025-01-16  0:06 UTC | newest]

Thread overview: 36+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-12-09  3:37 A new filter-based customization interface Moakt Temporary Email
2024-12-10 19:56 ` Philip Kaludercic
2024-12-12  4:48   ` Richard Stallman
2024-12-24  4:51 ` Richard Stallman
2024-12-24 21:10   ` Björn Bidar
     [not found]   ` <87bjx0oki1.fsf@>
2024-12-26  4:30     ` Richard Stallman
2024-12-29 15:29       ` Björn Bidar
     [not found]       ` <87o70ucxt5.fsf@>
2024-12-29 18:23         ` [External] : " Drew Adams
2024-12-29 23:39           ` Björn Bidar
2024-12-31  4:43         ` Richard Stallman
2025-01-01 20:00           ` Björn Bidar
     [not found]           ` <87o70quwxo.fsf@>
2025-01-16  0:06             ` Richard Stallman
2024-12-26  4:30     ` Richard Stallman
2024-12-27  2:04       ` Madhu
2024-12-27 13:07         ` Jean Louis
2024-12-27 15:16         ` dick.r.chiang
2024-12-28  5:58         ` Joel Reicher
2024-12-29 20:02       ` Björn Bidar
     [not found]       ` <87a5ce1clq.fsf@>
2024-12-31  4:43         ` Richard Stallman
  -- strict thread matches above, loose matches on Subject: below --
2024-12-16 22:02 Moakt Temporary Email
2024-12-31  4:43 ` Richard Stallman
2024-12-31 11:49 Moakt Temporary Email
2025-01-02  4:36 ` Richard Stallman
2025-01-02  4:36 ` Richard Stallman
2025-01-02  4:36 ` Richard Stallman
2025-01-02  4:36 ` Richard Stallman
2025-01-02  4:37 ` Richard Stallman
2025-01-09 13:46 Moakt Temporary Email
2025-01-10  3:24 ` Richard Stallman
2025-01-10 15:29 ` Björn Bidar
     [not found] ` <87o70eptze.fsf@>
2025-01-16  0:06   ` Richard Stallman
2025-01-13 23:39 Moakt Temporary Email
2025-01-14 12:58 ` Eli Zaretskii
2025-01-13 23:44 Moakt Temporary Email
2025-01-14  0:01 Moakt Temporary Email
2025-01-14  0:07 Moakt Temporary Email

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.