Re: Bold by moving pixels problem

[storm@cua.dk (Kim F. Storm)]

Before we accept Miles' patch, I would like to remind you that we
talked about a much better aproach the last time the issue was
raised (it probably has the same problems with signal handlers
and GC):

> Date: 19 Dec 2002 21:25:49 +0900
> From: Miles Bader <miles@gnu.org>
> 
> A while back I toyed with the idea of using face-vectors as `anonymous'
> faces, since it's often a pain to have to name a face.
> 
> On reason I didn't really do anything was that I figured there are
> probably places, in the redisplay code especially, which wouldn't work
> well without a named face (though at the time I wanted to make
> anonymous faces to inherit from, which should work fine).
> 
> However, in many places, it's trival -- in particular
> `internal-get-lisp-face-attribute' and `internal-set-lisp-face-attribute',
> since they use vectors internally and just translate the face-symbol into a
> vector at their start (the latter function would require a bit more tweaking,
> but as far as I could see, it's still fair to call it `trivial').
> 
> Now if those two functions were changed to allow `anonymous' faces (face
> vectors), then such functions as `face-attribute', `set-face-attribute',
> `make-face-bold', etc., would all start working on face-vectors too!
> 
> That way, functions in realize-face-filter-functions could still accept face-
> vectors, avoiding the plist translation step, but also use the same familiar
> face functions that users already know about; this seems like a huge win to
> me... 
> 
> [p.s. I'd still like to also allow anonymous faces in more places, but that's
> a separate issue]
> 



Richard Stallman <rms@gnu.org> writes:

> This patch makes it possible to GC inside a lot of places
> that formerly could not.  A list of them is below.
> I would expect that some of them don't GCPRO what they need to,
> but I have not checked them for that.

> 
> It also looks like eval can in principle be called from a signal
> handler.  We could solve that problem if we move all X event
> processing outside of the signal handler, as someone suggested.  That
> would mean that mouse highlighting doesn't update if you move the
> mouse while a command is running, and the Emacs frame would not
> rewrite itself if you move another window across it while a command is
> running.  I think that would be a very noticeable step backwards.
> 

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk