From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Adrian Robert Newsgroups: gmane.emacs.devel Subject: Re: observations for ns*.m files (Re: Emacs.app merged) Date: Mon, 28 Jul 2008 09:28:45 -0400 Message-ID: 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 (Apple Message framework v926) Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1217252783 10512 80.91.229.12 (28 Jul 2008 13:46:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 28 Jul 2008 13:46:23 +0000 (UTC) Cc: emacs- devel To: Dan Nicolaescu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 28 15:47:12 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 1KNT3n-0008AY-0Y for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2008 15:46:48 +0200 Original-Received: from localhost ([127.0.0.1]:56202 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNT2s-0006HW-4i for ged-emacs-devel@m.gmane.org; Mon, 28 Jul 2008 09:45:50 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KNSmd-0007z1-5c for emacs-devel@gnu.org; Mon, 28 Jul 2008 09:29:03 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KNSmb-0007yb-Am for emacs-devel@gnu.org; Mon, 28 Jul 2008 09:29:02 -0400 Original-Received: from [199.232.76.173] (port=38769 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KNSmb-0007yY-3e for emacs-devel@gnu.org; Mon, 28 Jul 2008 09:29:01 -0400 Original-Received: from wr-out-0506.google.com ([64.233.184.236]:35320) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KNSma-0002AA-O5 for emacs-devel@gnu.org; Mon, 28 Jul 2008 09:29:00 -0400 Original-Received: by wr-out-0506.google.com with SMTP id c30so4048098wra.14 for ; Mon, 28 Jul 2008 06:29:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:cc:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=OEbavsQ8K/kZ4xgNFIdJ9T2NJivIaS135Yyh8kSGxhg=; b=jd3gG3SGfEzVH1GhO5ziCdqIRaKidNvxiVeL6gplhIcP5bXOK9XjHJnPHV4OSLcxjx j+JUAvVH7R/8BOPzX7/1N693Id06hzg789hAoBWAH1P2YOz1M7cmbVXwoJYP9tQmFZiw RNVLIYbHaIgYNBJD0t7dncmq/SreQBOypMj/Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=cc:message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=aOkxW04ccamlb5dWFG19H4uU5hpZCs8OT+zSRpP53glT0joT6h+Y/+2xNclfonoK3l 4j82HAZdxbbBzOGiDjerk+rdlbimoae5jKwUXoMEUspvAX1erE1a7lueJSAn1zGvzXJQ oWTJilcwhkhBZH5SMafGqrOV6G7je45925VTc= Original-Received: by 10.90.72.3 with SMTP id u3mr4577492aga.45.1217251739924; Mon, 28 Jul 2008 06:28:59 -0700 (PDT) Original-Received: from ?10.0.1.200? ( [97.73.30.9]) by mx.google.com with ESMTPS id 20sm15415650agb.38.2008.07.28.06.28.54 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 28 Jul 2008 06:28:59 -0700 (PDT) In-Reply-To: <200807280258.m6S2wQmW021098@sallyv1.ics.uci.edu> X-Mailer: Apple Mail (2.926) X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) 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:101634 Archived-At: 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. Someone took the effort to write it at some point, and I assume it has been found useful. >> 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. >> What recent modifier changes are you referring to? > > where-is-preferred-modifier OK, no that relates to a different issue. >> 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. > 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?