1:17 p.m.
i built yesterday, against the latest CVS, and apparently everything
continued to be OK, except for VM
i use a pixmap for my bg, but now VM randomly modifies the bg of its
windows and also the bg of the minibuffer (sometimes it's my pixmap,
sometimes it's the default background color that i set in .Xdefaults)
ciao
1:36 p.m.
giacomo boffi writes:
i built yesterday, against the latest CVS, and apparently everything
continued to be OK, except for VM
i use a pixmap for my bg, but now VM randomly modifies the bg of its
windows and also the bg of the minibuffer (sometimes it's my pixmap,
sometimes it's the default background color that i set in .Xdefaults)
i forgot: i don't use buffer tabs
2:37 p.m.
At 02:17 PM 11/22/00 +0100, giacomo boffi wrote:
i built yesterday, against the latest CVS, and apparently everything
continued to be OK, except for VM
i use a pixmap for my bg, but now VM randomly modifies the bg of its
windows and also the bg of the minibuffer (sometimes it's my pixmap,
sometimes it's the default background color that i set in .Xdefaults)
I don't think my patches will have changed this - it sounds like Didier's
recent patch. You might want to try backing it out and see if that makes a
difference.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
3:47 p.m.
Andy Piper <andyp(a)bea.com> wrote:
I don't think my patches will have changed this - it sounds like
Didier's
recent patch. You might want to try backing it out and see if that makes a
difference.
It's probably my patch, indeed, and it probably means the answer to
one of my questions in the comment is "no". Try backing it out, as Andy says.
If that fixes the problem, I think I have the good solution.
Here's the original mail:
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
1:59 p.m.
Didier Verna writes:
Andy Piper <andyp(a)bea.com> wrote:
> I don't think my patches will have changed this - it sounds like Didier's
> recent patch. You might want to try backing it out and see if that makes a
> difference.
It's probably my patch, indeed, and it probably means the answer
to one of my questions in the comment is "no". Try backing it out,
as Andy says. If that fixes the problem, I think I have the good
solution.
i reverted Didier's patch, and VM is OK again
ciao
3:03 p.m.
giacomo boffi <giacomo.boffi(a)polimi.it> wrote:
i reverted Didier's patch, and VM is OK again
OK. Now try this one _on top_ of the other, and tell me if it works
correctly.
Index: faces.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/src/faces.c,v
retrieving revision 1.25.2.18
diff -u -r1.25.2.18 faces.c
--- faces.c 2000/11/20 14:02:17 1.25.2.18
+++ faces.c 2000/11/23 15:06:16
＠＠ -1154,22 +1154,6 ＠＠
}
}
-/* Called when the updated flag has been cleared on a cachel. */
-
-void
-update_face_cachel_data (struct face_cachel *cachel,
- Lisp_Object domain,
- Lisp_Object face)
-{
- if (XFACE (face)->dirty || UNBOUNDP (cachel->face))
- {
- int default_face = EQ (face, Vdefault_face);
- cachel->face = face;
-
- /* We normally only set the _specified flags if the value was
- actually bound. The exception is for the default face where
- we always set it since it is the ultimate fallback. */
-
#define FROB(field) \
do { \
Lisp_Object new_val = \
＠＠ -1188,6 +1172,76 ＠＠
cachel->field##_specified = (bound || default_face); \
} while (0)
+/*
+ * A face's background pixmap will override the face's
+ * background color. But the background pixmap of the
+ * default face should not override the background color of
+ * a face if the background color has been specified or
+ * inherited.
+ *
+ * To accomplish this we remove the background pixmap of the
+ * cachel and mark it as having been specified so that cachel
+ * merging won't override it later.
+ */
+#define MAYBE_UNFROB_BACKGROUND_PIXMAP \
+do \
+{ \
+ if (! default_face \
+ && cachel->background_specified \
+ && ! cachel->background_pixmap_specified) \
+ { \
+ cachel->background_pixmap = Qunbound; \
+ cachel->background_pixmap_specified = 1; \
+ } \
+} while (0)
+
+
+/* Add a cachel for the given face to the given window's cache. */
+
+static void
+add_face_cachel (struct window *w, Lisp_Object face)
+{
+ int must_finish_frobbing = ! WINDOW_FACE_CACHEL (w, DEFAULT_INDEX);
+ struct face_cachel new_cachel;
+ Lisp_Object domain;
+
+ reset_face_cachel (&new_cachel);
+ XSETWINDOW (domain, w);
+ update_face_cachel_data (&new_cachel, domain, face);
+ Dynarr_add (w->face_cachels, new_cachel);
+
+ /* The face's background pixmap have not yet been frobbed (see comment
+ int update_face_cachel_data), so we have to do it now */
+ if (must_finish_frobbing)
+ {
+ int default_face = EQ (face, Vdefault_face);
+ struct face_cachel *cachel
+ = Dynarr_atp (w->face_cachels, Dynarr_length (w->face_cachels) - 1);
+
+ FROB (background_pixmap);
+ MAYBE_UNFROB_BACKGROUND_PIXMAP;
+ }
+}
+
+/* Called when the updated flag has been cleared on a cachel.
+ This function returns 1 if the caller must finish the update (see comment
+ below), 0 otherwise.
+*/
+
+void
+update_face_cachel_data (struct face_cachel *cachel,
+ Lisp_Object domain,
+ Lisp_Object face)
+{
+ if (XFACE (face)->dirty || UNBOUNDP (cachel->face))
+ {
+ int default_face = EQ (face, Vdefault_face);
+ cachel->face = face;
+
+ /* We normally only set the _specified flags if the value was
+ actually bound. The exception is for the default face where
+ we always set it since it is the ultimate fallback. */
+
FROB (foreground);
FROB (background);
FROB (display_table);
＠＠ -1220,44 +1274,23 ＠＠
other image-related face attributes are ever implemented, they should
be protected the same way right here.
- Some notes:
+ One note:
* See comment in `default_face_font_info' in face.c. Who wrote it ?
Maybe we have the begining of an answer here ?
- * After window initialization, we end up with an incomplete cache
- since the background pixmap has not been frobbed. It seems however
- that redisplay will correct the situation the next time it is
- triggered. Is that correct ? All the time ?
Footnotes:
[1] See comment at the top of `allocate_window' in window.c.
-- didier
*/
- if (!WINDOWP (domain)
+ if (! WINDOWP (domain)
|| WINDOW_FACE_CACHEL (DOMAIN_XWINDOW (domain), DEFAULT_INDEX))
{
FROB (background_pixmap);
-
- /*
- * A face's background pixmap will override the face's
- * background color. But the background pixmap of the
- * default face should not override the background color of
- * a face if the background color has been specified or
- * inherited.
- *
- * To accomplish this we remove the background pixmap of the
- * cachel and mark it as having been specified so that cachel
- * merging won't override it later.
- */
- if (! default_face
- && cachel->background_specified
- && ! cachel->background_pixmap_specified)
- {
- cachel->background_pixmap = Qunbound;
- cachel->background_pixmap_specified = 1;
- }
+ MAYBE_UNFROB_BACKGROUND_PIXMAP;
}
#undef FROB
+#undef MAYBE_UNFROB_BACKGROUND_PIXMAP
ensure_face_cachel_contains_charset (cachel, domain, Vcharset_ascii);
＠＠ -1360,20 +1393,6 ＠＠
}
cachel->display_table = Qunbound;
cachel->background_pixmap = Qunbound;
-}
-
-/* Add a cachel for the given face to the given window's cache. */
-
-static void
-add_face_cachel (struct window *w, Lisp_Object face)
-{
- struct face_cachel new_cachel;
- Lisp_Object window;
-
- reset_face_cachel (&new_cachel);
- XSETWINDOW (window, w);
- update_face_cachel_data (&new_cachel, window, face);
- Dynarr_add (w->face_cachels, new_cachel);
}
/* Retrieve the index to a cachel for window W that corresponds to
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
4:21 p.m.
Didier Verna <didier(a)xemacs.org> writes:
+/*
+ * A face's background pixmap will override the face's
+ * background color. But the background pixmap of the
+ * default face should not override the background color of
+ * a face if the background color has been specified or
+ * inherited.
+ *
+ * To accomplish this we remove the background pixmap of the
+ * cachel and mark it as having been specified so that cachel
+ * merging won't override it later.
Didier, if you're working on this, you might want to fix the code.
The above comment, as it stands, does not cover all the cases.
Imagine the default face having a background pixmap. Say face A
exists and specifies its own background color. The color prevails
over the background inherited from default, which is good. But now
imagine a face B which inherits from face A (and specifies something
inconsequential, such as its foreground color.) You would expect the
face B to display exactly as the face A, except for the different
foreground color?
What happens is that face B gets displayed incorrectly, because the
MAYBE_UNFROB_BACKGROUND_PIXMAP sees that B doesn't specify its own
background color and concludes that the inherited background pixmap
should win.
Substitute modeline for A and modeline-mousable for B, and you'll
understand what's wrong with this picture:
What happens here is that my default face has a nearly black
background pixmap. However, I prefer my modeline to look like a
widget, and have this statement in my .emacs:
(set-face-background 'modeline "gray80")
But modeline-mousable and modeline-buffer-id faces *inherit* from
modeline, and for them the default background wins, as explained
above.
The correct way to resolve this conflict is like this:
The cachel needs to have either a background or a background
pixmap.
Instead of examining only the specifications of one face, the code
should go upward in the face inheritance hierarchy, and stop at
the level where either `background' or `background-pixmap' is
specified, and make that one the winner for the cachel. If they
are specified on the same level, `background' wins.
This was originally formulated by Ben, and I believe it would work
correctly in all cases. The current code would be the special case of
it, where the `background' is specified for the current case and no
upward examination is necessary.
9:36 a.m.
Hrvoje Niksic wrote:
Didier, if you're working on this, you might want to fix the
code.
The above comment, as it stands, does not cover all the cases.
Yes, I'm aware of the problem and it's indeed my intention to work on
it. BTW, I'm using a setup similar to yours with respect to faces (a dark
background pixmap for the default face and so on) and I have a temporary work
around (my faces are set up with custom, but you can do the same in your
.emacs): I setup the modeline face to a a grey background color, and *ALSO* a
background pixmap, but with a value of "[nothing]". That way, all faces
deriving from the modeline face actually be displayed with the grey
background.
The correct way to resolve this conflict is like this:
The cachel needs to have either a background or a background
pixmap.
Instead of examining only the specifications of one face, the code
should go upward in the face inheritance hierarchy, and stop at
the level where either `background' or `background-pixmap' is
specified, and make that one the winner for the cachel. If they
are specified on the same level, `background' wins.
This was originally formulated by Ben, and I believe it would work
correctly in all cases. The current code would be the special case of
it, where the `background' is specified for the current case and no
upward examination is necessary.
Yes, this is indeed the proper solution.
In a somewhat longer term, I plan to have a real `emacs-background'
specifier (I believe that the current status of the default face's background
is conceptually wrong; I can elaborate on this) instead of the current trick
of using face attribute for this. This is however subordinate to having a real
X Window per Emacs Window, which I also intend to implement. For Windows, I
don't know how it goes. Is the background-pixmap actually working under
Windows ?
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
10:15 a.m.
At 10:36 AM 11/27/00 +0100, Didier Verna wrote:
X Window per Emacs Window, which I also intend to implement. For
Windows, I
don't know how it goes. Is the background-pixmap actually working under
Windows ?
Yes, although the implementation is less trivial than under X.
andy
--------------------------------------------------------------
Dr Andy Piper
Principal Consultant, BEA Systems Ltd
11:43 a.m.
Andy Piper <andyp(a)bea.com> wrote:
At 10:36 AM 11/27/00 +0100, Didier Verna wrote:
>X Window per Emacs Window, which I also intend to implement. For Windows, I
>don't know how it goes. Is the background-pixmap actually working under
>Windows ?
Yes, although the implementation is less trivial than under X.
When I start working on the multiple X Window support,we'll have to
talk about the Windows implications. I expect it also to be less trivial than
under X.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
10:38 a.m.
Didier Verna <didier(a)xemacs.org> writes:
Hrvoje Niksic wrote:
> Didier, if you're working on this, you might want to fix the code.
> The above comment, as it stands, does not cover all the cases.
Yes, I'm aware of the problem and it's indeed my intention to work
on it. BTW, I'm using a setup similar to yours with respect to faces
(a dark background pixmap for the default face and so on) and I have
a temporary work around (my faces are set up with custom, but you
can do the same in your .emacs): I setup the modeline face to a a
grey background color, and *ALSO* a background pixmap, but with a
value of "[nothing]". That way, all faces deriving from the modeline
face actually be displayed with the grey background.
Nice. What I do is a bit more hackish:
(set-face-background-pixmap 'modeline-mousable [nothing])
(set-face-background-pixmap 'modeline-buffer-id [nothing])
In a somewhat longer term, I plan to have a real
`emacs-background'
specifier (I believe that the current status of the default face's
background is conceptually wrong; I can elaborate on this)
I believe you did. I don't have an opinion on that, so I might as
well agree. :-)
An emacs-background specifier should be able to specify a transparent
background, too.
12:12 p.m.
Hrvoje Niksic wrote:
An emacs-background specifier should be able to specify a
transparent
background, too.
Yup. I have this almost working under certain window/session managers.
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
10:49 a.m.
Hrvoje Niksic wrote:
Didier, if you're working on this, you might want to fix the
code.
Imagine the default face having a background pixmap. Say face A
exists and specifies its own background color. The color prevails
over the background inherited from default, which is good. But now
imagine a face B which inherits from face A (and specifies something
inconsequential, such as its foreground color.) You would expect the
face B to display exactly as the face A, except for the different
foreground color?
What happens is that face B gets displayed incorrectly, because the
MAYBE_UNFROB_BACKGROUND_PIXMAP sees that B doesn't specify its own
background color and concludes that the inherited background pixmap
should win.
This is actually *not* what happens. What happens is that the image
instantiator uses fallbacks in the case of face inheritance. Taking again your
example, here's what happens:
- We try to instantiate the background pixmap of the 'modeline-mousable face.
- It "inherits" from the 'modeline face, so we try to instantiate that one.
- It is unspecified, so we use the fallback, which returns the 'default face
specification.
As a consequence, the code related to the face cache management *is* correct:
the cache for 'modeline-mousable indeed contains a real specification for the
background-pixmap, so it wins.
I'll send a fix for this on xemacs-patches＠.
BTW, this reminds me of something a bit annoying:
if you do ... (set-face-background-pixmap face pixmap)
and later ... (set-face-background face color)
you would expect to remove actually the pixmap, wouldn't you (I would :-) ?
--
/ / _ _ Didier Verna http://www.inf.enst.fr/~verna/
- / / - / / /_/ / EPITA / LRDE mailto:didier＠lrde.epita.fr
/_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 53 14 59 47
94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99
8704
days inactive
8759
days old
13 comments
4 participants
participants (4)
-
Andy Piper -
Didier Verna -
Giacomo Boffi -
Hrvoje Niksic