A new filter-based customization interface

A new filter-based customization interface

[Moakt Temporary Email]

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

Re: A new filter-based customization interface

[Philip Kaludercic]

[-- Attachment #1: Type: text/plain, Size: 593 bytes --]

Moakt Temporary Email <emacs-devel-proposal@drmail.in> writes:

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

As this site is rather slow, here is the same image attached to this
message:


[-- Attachment #2: bde00610157f1ad327d8d066d5bc1744.png --]
[-- Type: image/png, Size: 334041 bytes --]

[-- Attachment #3: Type: text/plain, Size: 1701 bytes --]


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

My question is how this is worse or better than having some kind of
attributes added to user options and then having a
`customise-group'-like command that presents all suggested "irc", "ide",
"agenda", ... options.

But generally speaking, it seems that beginners are not interested in
being overburdened with all the things they can decide on (even if this
is categorised), but rather to have as many thing as possible to DTRT OOTB.

> 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 tend to feel that it would be better to have a separate UI with fewer
choices (beginners are probably not /that/ interested in the differences
between saving something for this session or permanently, I'd think?).

> 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

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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?

* Is that an exhaustive list of all "categories"?
* 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?

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

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?

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?

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?

What does [X] mean?  Does it mean "this is enabled"?
If so, what indicates "this is not enabled"?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

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

That site seems to depend on nonfree Javascript code.  Those of us who
block nonfree Javascript. or block Javascript entirely, cannot see
whatever you meant to show us.

Even worse, there are people on the lis who do not block nonfree
Javascript in their browsers.  By referring to that site, you are
promoting the use of nonfree software!  And, in the process,
legitimizing the use and distrbution of nonfree software -- which is
the direct opposite of the goal of GNU.

Would you please describe or present your idea in a way that we can
understand without running nonfree software?  Then we could all think
about adding it to Emacs.

Emacs already has a general configuration interface, which you can
access using M-x configure.  It at least tries to do what you have in
mind.  Your approach, if implemented without nonfree software,
might be better in some ways.

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?

M-x configure displays through Emacs buffers and Emacs redisplay
because that is the facility that is always avaiable (in Emacs).
Using some other basis could look nicer, but would be a lot more work
to implement and to maintain in various situations.

However, different semantics might not have such an obstacle.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I added a screenshot of what such an interface might look like (which
>   > is better than words).  https://justpaste.it/fdau4.
>
> That site seems to depend on nonfree Javascript code.  Those of us who
> block nonfree Javascript. or block Javascript entirely, cannot see
> whatever you meant to show us.

The website works entirely without JavaScript.
But there you go:
https://jpcdn.it/img/bde00610157f1ad327d8d066d5bc1744.png

> Even worse, there are people on the lis who do not block nonfree
> Javascript in their browsers.  By referring to that site, you are
> promoting the use of nonfree software!  And, in the process,
> legitimizing the use and distrbution of nonfree software -- which is
> the direct opposite of the goal of GNU.

People promote non-free software all the on this list e.g. with
@gmail in their addresses or talk about non-free operating systems.
There's even a package solely to support non-free software in Elpa.

> Would you please describe or present your idea in a way that we can
> understand without running nonfree software?  Then we could all think
> about adding it to Emacs.

Emails allow for attachments.

> Emacs already has a general configuration interface, which you can
> access using M-x configure.  It at least tries to do what you have in
> mind.  Your approach, if implemented without nonfree software,
> might be better in some ways.

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


The configure interface looks at times very old. I.e. in context of the
search it is very hard to see what the results actually are yes it does
show categories and settings items but it doesn't not show where they
are from e.g. as in which catergory a item is from or what tags it could
have.
I'm aware that Custom doesn't track tags but it is expected that most
system do use them or at least understand them for searching.

> M-x configure displays through Emacs buffers and Emacs redisplay
> because that is the facility that is always avaiable (in Emacs).
> Using some other basis could look nicer, but would be a lot more work
> to implement and to maintain in various situations.

The problem isn't eye-candy, functionality is the problem, e.g. in
discoverability. Improvements would help mostly beginner level users but
also long term users could benefit.
It does not help either that Emacs is not responding while searching.

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > I added a screenshot of what such an interface might look like (which
  > >   > is better than words).  https://justpaste.it/fdau4.
  > >
  > > That site seems to depend on nonfree Javascript code.  Those of us who
  > > block nonfree Javascript. or block Javascript entirely, cannot see
  > > whatever you meant to show us.

  > The website works entirely without JavaScript.

I just tried it again and verified that LibreJS reported blocked scripts.
(They are blocked for not being labeled with a free liecense.

  > But there you go:
  > https://jpcdn.it/img/bde00610157f1ad327d8d066d5bc1744.png

Thank you, I will now look at that...

[viewed it]

This image looks similar to an image that I saw a few days ago in
another email.  I found its meaning unclear, and reported how so.

  > The configure interface looks at times very old. I.e. in context of the
  > search it is very hard to see what the results actually are

I agree.  It could definitely use improvement, and your idea may have
potential for that -- if you explain it more concretely.

                                                              yes it does
  > show categories and settings items but it doesn't not show where they
  > are from e.g. as in which catergory a item is from

Could you show one example of that deficiency, and point out precisely
where it is and say what is missing?  With that help, I would understand
what you mean.

Since the customization buffer contains ordinary text, you can copy it
into an email -- avoiding the inconvenience of image files.

                                                       or what tags it could
  > have.

Could you explain what you mean my "tags"?  I am mot sure.

If you use the same example, pick one option, and say what
the missing tags would say, I might understand your idea.

  > It does not help either that Emacs is not responding while searching.

Could yoi explain more concretely what operation you mean here?
What is the command for searching which fails to respond?

If you use the same example, and say (as in the Emacs manua) exectly
what you type to do the sort of search that is nonresponsive,
it will be completely clear.


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >   > I added a screenshot of what such an interface might look like (which
>   > >   > is better than words).  https://justpaste.it/fdau4.
>   > >
>   > > That site seems to depend on nonfree Javascript code.  Those of us who
>   > > block nonfree Javascript. or block Javascript entirely, cannot see
>   > > whatever you meant to show us.
>
>   > The website works entirely without JavaScript.
>
> I just tried it again and verified that LibreJS reported blocked scripts.
> (They are blocked for not being labeled with a free liecense.
>

The website loads without JS if you encounter such an issue try loading
without JS. Why do you keep talking about the JavaScript which you don't
like to load?

>   > But there you go:
>   > https://jpcdn.it/img/bde00610157f1ad327d8d066d5bc1744.png
>
> Thank you, I will now look at that...
>
> [viewed it]
>
> This image looks similar to an image that I saw a few days ago in
> another email.  I found its meaning unclear, and reported how so.
>
>   > The configure interface looks at times very old. I.e. in context of the
>   > search it is very hard to see what the results actually are
>
> I agree.  It could definitely use improvement, and your idea may have
> potential for that -- if you explain it more concretely.
>
>                                                               yes it does
>   > show categories and settings items but it doesn't not show where they
>   > are from e.g. as in which catergory a item is from
>
> Could you show one example of that deficiency, and point out precisely
> where it is and say what is missing?  With that help, I would understand
> what you mean.
>

As stated item i.e. customization options don't contain context from
where .i.e which group they are from. Just compare the mockup posted by
the op and the output of customizes search function.

> Since the customization buffer contains ordinary text, you can copy it
> into an email -- avoiding the inconvenience of image files.

The does not preserve the exact output of the person reporting an issue.
For issues which are partially or mostly visual in nature ordinary text
is not an option that's why markup or image files exist.


>                                                       or what tags it could
>   > have.
>
> Could you explain what you mean my "tags"?  I am mot sure.

Tags are just plain the meaning of the word English word tag, not
confused with Tag the German word for day. E.g. The group Gnus
could have the tag news, mail or rss.

> If you use the same example, pick one option, and say what
> the missing tags would say, I might understand your idea.

Customs search doesn't use tags which is what I wated to point out.

>   > It does not help either that Emacs is not responding while searching.
>
> Could yoi explain more concretely what operation you mean here?
> What is the command for searching which fails to respond?
>
> If you use the same example, and say (as in the Emacs manua) exectly
> what you type to do the sort of search that is nonresponsive,
> it will be completely clear.

Emacs does not respond to user input while searching.
So for example the user opens custom, enters a word and presses search.

RE: [External] : Re: A new filter-based customization interface

[Drew Adams]

(Caveat: I'm not following this thread.)

> As stated item i.e. customization options don't contain context from
> where .i.e which group they are from. Just compare the mockup posted by
> the op and the output of customizes search function.

Not sure what you mean.

A `customize-option' buffer does have, as its
last line, a list of its custom `Groups:', and
the group names are links to `customize-group'.

OTOT, it's true that `C-h v' for an option
doesn't say which custom groups the option
belongs to.  Perhaps that info should be
provided there.
 
> Customs search doesn't use tags which is what I wated to point out.

True.  And Emacs itself doesn't provide tags as
a _general_ feature, AFAIK.  IIUC, you can use
tags with Org and with Gnus, but those tags are
Org- and Gnus-specific.  (I don't use Gnus, and
I don't use Org much, so I can't speak with any
authority about their tags.)

The most generally usable tags, AFAIK, are the
bookmark tags you can create with Bookmark+.
Very general and flexible.  Since you can, in
effect, bookmark pretty much anything, you can
pretty much tag anything.

You can of course search for things using their
tags.  In particular, you can search for complex
combinations of tags (Boolean combinations of
tag-name or tag-value matches for patterns,
including regexps, etc.)

But yeah, you need to bookmark something to tag
it, and you use bookmark commands etc. to make
use of the tags.  So this too is not a completely
generally tag facility.

Bookmark tags define bookmark sets. A bookmark
can have any number of tags, and multiple bookmarks
can have the same tag.  You can sort, show/hide,
or mark bookmarks based on their tags.

Bookmark tags can be more than just names. They
can be full-fledged user-defined attributes, with
EmacsLisp objects as their values.

It would be possible to bookmark, and thus tag,
*Customize* buffers or *Help* buffers for user
options.
___


If interested, see here:

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkTags

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkTagSets

https://www.emacswiki.org/emacs/BookmarkPlus#TaggingFiles

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkFilesForBookmarkswithSpecificTags

https://www.emacswiki.org/emacs/BookmarkPlus#TagCommandsAndKeys


https://www.emacswiki.org/emacs/BookmarkPlus#TagsAsAttributes


> 
> >   > It does not help either that Emacs is not responding while
> searching.
> >
> > Could yoi explain more concretely what operation you mean here?
> > What is the command for searching which fails to respond?
> >
> > If you use the same example, and say (as in the Emacs manua) exectly
> > what you type to do the sort of search that is nonresponsive,
> > it will be completely clear.
> 
> Emacs does not respond to user input while searching.
> So for example the user opens custom, enters a word and presses search.

Re: [External] : Re: A new filter-based customization interface

[Björn Bidar]

Drew Adams <drew.adams@oracle.com> writes:

> (Caveat: I'm not following this thread.)
>
>> As stated item i.e. customization options don't contain context from
>> where .i.e which group they are from. Just compare the mockup posted by
>> the op and the output of customizes search function.
>
> Not sure what you mean.
>
> A `customize-option' buffer does have, as its
> last line, a list of its custom `Groups:', and
> the group names are links to `customize-group'.

If you search something that could match a word in multiple customize
options such as name or address their is now indicator where each option
(what I called item before) comes from.

E.g. for example you search for -name

Currently the result looks like this:

<option>
<option description>

<option>
<option description>

<option>
<option description>

Basically just listing all the customs options matching the term you
entered which you can change here and there but there's no grouping
after where each option is from.

E.g. something like this:

<group option belongs to>

<option belonging to group>
<option description>


<another option belonging to group>
<option description>

Then repeat and repeat depending how many options have been returned and
to how many different customize groups they belong to.

>
> OTOT, it's true that `C-h v' for an option
> doesn't say which custom groups the option
> belongs to.  Perhaps that info should be
> provided there.

I wasn't talking about that one but it could help of too to add the
group there.

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > >   > I added a screenshot of what such an interface might look like (which
  > >   > >   > is better than words).  https://justpaste.it/fdau4.
  > >   > >
  > >   > > That site seems to depend on nonfree Javascript code.  Those of us who
  > >   > > block nonfree Javascript. or block Javascript entirely, cannot see
  > >   > > whatever you meant to show us.
  > >
  > >   > The website works entirely without JavaScript.
  > >
  > > I just tried it again and verified that LibreJS reported blocked scripts.
  > > (They are blocked for not being labeled with a free liecense.
  > >

  > The website loads without JS if you encounter such an issue try loading
  > without JS.

I am not sure what that concretely means.

What exactly do you man by "loading without JS">

I _normally_ disable nonfree JS, by using LibreJS.  Are you trying to
say that the site fails with LibreJS but would work properly if I were
to disable JavaScrpt 100% instead?

If the site works that way, it is a pain in the neck, but it can
be fixed.

                Why do you keep talking about the JavaScript which you don't
  > like to load?

That sentence seems to stretch words which are not contradictory so as
to accuse them of being contradictory.

Please don't do that.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > >   > >   > I added a screenshot of what such an interface might look like (which
>   > >   > >   > is better than words).  https://justpaste.it/fdau4.
>   > >   > >
>   > >   > > That site seems to depend on nonfree Javascript code.  Those of us who
>   > >   > > block nonfree Javascript. or block Javascript entirely, cannot see
>   > >   > > whatever you meant to show us.
>   > >
>   > >   > The website works entirely without JavaScript.
>   > >
>   > > I just tried it again and verified that LibreJS reported blocked scripts.
>   > > (They are blocked for not being labeled with a free liecense.
>   > >
>
>   > The website loads without JS if you encounter such an issue try loading
>   > without JS.
>
> I am not sure what that concretely means.
>
> What exactly do you man by "loading without JS">

By blocking JavaScript entirely for that website, i.e. not advertise
that the browser supports it. Browser extensions such NoScript can do
this.


> I _normally_ disable nonfree JS, by using LibreJS.  Are you trying to
> say that the site fails with LibreJS but would work properly if I were
> to disable JavaScrpt 100% instead?

I this context it should work properly but not in all websites. Sometime
websites have fallbacks for users who disable JavaScript completely for
their own personal reasons, for accessibility or to be compatible witn
legacy browsers. 

> If the site works that way, it is a pain in the neck, but it can
> be fixed.
>
>   > Why do you keep talking about the JavaScript which you don't
>   > like to load?
>
> That sentence seems to stretch words which are not contradictory so as
> to accuse them of being contradictory.

You continued to talk about JavaScript when I told you how you can avoid
it in this context (and possibly) others entirely.

I don't agree with that point. But to make it clear to avoid any
misunderstandings this is not a personal attack, I wrote you because in
this context I was specifically talked to you.

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > >   > Why do you keep talking about the JavaScript which you don't
  > >   > like to load?
  > >
  > > That sentence seems to stretch words which are not contradictory so as
  > > to accuse them of being contradictory.

  > You continued to talk about JavaScript when I told you how you can avoid
  > it in this context (and possibly) others entirely.

It did not occur to me that you meant "Running with JS disabled
entirely will work, but running with JS active will not."  That is
an unusual situation so I did not imagine it.

If you had stated it carefully and clearly, you could have made it
understandable.

Instead of reprimanding people who do not get the meaning you
intended, please put more effort into stating your point concretely
and clearly.

  > > I _normally_ disable nonfree JS, by using LibreJS.  Are you trying to
  > > say that the site fails with LibreJS but would work properly if I were
  > > to disable JavaScrpt 100% instead?

  > I this context it should work properly but not in all websites. Sometime
  > websites have fallbacks for users who disable JavaScript completely for
  > their own personal reasons, for accessibility or to be compatible witn
  > legacy browsers. 

It is natural and inevitable that there are sites, with freely
licensed JS code, that will work if LibreJS is running but not if JS
is simply disabled.  We can't avoid that; that possibility is part
of the plan.

The existence of sites that do the opposite -- they work properly if
JS is disabled entirely but will not work with LibreJS - is not
inevitabkle.  But those sites create a perverse situation for the
users.  It means there is no one way of avoiding nonfree JavaScript
that works for all the sites that could in principle do this.  So the
that users need to remember that "For sites A, C, G and Q, you must
disable JavaScript.  For sites B, F, J and Z, you must use LibreJS."

That is inconvenient for users.

To avoid that kind of inconvenience, the community should ensure that
one of those two approaches (LibreJS, or disabling JS entirely)
dominates the other in terms of which sites it supports.

To give the users this simpler convenience, the sites which currently
work without nonfree software if JS is disabled, but do not do so with
LibreJS, ought to be changed so that their special hacks for disabled
JS also detect LibreJS active.

I think that can be done in JavaScript code by means of a conditional
which s described in
https://gnu.org/software/librejs/free-your-javascript.html.  Is it
there?

If you know of such a site, please do not tell people here that we
ought to remember to use that site by totally disabling JS.  Instead,
please utrge the developers of that site to use a condiional that will
detect both cases, and treat the browser-uses-LibreJS cae the same way
it now handles JS-deactivated.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > Even worse, there are people on the lis who do not block nonfree
  > > Javascript in their browsers.  By referring to that site, you are
  > > promoting the use of nonfree software!  And, in the process,
  > > legitimizing the use and distrbution of nonfree software -- which is
  > > the direct opposite of the goal of GNU.

  > People promote non-free software all the on this list e.g. with
  > @gmail in their addresses or talk about non-free operating systems.
  > There's even a package solely to support non-free software in Elpa.

I think we are miscommunicating.  Promoting nonfree software, in the
GNU Project, is much more specific than you envision.  It means urging
users to do something (now, or later) in a way that involves _their_
running nonfree software.  If you tell people to look at that page on
https://justpaste.it/, you're directing _them_ to run its nonfree
Javascript code.

Just talking about some nonfree software is not promoting it unless
you encourage or direct people to use it.  For instance, mentioning
Windows or MacOS as part of making GNU Emacs run on them, or saying
that it does, is not promoting those systems.  Sending mail that says
it is from gmail doesn't direct other people to use gmail -- they can
receive that message using any email facility.

Please read the node References in the GNU Coding Standards for
explanation of this concept.  With that explanation you'll understand
what this issue is about.

  > There's even a package solely to support non-free software in Elpa.

That _might_ be promoting nonfree software, or might not, depending on
details of what that package does.  Perhaos it mainly encourages
people who use that nonfree software to use Emacs with it.  That is a
good thing to do.

I would like to take a look at it and see what it does.
What is its name?


-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Björn Bidar]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > Even worse, there are people on the lis who do not block nonfree
>   > > Javascript in their browsers.  By referring to that site, you are
>   > > promoting the use of nonfree software!  And, in the process,
>   > > legitimizing the use and distrbution of nonfree software -- which is
>   > > the direct opposite of the goal of GNU.
>
>   > People promote non-free software all the on this list e.g. with
>   > @gmail in their addresses or talk about non-free operating systems.
>   > There's even a package solely to support non-free software in Elpa.
>
> I think we are miscommunicating.  Promoting nonfree software, in the
> GNU Project, is much more specific than you envision.  It means urging
> users to do something (now, or later) in a way that involves _their_
> running nonfree software.  If you tell people to look at that page on
> https://justpaste.it/, you're directing _them_ to run its nonfree
> Javascript code.

You don't have to load the nono-free JavaScript if you open such a
website.
Disabling JavaScript when opening a website containing non-free is the
best option I think.
I get it's a however If a user sends mail from a non-free service such
as Gmail it makes most users send data to these kinds of companies.
But is something we can't avoid, the comparison doesn't exactly hold up
I get that now.

> Just talking about some nonfree software is not promoting it unless
> you encourage or direct people to use it.  For instance, mentioning
> Windows or MacOS as part of making GNU Emacs run on them, or saying
> that it does, is not promoting those systems.  Sending mail that says
> it is from gmail doesn't direct other people to use gmail -- they can
> receive that message using any email facility.
>
> Please read the node References in the GNU Coding Standards for
> explanation of this concept.  With that explanation you'll understand
> what this issue is about.
>
>   > There's even a package solely to support non-free software in Elpa.
>
> That _might_ be promoting nonfree software, or might not, depending on
> details of what that package does.  Perhaos it mainly encourages
> people who use that nonfree software to use Emacs with it.  That is a
> good thing to do.

At time the limit of inclusion of such software or specific vendor
dialect of existing standards such as OAuth2 was frowned upon.
To me what you describe sounds similar to support i.e. Microsoft
specific dialects of OAuth2.

> I would like to take a look at it and see what it does.
> What is its name?

The name is excorporate.

Re: A new filter-based customization interface

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > I would like to take a look at it and see what it does.
  > > What is its name?

  > The name is excorporate.

Thanks.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: A new filter-based customization interface

[Moakt Temporary Email]

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

Re: A new filter-based customization interface

[Eli Zaretskii]

> Date: Mon, 13 Jan 2025 23:39:01 +0000
> From: Moakt Temporary Email <a01158486246@drmail.in>
> 
> > 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 ?

I think we should first come up with a reasonable set of groups, and
deal with the backward compatibility issues afterwards.  One almost
trivial possibility is to _add_ new groups instead of renaming the old
ones, so that backward compatibility is preserved (an option can
belong to more than a single group).  And there are possibly other
ways to solve the compatibility problem.

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

It is true that coming up with a good set of groups is a significant
task.  But the advantage is that the Customize interface has all the
rest already solved: a rich, graphical interface that is capable of
customizing complex options, including built-in access to
documentation and Help, etc.  This will save a lot of work that will
otherwise need to be invested for starting the UI from scratch.

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

Each customizable user option already has a group tag.  We just need
to change them (or add new groups) so that users could customize a
group of options that they are interested in.

Having large groups is indeed a danger, but we are already there: we
currently have a small number of very general groups, each group very
large.  We can make this better by using sub-groups (which are also
already supported).  Later, we could introduce a feature whereby users
could request to see options that are the intersection of several
groups, i.e. they belong to several groups at once.  We could also add
more features that could allow finding the options easier.

My point is that if we go that way, a lot of the necessary
infrastructure already exists and is well documented.  We use it all
the time when adding new options.  This is a good system, it's just
that its categorization needs to be improved.

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

No one in their right minds navigates the entire tree of Emacs
customization groups.  Neither are they supposed to.  They should be
able to start from the group that suits their needs.  Coming up with a
good set of customization groups will actually allow that.

> What about adding the packages ?

Each package comes with its own customizable options, and those should
also have groups defined for them.

> The actual interface does not show the options of unavailable packages.

That's true.  But again, we can add that in the future.  The problem
here is to have a place from which to fetch the data, and that problem
will exist no matter what method and UI you will choose.

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

We already have an interface to package archives (M-x list-packages),
and we could build on that to help people find packages in a more
refined way.

RE: [External] : Re: A new filter-based customization interface

[Drew Adams]

(Caveat: Not following this thread.)

Don't forget `customize-apropos-groups'.
And a given thing can belong to more than
one custom group.

Maybe take those things into account, for
whatever you're cooking up.

Especially if you're interested in enhancing
discoverability.  The assignment of something
to a group or groups isn't always done well,
unfortunately, and even when done well there
are often other equally good group choices
that don't get made.  So it can be iffy to
guess what group(s) something is in.

A user might think in terms of a different
group than whatever actually was assigned to 
something.  Discoverability is helped when
you can use different terms to find something.

(Predefined categories of groups have the
same problem - different people can think
differently when trying to find something.)

RE: [External] : Re: A new filter-based customization interface

[Ihor Radchenko]

Drew Adams <drew.adams@oracle.com> writes:

> A user might think in terms of a different
> group than whatever actually was assigned to 
> something.  Discoverability is helped when
> you can use different terms to find something.
>
> (Predefined categories of groups have the
> same problem - different people can think
> differently when trying to find something.)

Some kind of group aliases may help then.
Both centralized (to cover more people thinking differently) and local,
customized by users.

-- 
Ihor Radchenko // yantar92,
Org mode maintainer,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>