From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David De La Harpe Golden Newsgroups: gmane.emacs.devel Subject: Re: Changes 2009-07-15/16 in branch? Date: Mon, 27 Jul 2009 21:14:06 +0100 Message-ID: <4A6E0A8E.3030407@harpegolden.net> References: <4A692E0A.9060108@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1248725686 13710 80.91.229.12 (27 Jul 2009 20:14:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 27 Jul 2009 20:14:46 +0000 (UTC) Cc: adrian.b.robert@gmail.com, jasonr@gnu.org, monnier@iro.umontreal.ca, YAMAMOTO Mitsuharu , emacs-devel@gnu.org To: rms@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 27 22:14:38 2009 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 1MVWag-0004pB-Hv for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 22:14:34 +0200 Original-Received: from localhost ([127.0.0.1]:39690 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVWaf-0006VT-RU for ged-emacs-devel@m.gmane.org; Mon, 27 Jul 2009 16:14:33 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MVWaY-0006Ua-T3 for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:14:26 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MVWaU-0006Tq-RI for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:14:26 -0400 Original-Received: from [199.232.76.173] (port=46087 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MVWaU-0006Tn-OH for emacs-devel@gnu.org; Mon, 27 Jul 2009 16:14:22 -0400 Original-Received: from harpegolden.net ([65.99.215.13]:34724) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MVWaP-0000RF-HD; Mon, 27 Jul 2009 16:14:17 -0400 Original-Received: from [87.198.54.192] (87-198-54-192.ptr.magnet.ie [87.198.54.192]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "David De La Harpe Golden", Issuer "David De La Harpe Golden Personal CA rev 3" (verified OK)) by harpegolden.net (Postfix) with ESMTP id 0716C81CB; Mon, 27 Jul 2009 21:14:13 +0100 (IST) User-Agent: Mozilla-Thunderbird 2.0.0.22 (X11/20090701) In-Reply-To: X-detected-operating-system: by monty-python.gnu.org: Genre and OS details not recognized. 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:113250 Archived-At: Richard Stallman wrote: > What I'm concerning about with respect to the GNU policy is the > "alpha-component" (or maybe "alpha-channel" is more familiar) support, > which was added only for Cocoa. Alpha-component/alpha-channel > controls translucency of colors by specifying how opaque it is. > > Is this a feature users might actually want to use? > I don't see what it is good for. > Can someone explain what a user might want to do with this? > > > Well, my understanding (possibly outdated) is the NS port only uses its alpha value in very limited fashion. It just lets you sort of see what's underneath the emacs window. It's AFAIK not doing the in-emacs alpha-blending I proposed (without working implementation...) a while back to allow translucent overlays - e.g. a translucent region letting highlighted text "underneath" show through /with highlighting still visible/. That would be much more useful. But if I was doing that in-emacs alphablending (not saying I will successfully, just if...), I personally would not use the peculiar NS chosen syntax for colors with alpha values. I'd probably prefer to have separate float face properties, foreground-alpha and background-alpha, to allow me to continue to use named X11 colors i.e. background: "midnightblue" background-alpha: 0.5 (yes, I suppose it would be possible to support both external and in-color-name alphas, messily. But if I was doing that, I'm still not keen on the NS chosen syntax. Note how css and x11 both nowadays user separated values e.g. rgb(r, g, b) or rgb:r/g/b ) OTOH, color names are currently parsed in a platform dependent manner anyway - i.e. you can't expect a color specification that works on X11 to work on w32. X11 emacs actually does a call out to XParseColor() on X11, which means emacs might get end-user defined named colors for all it knows*, so I'm not sure there's any particular harm in letting the NS port have its own interpretation of the color name strings. * e.g. Place following in ~/.xcms.txt XCMS_COLORDB_START 0.1 Blobby rgb:7fe2/ffe1/331a XCMS_COLORDB_END (note that the syntax demands a _tab_ between color name and rgb: spec) then do export XCMSDB=~/.xcms.txt Now run x11 emacs, and note how if you enter Blobby (or indeed some rgb:r/g/b value) in emacs for a color, x11 emacs recognises it.