From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dan Nicolaescu Newsgroups: gmane.emacs.devel Subject: Re: observations for ns*.m files (Re: Emacs.app merged) Date: Mon, 28 Jul 2008 07:35:54 -0700 Message-ID: <200807281435.m6SEZsh0014380@sallyv1.ics.uci.edu> References: <1C66F1FC-BF82-4365-944D-ADCC4D1F435C@gmail.com> <200807272218.m6RMIIGA007577@sallyv1.ics.uci.edu> <16EE24C1-291C-4148-90F2-C249F612EFB2@gmail.com> <200807280258.m6S2wQmW021098@sallyv1.ics.uci.edu> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1217255786 21903 80.91.229.12 (28 Jul 2008 14:36:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2008 14:36:26 +0000 (UTC) Cc: emacs- devel To: Adrian Robert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 16:37:15 2008 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1KNTqc-0001hQ-0S for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2008 16:37:14 +0200 Original-Received: from localhost ([127.0.0.1]:49384 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNTph-0000my-Sz for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2008 10:36:17 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNTpc-0000mt-UW for emacs-devel@gnu.org; Mon, 28 Jul 2008 10:36:12 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNTpa-0000mE-WE for emacs-devel@gnu.org; Mon, 28 Jul 2008 10:36:11 -0400 Original-Received: from [199.232.76.173] (port=54451 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNTpa-0000mB-RP for emacs-devel@gnu.org; Mon, 28 Jul 2008 10:36:10 -0400 Original-Received: from sallyv1.ics.uci.edu ([128.195.1.109]:46592) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA1:24) (Exim 4.60) (envelope-from ) id 1KNTpa-0002Dn-FG for emacs-devel@gnu.org; Mon, 28 Jul 2008 10:36:10 -0400 X-ICS-MailScanner-Watermark: 1217860555.23333@IdFoLTnRzpIdr1a4gpkJZA Original-Received: from mothra.ics.uci.edu (mothra.ics.uci.edu [128.195.6.93]) by sallyv1.ics.uci.edu (8.13.7+Sun/8.13.7) with ESMTP id m6SEZsh0014380; Mon, 28 Jul 2008 07:35:54 -0700 (PDT) In-Reply-To: (Adrian Robert's message of "Mon, 28 Jul 2008 09:28:45 -0400") Original-Lines: 125 X-ICS-MailScanner: Found to be clean X-ICS-MailScanner-SpamCheck: not spam, SpamAssassin (score=-1.44, required 5, autolearn=disabled, ALL_TRUSTED -1.44) X-ICS-MailScanner-From: dann@mothra.ics.uci.edu X-detected-kernel: by monty-python.gnu.org: Solaris 10 (beta) 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:101645 Archived-At: Adrian Robert writes: > On Jul 27, 2008, at 10:58 PM, Dan Nicolaescu wrote: > > >> DEFVAR_LISP ("ns-icon-type-alist", &Vns_icon_type_alist, > >> doc: /* Alist of elements (REGEXP . IMAGE) for > >> images of > >> icons associated to frames. > >> ... > >> > >> This looks like a generic thing, better not make it platform > >> specific. Is there a problem with the normal way of specifying > >> icons? > >> > >> > >> What is the normal way? I think this facility in the NS port > >> probably dates > >> from before emacs itself had this feature, so certainly we should > >> try to use > >> the generic code now. > > > > You can set a icon as a frame parameter. > > This is a different approach. ns-icon-type-alist allows all frames w/ > titles matching a regexp to get a certain icon. I'm not sure how > widely used this is, but the code is there, it's working, there have > been no complaints about it, I'd rather leave it. The problem is that this is generic functionality, not ns specific, so it should not be in ns specific files. The thing is if something makes it into a released version of emacs it will have to be supported until the end of time. If some functionality gets implemented differently later in the cross platform part of emacs, it will just add complexity to the code. And it will make the life of elisp writers more complicated: they'd have to write (if (featurep 'ns) (foo) (bar)) or (if (boundp 'ns-icon-type-alist) (foo) (bar)). That is unclean and better avoid it. > Someone took the effort to write it at some point, and I assume it > has been found useful. Again, please don't try to force generic functionality in through platform specific code. > >> void > >> syms_of_nsterm () > >> { > >> DEFVAR_LISP ("ns-command-modifier", &ns_command_modifier, > >> "This variable describes the behavior of the > >> command key.\n\ > >> Set to control, meta, alt, super, or hyper means it is taken to > >> be that > >> key."); > >> > >> DEFVAR_LISP ("ns-control-modifier", &ns_control_modifier, > >> "This variable describes the behavior of the > >> control key.\n\ > >> Set to control, meta, alt, super, or hyper means it is taken to > >> be that > >> key."); > >> > >> These 2 look identical, are they both needed? Are they needed > >> at all > >> after the recent modifier changes? > >> > >> > >> On Mac keyboards, Command and Control are separate keys, so both > >> are needed. > > > > So you can change the meaning of Control? That sounds strange. Maybe > > Meta/Alt are sometime confused, but Control should be pretty well > > established. Do users actually want this? > > I'm not sure, they definitely want to map modifiers for alt and > command keys. It's more consistent to handle all modifiers the same > way, and keeps the code simpler. Furthermore, the control panel > interface on OS X where modifiers can be remapped also shows all keys, > so this is consistent with that. IMVHO this is just an extra knob that almost nobody would use. Did the Carbon port have something similar? > >> DEFVAR_LISP ("ns-antialias-text", &ns_antialias_text, > >> "Non-nil (the default) means to render text > >> antialiased. Only > >> has an effect on OS X Panther and above."); > >> > >> Can the generic functionality be used instead of this? > >> > >> > >> Which generic functionality? > > > > There's support for antialiasing in X, I know no details about it as I > > don't use it. > > Maybe there's a case for x-antialias-text now, applicable to all > platforms, with caveat that it's ignored where not supported. Probably, please talk to Handa-san about that. > > One more thing: > > > > DEFUN ("ns-set-alpha", Fns_set_alpha, Sns_set_alpha, 2, 2, 0, > > doc: /* Return a color equivalent to COLOR with alpha setting > > ALPHA. > > The argument ALPHA should be a number between 0 and 1, where 0 is full > > transparency and 1 is opaque. */) > > > > Not sure about the details, but can this functionality be replaced by > > an implementation of x_set_frame_alpha? > > This is a utility function. There's also ns-set-background-alpha. I > would like to replace it with the new alpha frame parameter, but the > meaning is different. For x_set_frame_alpha, the alpha of the entire > window is intended (including the text). ns-set-background-alpha > changes only the background, which usually results in more readable > text. But I'm not sure that any other platform can support this right > now. Maybe drop ns-set-background-alpha and make a customized > variable ns-frame-alpha-affects-only-background? If this is a better interface to this functionality, then IMHO it would be better make it available under a generic name, and then the other platforms can catch up and use this name. Stefan and Jason had opinions about this in other replies, so you might want to talk to them about the details.