From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: 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?)) Date: Sun, 22 Dec 2024 20:54:48 +0200 Message-ID: <86frmf5z0n.fsf@gnu.org> References: <8734m28l9a.fsf@gmail.com> <87zfm4s50x.fsf@localhost> <87wmh8s358.fsf@localhost> <87y11nwp9z.fsf@gmail.com> <87v7wd9a2h.fsf@localhost> <878qt7fbki.fsf@gmail.com> <87o71jwdxz.fsf@localhost> <87wmg6edr0.fsf@gmail.com> <87msgzh1dh.fsf@localhost> <87v7vn12tp.fsf@ASCALON.mail-host-address-is-not-set> <878qsifufe.fsf@localhost> <87y10fcy4e.fsf@localhost> <87cyhpclns.fsf@bernoul.li> <877c7v7dbn.fsf@localhost> <87cyhk9icj.fsf@localhost> <86y1076h23.fsf@gnu.org> <87cyhj7faz.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2033"; mail-complaints-to="usenet@ciao.gmane.io" Cc: rms@gnu.org, jonas@bernoul.li, samologist@gmail.com, emacs-devel@gnu.org, karthikchikmagalur@gmail.com, visuweshm@gmail.com, raman@google.com To: Ihor Radchenko Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Dec 22 19:55:47 2024 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tPR7D-0000MD-LW for ged-emacs-devel@m.gmane-mx.org; Sun, 22 Dec 2024 19:55:47 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tPR6Y-0007Ug-6H; Sun, 22 Dec 2024 13:55:06 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPR6W-0007T9-6I for emacs-devel@gnu.org; Sun, 22 Dec 2024 13:55:04 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tPR6T-0007lv-JT; Sun, 22 Dec 2024 13:55:01 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8NYizuVa/oVrGXsmFPlQ+UEPR3GVc+Oh9heKDQTuOKY=; b=n4Z7duK4Ne9T /TMKv7Co8PY3ui/zdOBZyrvvt9r7rfuriGiwHxucCkp/0bZyPGfl5F73O7alVeDw+ZpqcdmZeqdTz XoH7xVqqwT9NxNy0KfISBpCMWZSirlIl983Gm45aPluboIHSQm+CMm+zeGgNGSCPow0VwR7aptCkL d9zF87E/mpw/xhTBXTDQB6D3llz4Nrd1jS9uLuWxliQqF/hQOYnE+z9WdWbfuWAAiosVwVIR3eaqb zHLvoAn0rguY6qeA4D/xSq4rdzQ7IHK4ju5wjqDwqLXk1vXl9wL3Z7ZRv9ktde6IpXpFQ1qZBvKG4 thChclkTfh1rME7H+SfWLw==; In-Reply-To: <87cyhj7faz.fsf@localhost> (message from Ihor Radchenko on Sun, 22 Dec 2024 18:17:40 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:326878 Archived-At: > From: Ihor Radchenko > Cc: rms@gnu.org, jonas@bernoul.li, samologist@gmail.com, > emacs-devel@gnu.org, karthikchikmagalur@gmail.com, visuweshm@gmail.com, > raman@google.com > Date: Sun, 22 Dec 2024 18:17:40 +0000 > > Eli Zaretskii writes: > > >> ... I meant support and maintenance in Emacs > >> core. IMHO, these features are too important for third-party package that > >> might be abandoned. > >> ... > > > > We do want to have accessibility features in Emacs, if that is what > > you are asking. (In some cases we already do: e.g., see the > > Windows-specific variable w32-use-visible-system-caret, which aims > > specifically at aiding screen-reading software.) > > Thanks for the clarification. Then, let me expand on the idea I have. > > I imagine adding "alternative" default value to `defcustom': > > (defcustom variable default-value > :alt-default > (("blind" . value2) > ("large-fonts" . value3)) > ...) > > Then, consider custom options like > > (defcustom accessibility-blind nil > "When non-nil, Emacs will use defaults suitable for blind users.") > (defcustom accessibility-large-fonts nil > "When non-nil, Emacs will use defaults suitable for large font sizes.") > > If any of the above options is non-nil, and custom variable has its > default value (not changed by user explicitly), instead of > "default-value" a suitable alternative value is used. > > Third-party packages will also be able to make use of this semantics, > providing better defaults if necessary. > > Elisp manual should also encourage package authors to keep these > alternatives in mind. > > WDYT? 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. (We had a similar problem long ago, when TTY frames learned to display colors, back when they only supported 8 colors. Originally, the idea was that each face will have a separate definition for TTYs, but this idea crashed and burned very fast, and instead we added transparent conversion of X colors to TTY colors, see tty-colors.el.) If you mean something else, please explain how (via which mechanisms) will accessibility-* options affect Emacs, once turned on. 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. 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.