10:44 a.m.
Andy Piper <andy(a)xemacs.org> writes:
Oh dear. This is my fault.
At 04:54 PM 8/30/99 +0900, SL Baur wrote:
>From current cvs and a clean build. Any clues?
Try this:
[...]
Unfortunately, this doesn't fix the crash. Here is the backtrace:
To make things worse, not even your second patch cures the crash. The
backtrace seems the same.
11:49 a.m.
New subject: Continuing problems with current 21.2
On Mon, Aug 30, 1999 at 11:44:22AM +0200, Hrvoje Niksic wrote:
To make things worse, not even your second patch cures the crash.
The
backtrace seems the same.
You can workaround it with:
Index: lwlib-Xaw.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xaw.c,v
retrieving revision 1.9.2.3
diff -u -r1.9.2.3 lwlib-Xaw.c
--- lwlib-Xaw.c 1999/08/29 20:57:18 1.9.2.3
+++ lwlib-Xaw.c 1999/08/30 10:48:06
＠＠ -149,7 +149,7 ＠＠
else if (XtClass (widget) == labelWidgetClass)
{
Arg al [1];
- XtSetArg (al [0], XtNlabel, val->contents->value);
+ XtSetArg (al [0], XtNlabel, val->contents ? val->contents->value :
"<null>");
XtSetValues (widget, al, 1);
}
#endif /* LWLIB_WIDGETS_ATHENA */
Motif seems to be more NULL-proof.
OG.
12:55 p.m.
New subject: Continuing problems with current 21.2
thanx, this does the trick.
but i still applied the first (fix) patch from Andy Piper, not the
second that is supposed to disable what color fix i don't know.
the result is funny: i get the background of the gutter to black (normal
with my setup) and the foreground to blue for the *scratch* , but then
if i load several files within the same gutter-group, only the first tab
had a fg of blue, all the others are fg white.
funny thing is that when i click on another gutter tab to visit another
buffer, thngs stay the same, then if i loose/gain focus on the XEmacs
frame, the tabs order change, putting the actual buffer as the first
tab, but the fg color still is the first tab.
not possible to have another tab with my foreground.
what face is it supposed to get the color from?
On Mon, Aug 30, 1999 at 06:49:32AM -0400, Olivier Galibert wrote:
On Mon, Aug 30, 1999 at 11:44:22AM +0200, Hrvoje Niksic wrote:
> To make things worse, not even your second patch cures the crash. The
> backtrace seems the same.
You can workaround it with:
Index: lwlib-Xaw.c
===================================================================
RCS file: /usr/CVSroot/XEmacs/xemacs/lwlib/lwlib-Xaw.c,v
retrieving revision 1.9.2.3
diff -u -r1.9.2.3 lwlib-Xaw.c
--- lwlib-Xaw.c 1999/08/29 20:57:18 1.9.2.3
+++ lwlib-Xaw.c 1999/08/30 10:48:06
＠＠ -149,7 +149,7 ＠＠
else if (XtClass (widget) == labelWidgetClass)
{
Arg al [1];
- XtSetArg (al [0], XtNlabel, val->contents->value);
+ XtSetArg (al [0], XtNlabel, val->contents ? val->contents->value :
"<null>");
XtSetValues (widget, al, 1);
}
#endif /* LWLIB_WIDGETS_ATHENA */
Motif seems to be more NULL-proof.
OG.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
2:38 p.m.
New subject: Continuing problems with current 21.2
At 11:44 AM 8/30/99 +0200, Hrvoje Niksic wrote:
To make things worse, not even your second patch cures the crash. The
backtrace seems the same.
Of course I was assuming that I had introduced new bugs, not revealed old
ones. You will be pleased to know that I have fixed at least 3 lwlib bugs
as part of fixing the tab colors. All authored by me of course :)
I have applied this to cvs.
andy
1999-08-30 Andy Piper <andy(a)xemacs.org>
* lwlib.c (free_widget_value_contents): be more precise about
freeing user defined args.
* lwlib-Xaw.c (xaw_update_one_widget): make sure we use val not
its contents for hierarchies one deep.
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
2:58 p.m.
New subject: Continuing problems with current 21.2
At 06:49 AM 8/30/99 -0400, Olivier Galibert wrote:
Motif seems to be more NULL-proof.
Maybe, but lwlib-Xm.c also doesn't have this bug. Its a copy and paste
error on my part...
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
2:59 p.m.
New subject: Continuing problems with current 21.2
At 01:55 PM 8/30/99 +0200, Stef Epardaud wrote:
not possible to have another tab with my foreground.
what face is it supposed to get the color from?
Currently default. There is still a problem that if you change the face the
changes do not get noticed for existing tabs. This is somthing of a problem
anyway for XEmacs under X, but I think it is fixable in the case of tabs.
If you use X resources to set faces then you should get the right effect.
e.g. xemacs -fg red
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
3:03 p.m.
New subject: Continuing problems with current 21.2
On Mon, Aug 30, 1999 at 02:59:01PM +0100, Andy Piper wrote:
At 01:55 PM 8/30/99 +0200, Stef Epardaud wrote:
>not possible to have another tab with my foreground.
>what face is it supposed to get the color from?
Currently default. There is still a problem that if you change the face the
defaults, as in 'default text' ??
should that not be a gui face or a menu face ?
changes do not get noticed for existing tabs. This is somthing of a
problem
anyway for XEmacs under X, but I think it is fixable in the case of tabs.
If you use X resources to set faces then you should get the right effect.
e.g. xemacs -fg red
well i do have that in my .Xresources:
Emacs*borderColor: #8470ff
Emacs*menubar: False
Emacs*foreground: #8470ff
Emacs*background: black
and the tabs in the first frame that are not the first tab have all a
white fg instead of a blue one like every other menu item.
and for the other frames, all tabs have white fg.
just that one left tab on the first frame stays blue, lovely tab, i am
so attached to it now :)
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
5:19 p.m.
New subject: Continuing problems with current 21.2
At 04:03 PM 8/30/99 +0200, Stef Epardaud wrote:
On Mon, Aug 30, 1999 at 02:59:01PM +0100, Andy Piper wrote:
> At 01:55 PM 8/30/99 +0200, Stef Epardaud wrote:
> >not possible to have another tab with my foreground.
> >what face is it supposed to get the color from?
>
> Currently default. There is still a problem that if you change the face the
defaults, as in 'default text' ??
default face so I guess yes.
should that not be a gui face or a menu face ?
Well, really whatever people want. I don't currently use X and have found
no way of setting the tab colors under mswindows so it doesn't bother me.
The idea was that the tab should be a continuation of the color of the
buffer. But I'm not sure you can set the background of the non-tab bit, so
maybe that's pie in the sky. I will bow to whatever people want (and at the
very least make it customizable), although precedence says they should be
the same color as the buffer. It might not look bad when I get around to
fixing the 3d-ness.
> changes do not get noticed for existing tabs. This is somthing of
a problem
> anyway for XEmacs under X, but I think it is fixable in the case of tabs.
> If you use X resources to set faces then you should get the right effect.
> e.g. xemacs -fg red
well i do have that in my .Xresources:
Emacs*borderColor: #8470ff
Emacs*menubar: False
Emacs*foreground: #8470ff
Emacs*background: black
and the tabs in the first frame that are not the first tab have all a
white fg instead of a blue one like every other menu item.
and for the other frames, all tabs have white fg.
Hmmn, what color is #8470ff? That should be the color you are getting.
What do you do in .emacs?
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
5:29 p.m.
New subject: Continuing problems with current 21.2
On Mon, Aug 30, 1999 at 05:19:25PM +0100, Andy Piper wrote:
>should that not be a gui face or a menu face ?
Well, really whatever people want. I don't currently use X and have found
no way of setting the tab colors under mswindows so it doesn't bother me.
The idea was that the tab should be a continuation of the color of the
buffer. But I'm not sure you can set the background of the non-tab bit, so
maybe that's pie in the sky. I will bow to whatever people want (and at the
very least make it customizable), although precedence says they should be
the same color as the buffer. It might not look bad when I get around to
fixing the 3d-ness.
well i would say it is a gui item, and should be treated as such,
so it should/could have the color of the toolbar for example.
>> changes do not get noticed for existing tabs. This is
somthing of a problem
>> anyway for XEmacs under X, but I think it is fixable in the case of tabs.
>> If you use X resources to set faces then you should get the right effect.
>> e.g. xemacs -fg red
>
>well i do have that in my .Xresources:
> Emacs*borderColor: #8470ff
> Emacs*menubar: False
> Emacs*foreground: #8470ff
> Emacs*background: black
>
>and the tabs in the first frame that are not the first tab have all a
>white fg instead of a blue one like every other menu item.
>and for the other frames, all tabs have white fg.
Hmmn, what color is #8470ff? That should be the color you are getting.
What do you do in .emacs?
it is a nice blue, and my menubar is using it perfectly well.
the color part in my .emacs follows:
;; my custom faces
(custom-set-faces
'(default ((t (:size "12pt" :family "Fixed" :foreground
"white" :background "black"))) t)
'(gui-button-face ((t (:foreground "#8470ff" :background
"gray10"))) t)
'(secondary-selection ((t (:foreground "black" :background
"paleturquoise"))) t)
'(widget-field-face ((t (:background "black"))))
'(font-lock-string-face ((t (:foreground "#00ff00"))))
'(font-lock-reference-face ((t (:foreground "#ff0000"))))
'(font-lock-doc-string-face ((t (:foreground "#00ff00"))))
'(display-time-time-balloon-face ((t (:foreground "magenta"))))
'(modeline-buffer-id ((t (:foreground "yellow3"))) t)
'(font-lock-preprocessor-face ((t (:foreground "blueviolet"))))
'(modeline-mousable ((t (:foreground "firebrick1"))) t)
'(font-lock-variable-name-face ((t (:foreground "#55ffff"))))
'(widget ((t (:foreground "green" :background "black"))) t)
'(hyper-apropos-hyperlink ((t (:foreground "red"))))
'(font-lock-keyword-face ((t (:foreground "orange"))))
'(font-lock-type-face ((t (:foreground "#ff55ff"))))
'(primary-selection ((t (:background "gray65"))) t)
'(hyper-apropos-documentation ((t (:foreground "blueviolet"))))
'(font-lock-comment-face ((t (:foreground "#ff0000"))))
'(font-lock-function-name-face ((t (:foreground "#8888ff"))))
'(hyper-apropos-major-heading ((t (:foreground "yellow" :bold t))))
'(widget-button-face ((t nil)))
'(modeline ((t (:foreground "#8470ff" :background "black"))) t))
i think it should be the same color than the menubar, but that might
be my own opinion.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
1:31 p.m.
New subject: Continuing problems with current 21.2
At 06:29 PM 8/30/99 +0200, Stef Epardaud wrote:
> >well i do have that in my .Xresources:
> > Emacs*foreground: #8470ff
> > Emacs*background: black
and
'(default ((t (:size "12pt" :family "Fixed"
:foreground "white"
:background "black"))) t)
This is the problem. XEmacs will start using the default face
characteristics that are set by your X resources. When you explicitly set
the default face in custom, this is too late to affect the initial frame,
so you just get you X colors. New frames will get the proper face colors.
It is a bug. When I will get round to fixing it I don't know.
andy
--------------------------------------------------------------
Dr Andy Piper
Senior Consultant Architect, BEA Systems Ltd
1:41 p.m.
New subject: Continuing problems with current 21.2
On Wed, Sep 01, 1999 at 01:31:19PM +0100, Andy Piper wrote:
At 06:29 PM 8/30/99 +0200, Stef Epardaud wrote:
>> >well i do have that in my .Xresources:
>> > Emacs*foreground: #8470ff
>> > Emacs*background: black
and
> '(default ((t (:size "12pt" :family "Fixed" :foreground
"white"
:background "black"))) t)
This is the problem. XEmacs will start using the default face
characteristics that are set by your X resources. When you explicitly set
the default face in custom, this is too late to affect the initial frame,
so you just get you X colors. New frames will get the proper face colors.
now that you put it that way, i looke very stupid indeed :-/
but in fact what i wanted was to have all menus' foreground to #8470ff
but my default face set to white.
is there a proper way to do that?
It is a bug. When I will get round to fixing it I don't know.
yeah, well it is also a mistake from me, but then again, most of tyhe
bug reports i get for my products are not real bugs, but lead me to find
some other bugs completely elsewhere :)
thanx.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
2:40 p.m.
New subject: shouldn't buffers-tab-face be the gutter face?
i thought i read that somewhere in cvs log or i don't remember where,
so i tried to set that face to something other than (quote default)
excactly gui-element-face (which btw i could never figure where it is
used...) which i set to
(gui-button-face ((t (:foreground "#8470ff" :background "gray10")))
t)
in my .emacs .
well i'm still not sure it is supposed to be the gutter face, but if
it is ... well it doesn't work.
i have more and more the feeling that i'm the only one having a black
background for xemacs, a white font and gui items like menus with a
blue fg ... except the gutter thing which listens too much to the
default face when it wants to be a gui element.
--
# Stef Epardaud, # There is no limit to the power of computing ...
# Java Defeater # ... except men maybe ?
# Earth # Lunatech Research,
# Solar System # soon we will quit researching and start finding...
9003
days inactive
9005
days old
11 comments
4 participants
participants (4)
-
Andy Piper -
Hrvoje Niksic -
Olivier Galibert -
Stef Epardaud