emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bold by moving pixels problem


From: Kim F. Storm
Subject: Re: Bold by moving pixels problem
Date: 05 Jun 2003 01:30:53 +0200
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

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 <address@hidden>
> 
> 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 <address@hidden> 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 <address@hidden> http://www.cua.dk





reply via email to

[Prev in Thread] Current Thread [Next in Thread]