Systematic implicit aliases for option variables

Systematic implicit aliases for option variables

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

`occur' is an alias for the command `list-matching-lines'.
`occur' may be used by more people than `list-matching-lines'.

There are options named `list-matching-lines-*', but people who know
the command as `occur' may not think to look for options with those
names.

Does it make sense to define a command `customize-command' which takes
a command name as argument and shows you the options that are
pertinent to customizing that command?

If you give it `occur', it would recognize that that is an alias
for `list-matching-lines', and show you the options pertinent to
`list-matching-lines'.  You wouldn't need to know that `occur'
is an alias.

I think the hard part of this would be adding a data base to find the
custom groups that are pertinent to any particular command.

-- 
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: Systematic implicit aliases for option variables

[Eli Zaretskii]

On March 1, 2022 6:24:49 AM GMT+02:00, Richard Stallman <rms@gnu.org> wrote:
> 
> Does it make sense to define a command `customize-command' which takes
> a command name as argument and shows you the options that are
> pertinent to customizing that command?
> 
> If you give it `occur', it would recognize that that is an alias
> for `list-matching-lines', and show you the options pertinent to
> `list-matching-lines'.  You wouldn't need to know that `occur'
> is an alias.
> 
> I think the hard part of this would be adding a data base to find the
> custom groups that are pertinent to any particular command.
> 

Sounds like a natural extension of customize-apropos, which we already have?

RE: [External] : Systematic implicit aliases for option variables

[Drew Adams]

> `occur' is an alias for the command `list-matching-lines'.
> `occur' may be used by more people than `list-matching-lines'.

Definitely.  Just as more users might think
of `flush-lines' and `keep-lines' than
`delete-matching-lines' and
`delete-non-matching-lines'.

> There are options named `list-matching-lines-*', but people who know
> the command as `occur' may not think to look for options with those
> names.
> 
> Does it make sense to define a command `customize-command' which takes
> a command name as argument and shows you the options that are
> pertinent to customizing that command?

Not sure.  The options relevant for some
commands can be diverse.

Also, is this only relevance for "customizing
that command", by which I guess you mean
options that change its behavior?  Or does it
include relevance in other senses?

> If you give it `occur', it would recognize that that is an alias
> for `list-matching-lines', and show you the options pertinent to
> `list-matching-lines'.  You wouldn't need to know that `occur'
> is an alias.

That would come for free, I think, if we just
aliased those options (like we do the commands),
to let users see them also/alternatively as
"occur" options: use prefix `occur-' for aliases
of options that have prefix `list-matching-lines'.

This would help users find and access such things.
It leverages existing search, apropos, completion,
and other help aids (ways to "ask Emacs").

See also: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54157

> I think the hard part of this would be adding a data base to find the
> custom groups that are pertinent to any particular command.

Dunno.  If this is (only) about options that
change the behavior of a command then the option
doc strings will often mention the command(s)
they affect.

In that case, `apropos-doc' tells us which
options affect which commands.

And it can sometimes provide info about
potential aliasing.  For example,
`M-x apropos-doc list-matching-lines' shows
that the doc of command `occur' mentions option
`list-matching-lines-default-context-lines'.

Re: Systematic implicit aliases for option variables

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

  > > If you give it `occur', it would recognize that that is an alias
  > > for `list-matching-lines', and show you the options pertinent to
  > > `list-matching-lines'.  You wouldn't need to know that `occur'
  > > is an alias.
  > > 
  > > I think the hard part of this would be adding a data base to find the
  > > custom groups that are pertinent to any particular command.
  > > 

  > Sounds like a natural extension of customize-apropos, which we already have?

Could you explain how it relates to customize-apropos?  That selects
options purely on their names -- the feature I request would select
them based on semantics.

-- 
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: Systematic implicit aliases for option variables

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Tue, 01 Mar 2022 23:46:51 -0500
> 
>   > > If you give it `occur', it would recognize that that is an alias
>   > > for `list-matching-lines', and show you the options pertinent to
>   > > `list-matching-lines'.  You wouldn't need to know that `occur'
>   > > is an alias.
>   > > 
>   > > I think the hard part of this would be adding a data base to find the
>   > > custom groups that are pertinent to any particular command.
>   > > 
> 
>   > Sounds like a natural extension of customize-apropos, which we already have?
> 
> Could you explain how it relates to customize-apropos?  That selects
> options purely on their names -- the feature I request would select
> them based on semantics.

Yes, it currently only considers names.  The idea is to extend it
consider aliases as well.  For example, for each symbol it finds by
name, it could attempt to find its alias(es), and if found, show the
symbols related to those aliases as well.  Similar to what you
suggested, but without a new command.

Re: [External] : Systematic implicit aliases for option variables

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

  > That would come for free, I think, if we just
  > aliased those options (like we do the commands),
  > to let users see them also/alternatively as
  > "occur" options: use prefix `occur-' for aliases
  > of options that have prefix `list-matching-lines'.

Yes, that would work.  But it would mean storing equivalent data in
multiple forms, which could get out of synch.  If we could make
customize take note of the fact that `occur' is an alias, we would
not have to make lots of secondary aliases too.


-- 
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: Systematic implicit aliases for option variables

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

  > Yes, it currently only considers names.  The idea is to extend it
  > consider aliases as well.  For example, for each symbol it finds by
  > name, it could attempt to find its alias(es), and if found, show the
  > symbols related to those aliases as well.  Similar to what you
  > suggested, but without a new command.

It's worth a try.  It doesn't do the whole job I had in mind,
but it might do enough to solve this problem.

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