From: storm@cua.dk (Kim F. Storm)
Cc: Miles Bader <miles@gnu.org>
Subject: Re: Bold by moving pixels problem
Date: 05 Jun 2003 01:30:53 +0200 [thread overview]
Message-ID: <5xr869o1xu.fsf@kfs2.cua.dk> (raw)
In-Reply-To: <E19NU2b-0005te-Nn@fencepost.gnu.org>
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
next prev parent reply other threads:[~2003-06-04 23:30 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-06-04 8:54 Bold by moving pixels problem Richard Stallman
2003-06-04 14:35 ` Stefan Monnier
2003-06-05 10:58 ` Richard Stallman
2004-01-21 5:39 ` Stefan Monnier
2003-06-04 23:30 ` Kim F. Storm [this message]
[not found] ` <E19O2Z4-0002Rk-GY@fencepost.gnu.org>
2003-06-06 1:45 ` Kim F. Storm
2003-06-06 0:46 ` Miles Bader
-- strict thread matches above, loose matches on Subject: below --
2003-08-07 6:04 last-sexp-toggle-display Richard Stallman
2003-08-07 16:56 ` last-sexp-toggle-display Luc Teirlinck
2003-08-11 12:53 ` last-sexp-toggle-display Richard Stallman
2003-08-11 17:59 ` last-sexp-toggle-display Luc Teirlinck
2003-08-11 18:54 ` Bold by moving pixels problem Robert J. Chassell
2002-11-13 5:42 Gtk version getting closer Eli Zaretskii
2002-11-13 13:21 ` Robert J. Chassell
2002-11-14 12:16 ` Richard Stallman
2002-11-14 16:46 ` Robert J. Chassell
2002-11-15 2:20 ` Miles Bader
[not found] ` <m18EUbO-000IeAC@localhost>
2002-11-20 22:08 ` Bold by moving pixels problem Miles Bader
2002-11-21 0:21 ` Robert J. Chassell
2002-11-21 1:33 ` Stefan Monnier
2002-11-21 1:44 ` Miles Bader
[not found] ` <m18HRR2-000IeBC@localhost>
2002-12-17 5:00 ` Miles Bader
2002-12-17 6:28 ` Miles Bader
2002-12-17 7:08 ` Miles Bader
2002-12-18 10:01 ` Miles Bader
2002-12-18 12:26 ` Kim F. Storm
2002-12-19 8:34 ` Miles Bader
2002-12-19 10:18 ` Miles Bader
2002-12-19 12:18 ` Kim F. Storm
2002-12-19 11:27 ` Miles Bader
2002-12-19 12:25 ` Miles Bader
2002-12-19 13:55 ` Kim F. Storm
2003-01-07 11:02 ` Kim F. Storm
2003-01-07 14:02 ` Miles Bader
2003-01-09 7:28 ` Richard Stallman
2003-01-09 7:52 ` Miles Bader
2002-12-18 14:25 ` Robert J. Chassell
2002-12-17 10:31 ` Kim F. Storm
2002-12-17 16:38 ` Robert J. Chassell
2002-12-17 23:54 ` Miles Bader
2002-11-21 6:01 ` Eli Zaretskii
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=5xr869o1xu.fsf@kfs2.cua.dk \
--to=storm@cua.dk \
--cc=miles@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.