June 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: sample.emacs to break custom-set-face in 21.2b16 under native NT 25 years, 5 months

Jan Vroonhof

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: Please make sure your .elc are up to date and you are not suffering from the problems the other NT users were seeing. > Jan> Please give the values of the relevant specifiers. > > Sorry, Jan, I don't understand what you mean here. I mean what does (face-font 'default) give you > > Jan> (make-face-unitalic font-lock-comment-face tags '(custom)) > > I am calling this with tags of nil, like custom does. RED ALERT! Custom should be making _all_ its changes with a 'custom tag! > (make-face-unitalic 'font-lock-comment-face nil '(custom)) > ====================================================================== > 1 -> frob-face-property: face=font-lock-comment-face property=font func=mswindows-make-font-unitalic locale=nil tags=(custom) > 1 <- frob-face-property: nil > (make-face-unitalic 'font-lock-comment-face nil '(custom)) Here is probably the problem. There might be some bug in frob-face-property (or the way customize uses it). The use of it with a non-nil tags probably has never been tested very well.. That's all for now, have to go, Jan -- Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Mathematik, vroonhof ＠ math.ethz.ch HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085

1 participants
0 comments

dump-emacs -> dump-emacs-kill-emacs 25 years, 5 months

Olivier Galibert

I'd like to delete the consoles and shut_down_emacs() before dumping, if order to dump the console and device lrecords (3 consoles, 1 device) in a sane state[1]. Any fundamental objections ? OG. [1] Actually, I'd rather not dump them at all, but heh.

2 participants
1 comments

struct lrecord_header size 25 years, 5 months

Olivier Galibert

Fow now, on linux x86 at least (which probably means on all compiles with gcc on 32bits computers I'm afraid), the struct lrecord_header size is 8 bytes. struct lrecord_header { /* index into lrecord_implementations_table[] */ unsigned char type; struct { /* 1 if the object is marked during GC. */ unsigned mark :1; /* 1 if the object resides in read-only space */ unsigned c_readonly : 1; /* 1 if the object is readonly from lisp */ unsigned lisp_readonly : 1; } flags; }; We may want someday to integrate the type into the flags struct to go back to 4 bytes _or_ change the unsigned char to int (which may make the code faster, but probably only when using error checking). OG.

2 participants
1 comments

Re: sample.emacs to break custom-set-face in 21.2b16 under native NT 25 years, 5 months

Adrian Aichner

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> Adrian Aichner <aichner(a)ecf.teradyne.com> writes: >> (custom-set-faces >> '(font-lock-comment-face ((t (:foreground "forest green" :bold t)))) >> '(font-lock-doc-string-face ((t (:foreground "brown" :bold nil))))) >> >> fail to work. Jan> Please give the values of the relevant specifiers. Sorry, Jan, I don't understand what you mean here. >> Colors are OK, but they are rendered italic Jan> given >> (copy-face 'italic 'font-lock-comment-face) Jan> that seems correct. The patch changes the definition of the Jan> customize specs to merge its explicit properties with the Jan> other settings. For most properties that seems like the Jan> correct thing to do and gets rid off all kinds of ugly Jan> problems. >> and I cannot correct them >> via custom. Jan> This however seems like a bug. You should be able to check Jan> [x] italic and with a setting to off to force a non-intalic Jan> face). Could you try calling Jan> (make-face-unitalic font-lock-comment-face tags '(custom)) I am calling this with tags of nil, like custom does. It doesn't work the first time around (returning [default]). Second time it works. Here's what I did (in xemacs -vanilla): (load-file (locate-file "sample.emacs" (list data-directory))) (mapc (function (lambda (f) (trace-function f))) (list (function mswindows-make-font-unitalic) (function mswindows-make-font-italic) (function frob-face-property) )) (make-face-unitalic 'font-lock-comment-face nil '(custom)) ====================================================================== 1 -> frob-face-property: face=font-lock-comment-face property=font func=mswindows-make-font-unitalic locale=nil tags=(custom) 1 <- frob-face-property: nil (make-face-unitalic 'font-lock-comment-face nil '(custom)) ;====================================================================== 1 -> frob-face-property: face=font-lock-comment-face property=font func=mswindows-make-font-unitalic locale=nil tags=(custom) | 2 -> mswindows-make-font-unitalic: font=#<font-instance "Courier New:Italic:10::Western" on #<mswindows-device on nil 0x1b0c> 0x1b25> device=#<mswindows-device on nil 0x1b0c> | 2 <- mswindows-make-font-unitalic: #<font-instance "Courier New:Regular:10::Western" on #<mswindows-device on nil 0x1b0c> 0x2867> | 2 -> mswindows-make-font-unitalic: font=#<font-instance "Courier New:Regular:10::Western" on #<mswindows-device on nil 0x1b0c> 0x1b14> device=#<mswindows-device on nil 0x1b0c> | 2 <- mswindows-make-font-unitalic: #<font-instance "Courier New:Regular:10::Western" on #<mswindows-device on nil 0x1b0c> 0x286f> 1 <- frob-face-property: nil Jan> and if that does not work: Jan> (make-face-unitalic font-lock-comment-face tags) Jan> and may be single step through them to where they don't give Jan> the right result. >From a newly started xemacs -vanilla, using custom, mswindows-make-font-*italic never gets called: (load-file (locate-file "sample.emacs" (list data-directory))) (mapc (function (lambda (f) (trace-function f))) (list (function mswindows-make-font-unitalic) (function mswindows-make-font-italic) (function frob-face-property) )) (customize-face 'font-lock-comment-face) This causes folloging trace, as custom faces are initialized: ====================================================================== 1 -> frob-face-property: face=widget-button-face property=font func=mswindows-make-font-bold locale=nil tags=(custom) 1 <- frob-face-property: nil == [State]: you have set this face, but not saved it for future sessions. utton-face property=font func=mswindows-make-font-bold locale=nil tags=(custom) 1 <- frob-face-property: nil ====================================================================== 1 -> frob-face-property: face=custom-variable-button-face property=font func=mswindows-make-font-bold locale=nil tags=(custom) 1 <- frob-face-property: nil Now I toggle Italic between on and off in the "*Customize Face: Font Lock Comment Face*" buffer and hit the "Set" button after each change. Not much is happening: ====================================================================== 1 -> frob-face-property: face=font-lock-comment-face property=font func=mswindows-make-font-unitalic locale=nil tags=(custom) 1 <- frob-face-property: nil I am way too un-frobbed to understand all of this. Andy? Jan? Happy Weekend, all. Adrian Jan> -- Jan> Jan Vroonhof http://www.math.ethz.ch/~vroonhof/ Jan> Mathematik, vroonhof ＠ math.ethz.ch Jan> HG E16, ETH-Zentrum, Tel: +41-1-6325456/25154 Jan> Raemistrasse 101, CH-8092 Zuerich. Fax: +41-1-6321085 -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: [bug] C-x (space) debug loop with error 25 years, 5 months

Karl M. Hegbloom

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Karl M Hegbloom <psu25682(a)odin.cc.pdx.edu> writes in sb> xemacs-beta(a)xemacs.org: >> With `debug-on-error' turned on, if I push `C-x (space)', I get >> a recurring: Wrong type argument: number-char-or-marker-p, nil sb> I get: Signaling: (undefined-keystroke-sequence sb> [#<keypress-event control-X> #<keypress-event space>]) >> It doesn't happen in `xemacs -vanilla'. Has anyone seen this >> before? It's on my todo list... I'll try and find it if I >> can. sb> The output from `C-h k C-x SPC' will probably tell you where sb> to start looking. -- $BAkHV9f$rF~NO$7$F2<$5$$(B That just blonks with undefined key; if I turn on the debugger, it prints the message you show above, then (apparently) the debugger is erroring with the wta over and over again. I see no changes to `debug.el' in cvs.xemacs.org... Where should I begin looking, I wonder... I guess just comment off all of my site-start.el and init.el, then restart a bunch of times uncommenting each thing in turn. Not today... But at some point I'll do that; maybe next week.

1 participants
0 comments

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

Norbert Koch

Adrian Aichner <aichner(a)ecf.teradyne.com> writes: > Could the functionality of update-elc.sh be moved to lisp sensibly? Hmm, I prefer this to writing a batch file out of maintenance reasons.

1 participants
0 comments

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

SL Baur

Adrian Aichner <aichner(a)ecf.teradyne.com> writes in xemacs-beta(a)xemacs.org: >>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> The build process is supposed to run `temacs -batch -l update-elc.el' sb> before dumping xemacs, update-elc.el takes care of bytecompiling sb> out-of-date elcs, and lib-src/update-elc.sh after dumping. sb> update-elc.sh takes care of bytecompiling the remainder of the core. sb> Is this not happening? > update-elc.el gets run from nt/xemacs.mak. > However, there is no all-elc target in nt/xemacs.mak and > lib-src/update-elc.sh obviously does not get run for an XEmacs native > build where there is no sh. Oh. Right. > What to do? > Could the functionality of update-elc.sh be moved to lisp sensibly? Yup. It depends on how stable the binary is. When update-elc.sh was first done, XEmacs couldn't handle bytecompiling many, many files without crashing. There aren't lots of files to handle any more and many, many bugs have been fixed. You can do it without any Lisp if you put the right kind .el:.elc rule in the Makefile, as is done with xemacs-packages. -- 窓番号を入力してください

1 participants
0 comments

Re: Build failure, xemacs-21.1.2 on rh6-based linux-alpha-unknown 25 years, 5 months

Jan Vroonhof

Valdis.Kletnieks(a)vt.edu writes: > *IF* you compile at -O3 or higher, *and* specify -qansialias, it will > make optimization decisions based on the assumption that there are no > aliasing screws to worry about. Otherwise, it will make pessimistic > assumptions regarding aliasing. OK, thus it is likely that the proportion of AIX XEmacs versions that were compiled like this is extremely small. > Well, the *default* xlc flags don't use aliasing. However, this doesn't > mean that the code is "correct", merely that the compiler doesn't trip > over the problme. The argument put forward by the egcs people is "Other compilers have had this optimization for quite some time, so it is likely that code that runs on multiple compilers is safe." Of course that argument only works if this optimization is normally enabled on those compilers. For AIX at least it seems it isn't. Jan

1 participants
0 comments

Re: [Failure] XEmacs 21.1.2 "2", 20 Minutes to Nikko 25 years, 5 months

Adrian Aichner

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> Vin Shelton <acs(a)xemacs.org> writes in xemacs-beta(a)xemacs.org: >> aichner(a)ecf.teradyne.com said: >>> Hmmh, not any longer. How am I supposed to update to the latest >>> sources? sb> ... >>> Is there a tag I could use to cvs update to 21.1.3? >> No, not yet. I think 21.1.x is still on the mainline. Here's how I >> built a copy of the 21.1.x archive: sb> You don't ever need a tag to update to the latest sources. You only sb> need to specify a branch. Since 21.1.x is the default branch, the sb> latest is what you will get. Yep, I have done that in the past. I wasn't sure whether any policies had hchanged when I didn't get the latest commits. Turned out the commit of version.sh was missing. All is well now. Regards, Adrian sb> -- sb> $B1+$,9_$C$F$$$^$9!#(B -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

Re: NT makefiles broken? [was Re: colourless xemacs on NT :-(] 25 years, 5 months

Adrian Aichner

>>>>> "sb" == SL Baur <steve(a)xemacs.org> writes: sb> The build process is supposed to run `temacs -batch -l update-elc.el' sb> before dumping xemacs, update-elc.el takes care of bytecompiling sb> out-of-date elcs, and lib-src/update-elc.sh after dumping. sb> update-elc.sh takes care of bytecompiling the remainder of the core. sb> Is this not happening? update-elc.el gets run from nt/xemacs.mak. However, there is no all-elc target in nt/xemacs.mak and lib-src/update-elc.sh obviously does not get run for an XEmacs native build where there is no sh. What to do? Could the functionality of update-elc.sh be moved to lisp sensibly? Regards, Adrian sb> -- sb> $B1+$,9_$C$F$$$^$9!#(B -- Adrian Aichner Teradyne GmbH, European Design Center Integra Test Division Telephone +49/89/41861(0)-208 Dingolfinger Strasse 2 Fax +49/89/41861-217 (What is a Fax?) D-81673 MUENCHEN E-mail adrian.aichner(a)teradyne.com

1 participants
0 comments

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

XEmacs-Beta June 1999