From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: "Jan D." Newsgroups: gmane.emacs.devel Subject: Re: [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic] Date: Tue, 8 Oct 2002 07:16:51 +0200 Sender: emacs-devel-admin@gnu.org Message-ID: <26C9786D-DA7D-11D6-8C1C-00039363E640@swipnet.se> References: <200210072007.g97K7HG26460@rum.cs.yale.edu> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 (Apple Message framework v482) Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit X-Trace: main.gmane.org 1034054326 19684 127.0.0.1 (8 Oct 2002 05:18:46 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 8 Oct 2002 05:18:46 +0000 (UTC) Cc: emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17ymlY-000576-00 for ; Tue, 08 Oct 2002 07:18:44 +0200 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 17ynYx-0003uA-00 for ; Tue, 08 Oct 2002 08:09:47 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ymkx-0005c0-00; Tue, 08 Oct 2002 01:18:07 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17ymkF-0003lT-00 for emacs-devel@gnu.org; Tue, 08 Oct 2002 01:17:23 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17ymkB-0003bD-00 for emacs-devel@gnu.org; Tue, 08 Oct 2002 01:17:22 -0400 Original-Received: from stubby.bodenonline.com ([193.201.16.94]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17ymk7-0002wW-00 for emacs-devel@gnu.org; Tue, 08 Oct 2002 01:17:16 -0400 Original-Received: from pc35.bodenonline.com (IDENT:root@pc35.bodenonline.com [195.196.29.227] (may be forged)) by stubby.bodenonline.com (8.12.1/8.12.1) with ESMTP id g985DDd8002295; Tue, 8 Oct 2002 07:13:17 +0200 Original-To: "Stefan Monnier" In-Reply-To: <200210072007.g97K7HG26460@rum.cs.yale.edu> X-Mailer: Apple Mail (2.482) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:8460 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:8460 >> In principle, yes. But if Emacs runs on the default visual, it uses the >> default colormap, otherwise, it creates its own. It would not be nice >> by an application to change the default colormap or one created by Emacs. >> >> It can happen, but I consider that a bug in the application that does >> such a thing. > > My "default" colormap has never behaved in that way. It just contains > whichever colors have been requested by applications, i.e. it is changed > by applications like ExMH, Netscape, Emacs, ... You are right, I didn't read the question properly. If an application allocates a color not in the colormap and there are free cells, these cells change. But Emacs should not be using cells (i.e. pixels) that it has freed. I don't think it does, I'll check that. > >>> As someone whose colormap is full about 95% of the time, I can >>> assure you that tose things happen ;-) >> >> What should happen is that when the colormap is full, a new one is >> created and then the window manager switches colormap depending on >> which application has the focus. > > I hate colormap switching. I much prefer what happens with Emacs: > when XAllocColor fails, Emacs looks for the nearest color in the map > and uses it. After all I generally don't care that much about the > exact color. If the exact color isn't important, and the nearest color is ok, that is easier on the user. But sometimes the exact color is important, and then you have no choise but to do switching. Anyway, in about a year or two, we will all be running 16 or 24 bit color and this problem goes away :-) Jan D.