Re: Alternative defaults for visually impaired users? (was: [RFC] The best way to choose an "action" at point: context-menu-mode, transient, which-key or embark? (was: Fwd: Org-cite: Replace basic follow-processor with transient menu?))

[Eli Zaretskii <eliz@gnu.org>]

> From: Ihor Radchenko <yantar92@posteo.net>
> Cc: rms@gnu.org, jonas@bernoul.li, samologist@gmail.com,
>  emacs-devel@gnu.org, karthikchikmagalur@gmail.com, visuweshm@gmail.com,
>  raman@google.com
> Date: Mon, 23 Dec 2024 08:28:03 +0000
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I imagine adding "alternative" default value to `defcustom':
> >> 
> >> (defcustom variable default-value
> >>   :alt-default
> >>     (("blind" . value2)
> >>      ("large-fonts" . value3))
> >>   ...)
> >> ...
> >
> > If this means that, for example, each face and defcustom we define
> > will need to have such alternatives defined in advance, I think it's a
> > non-starter.  People will forget to define those, and having such a
> > definition for each face/defcustom is extremely inconvenient and hard
> > to maintain.
> 
> I believe that only a small subset of options/faces will need to specify
> the alternative defaults. Why do you think that _each_ face/defcustom
> will require that?

Because each face can appear on display, and we want all of them to be
visible.

Or maybe I'm missing something: why do you think only a small subset
of faces and options will need to have special defaults?

> > What I think we need is some infrastructure which will automatically
> > react to a setting from the accessibility set.  For "large fonts",
> > this is almost trivial, but other settings might be harder.
> 
> I doubt that such _universal_ infrastructure that will not require
> manual intervention can exist wrt Emacs options. Maybe for faces. But
> 100% not for user options.

If we agree that this is reasonable for faces, we should be able to do
that already.

As for user options, we should first have an idea what kind of options
will need to be affected.  If you know, please tell.  Then we can
discuss what needs to be done about them, and then we could see if
some mechanism will be needed or will be useful.

> > Perhaps a useful first step would be for someone to see what other
> > systems and applications offer in this department, and post the
> > findings.  Then we could discuss how to incorporate the relevant parts
> > into Emacs.
> 
> I CCed Samuel and Raman because they probably know best about
> Emacs-specific customization and maybe also about other apps.

Thanks.