From: "Jan D." <jan.h.d@swipnet.se>
Cc: emacs-devel@gnu.org
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 [thread overview]
Message-ID: <26C9786D-DA7D-11D6-8C1C-00039363E640@swipnet.se> (raw)
In-Reply-To: <200210072007.g97K7HG26460@rum.cs.yale.edu>
>> 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.
next prev parent reply other threads:[~2002-10-08 5:16 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-10-06 0:21 [patch] cache color info for remote X sessions [Was: Emacs 21/X11 generating unbelieveable network traffic] Ami Fischman
2002-10-06 1:29 ` Miles Bader
2002-10-06 5:31 ` Ami Fischman
2002-10-06 6:53 ` Miles Bader
2002-10-06 17:59 ` Jan D.
2002-10-06 20:22 ` Ami Fischman
2002-10-06 18:14 ` Ami Fischman
2002-10-07 14:53 ` Stefan Monnier
2002-10-07 15:35 ` Ami Fischman
2002-10-07 15:52 ` Stefan Monnier
2002-10-07 16:49 ` Ami Fischman
2002-10-07 17:59 ` Jan D.
2002-10-07 18:14 ` Jan D.
2002-10-07 20:07 ` Stefan Monnier
2002-10-08 5:16 ` Jan D. [this message]
2002-10-08 17:21 ` Richard Stallman
2002-10-07 15:31 ` Richard Stallman
2002-10-07 17:04 ` Ami Fischman
2002-10-08 17:21 ` Richard Stallman
2002-10-06 7:46 ` Jan D.
2002-10-06 17:33 ` Ami Fischman
2002-10-07 15:31 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26C9786D-DA7D-11D6-8C1C-00039363E640@swipnet.se \
--to=jan.h.d@swipnet.se \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.