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: Fri, 15 Apr 2005 01:40:05 +0200 Message-ID: <85ll7l0vxm.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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1113522360 11092 80.91.229.2 (14 Apr 2005 23:46:00 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 14 Apr 2005 23:46:00 +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 Fri Apr 15 01:45:58 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1DME1o-00005Q-3M for ged-emacs-devel@m.gmane.org; Fri, 15 Apr 2005 01:45:44 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DME5C-0008QC-7c for ged-emacs-devel@m.gmane.org; Thu, 14 Apr 2005 19:49:14 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1DME2m-0007kD-Sm for emacs-devel@gnu.org; Thu, 14 Apr 2005 19:46:44 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1DME2i-0007hk-CQ for emacs-devel@gnu.org; Thu, 14 Apr 2005 19:46:40 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1DME2i-0007gZ-4F for emacs-devel@gnu.org; Thu, 14 Apr 2005 19:46:40 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.34) id 1DME2Q-0007x6-Iz for emacs-devel@gnu.org; Thu, 14 Apr 2005 19:46:22 -0400 Original-Received: from localhost ([127.0.0.1] helo=localhost.localdomain) by fencepost.gnu.org with esmtp (Exim 4.34) id 1DME1J-0004rE-Bt; Thu, 14 Apr 2005 19:45:13 -0400 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Thu, 14 Apr 2005 15:03:40 -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:36000 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:36000 Richard Stallman writes: > > Until multi-language menus are supported, perhaps we should > > change the menu item to say > > > > Emacs Tutorial (in YOUR-LANGUAGE) > > > > where YOUR-LANGUAGE stands for the language name. This should > > be done only for those languages that indeed have a translated > > tutorial. The tooltip should also hint about that. > > I think we should do that only for those languages that can't be > shown in the menu. Since this depends on a complex interaction > of platform, fonts and locales, I think the programmer wanting > to put something into a menu can't be reasonably expected to > make a guess. > > So I think that we should add something like > (defun menu-string-supported-p STRING &optional DISPLAY) > that will tell a programmer whether a given platform is supposed to > be able to display a given string. > > This might be ok in theory, but I'd rather do something simpler. It is a reoccuring problem, and it will become more prevalent in future. 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 necessary knowledge when to enable this option and when not is so complicated to gather that we should provide an interface that reflects our current wisdom. The proposed interface has the advantage that it is easy to use in my opinion (though I'll be glad to hear something simpler). Of course it is not simple to implement, but the reason for that is that the task _is_ not simple, and it makes sense to solve it once in Emacs instead of anew for every application. If you have an idea that is also simpler to _use_, I'll be glad to hear about it. -- David Kastrup, Kriemhildstr. 15, 44793 Bochum