From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: Possible change to startup.el Date: Sun, 17 Apr 2005 11:31:41 +0200 Message-ID: <85mzrxg35u.fsf@gnu.org> References: <87fyy3hvxl.fsf@jurta.org> <01c53c28$Blat.v2.4$1bd305e0@zahav.net.il> <87k6ndkv98.fsf@jurta.org> <01c53cda$Blat.v2.4$4eb132e0@zahav.net.il> <85is2q5iwl.fsf@gnu.org> <85ll7l0vxm.fsf@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1113730223 19468 80.91.229.2 (17 Apr 2005 09:30:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sun, 17 Apr 2005 09:30:23 +0000 (UTC) Cc: juri@jurta.org, eliz@gnu.org, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Apr 17 11:30:20 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DN66e-0004xL-9b for ged-emacs-devel@m.gmane.org; Sun, 17 Apr 2005 11:30:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DN6AW-0004GV-Np for ged-emacs-devel@m.gmane.org; Sun, 17 Apr 2005 05:34:20 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DN6AJ-0004G3-3z for emacs-devel@gnu.org; Sun, 17 Apr 2005 05:34:07 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DN6AH-0004Fb-Sy for emacs-devel@gnu.org; Sun, 17 Apr 2005 05:34:06 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DN6AH-0004Eb-5t for emacs-devel@gnu.org; Sun, 17 Apr 2005 05:34:05 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DN69V-0007FF-7M for emacs-devel@gnu.org; Sun, 17 Apr 2005 05:33:17 -0400 Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DN67p-0003W9-Up; Sun, 17 Apr 2005 05:31:34 -0400 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat, 16 Apr 2005 21:49:52 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:36049 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36049 [proposal was IIRC:] (menu-string-displayable-p STRING &optional DISPLAY) Richard Stallman writes: > For example, AUCTeX has an option that will enable the use of Unicode > math characters in menus. How can I know when to enable it by > default? I need to know for every platform that Emacs might be > running on, and this might even depend on your settings for the menu > font and the locale. > > The interface that has been proposed is defined so as to make > complete informatoin available about what is or isn't supported. > That makes it so complex to implement--to complex to be considered > for now, and undesirable even for later. I can't quite see why having complete information about what is or isn't supported would be undesirable for later. As an application developer, I'd rather consider it desirable. It seems reasonable to solve this task once, within Emacs. > AUCTeX needs *some* information. Could it be satisfied with less? > What is the minimum, simplest, information that could be enough? Well, we can omit the "technicality" of actually installed fonts: it would be sufficient to know whether a given string could be mapped to the toolkit _if_ the fonts were available (this will be an incentive to people to actually install fonts _if_ they could be made to work). I can't see how one could get along with different call semantics, though: different displays may have different toolkits at least on the upcoming multi-tty (like being on the tty and on x11), so it would seem silly not to provide the DISPLAY option, and the various unifying modes mean that we can't really give a definite decision when only knowing about the charset instead of the actual characters in STRING. As an intermediate version, something based on the charset/display combination instead of the character/display combination would help a lot already, and since charsets are not strings, one could later make the function accept a string, too, or just a single character (in Emacs encoding?). -- David Kastrup, Kriemhildstr. 15, 44793 Bochum