March 1999 - XEmacs-Beta - XEmacs Mailing List Archives

crashes on SGI (old compiler) 25 years, 8 months

John A. Turner

If anyone is successfully building on SGI using the old 7.1 compilers, please get in touch with me. I'm no longer on the list, but I thought I'd try building 21.2.12 on Irix. I've never been able to compile on this platform using the -n32 option (and -mips3), but I got farther this time. Compilation completed, but the executable usually barfs on startup (with -vanilla). If not at startup, then shortly thereafter. Yes, I've looked at PROBLEMS and this doesn't seem to be covered. I don't want to go on too much about it here, since these compilers are old and somewhat problematic anyway (had to back off optimization for md5.c from -O3 to -O1 to prevent apparently infinite compile time). Anyway, if anyone is successful on this platform, please get in touch. I have lisp backtraces and such. This couldn't be a mule thing, could it? I used the latest SUMO tarball (1999-03-05) and build w/o mule... Thanks, -- John A. Turner, Ph.D. Senior Research Associate Blue Sky Studios http://www.blueskystudios.com/ One South Road, Harrison, NY 10528 http://www.lanl.gov/home/turner/ Phone: 914-381-8400 http://john.turner.org/ Info on Blue Sky's fully computer-generated, Oscar-nominated short film: http://bunny.blueskystudios.com/ You've never seen computer-generated images like this...

1 participants
0 comments

Re: [21.0, repost with more Rationale] Mix X resources with Custom 25 years, 8 months

Jan Vroonhof

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > C. [ X ressources overrides ] > Initialize face as specified by defface or saved customize settings. > Change face according to X ressources. Aha.. I missed that although the resource setup call is not in face-spec-set, it is called later on. However it seems that in the custom face editor this is not the case. Again this only from source inspection. I really should install FSF 20.3 sometime. Anyway, I think my patch is even more correct now :-). Jan

2 participants
1 comments

Re: Patches Not Yet Applied to 21.2 25 years, 8 months

Jan Vroonhof

Vin Shelton <acs(a)xemacs.org> writes: > applied OK. Apologies if any of these patches have already been > rejected, > Message-ID: <13876.35228.330418.385565(a)tanko.sk.tsukuba.ac.jp> Subject: [patch] make reset-face a no-op for 'default face I am not sure but I think this patch has been superseded by other patches that have been applied. > Message-Id: <199810280256.CAA24714(a)moomin.cs.ie.niigata-u.ac.jp> Subject: patch for fileio.c Sometimes even XEmacs disappoints you. I sort of expected to be able to mouse-2 on the message-d and be taken right to the patch :-) > I hope this is useful to someone. It is. thanks alot. Jan

1 participants
0 comments

[21.0, repost with more Rationale] Mix X resources with Custom 25 years, 8 months

Jan Vroonhof

[I posted this patch before. It is annoying not know whether it has been forgotten or is just the subject of hot debate on xemacs-review] Rationale: The current interaction of XEmacs 21.0's custom with the Xresources is an inconsistent and non-intuitive mess. Both the X resources and Custom settings specify the font only incompletely. The problem occurs when there are BOTH X resource and Custom settings. Then there are basically two recipes/interpretations A. [Custom is complete] if there are ANY custom settings for the face) Take default settings. Apply changes in custom specifications. else Take default settings. Apply changes in resources. B. [Custom overrides] Take default settings. Apply changes in resources. Apply changes in custom specifications. Status Quo: XEmacs 21.0 uses A for the 'default face and B. for others! FSF 20.3 uses A (conclusion from code inspection only!). XEmacs 20.4 uses B! (with a wrong value for "default settings"[1]). Problems: XEmacs 21.0 is inconsistent. XEmacs 21.0 is incompatible with 20.4. Some annoying user inter face problems (see Con using A). Proposed solution: Make XEmacs 21.0 use B. Always with the below patch. Other solutions: Make XEmacs 21.0 use B always (remove the init-face-from-resources settings in face-spec-set). + document change in NEWS. Pro's and Cons'. Pro using A: - Compatible with FSF 20.3 - One could argue this is the right interpretation. That attributes arguments in the custom spec are just a form of writing minimal data. However I think the way the customize face editor is implemented suggests otherwise. Also the current call to init-face-from-resources makes no sense then. Cons using A: - Incompatible with XEmacs 20.4 - It seems to be very unintuitive. I have seen a lot of complaints already from Xresources users. They expect setting the back ground color using resources to be independent of setting the font size using custom. Note that this kind of mixing will become more common in 21.0 because the font-menu now uses customize. i.e. unsuspecting user uses font-menu ---> bingo his background is gray again. Cons of using this patch: - It introduces yet another subtle change in the font behaviour. [if you want you can leave the 'x tag bit for 21.2. I have only tested this version though.] 1999-02-19 Jan Vroonhof <vroonhof(a)math.ethz.ch> * x-faces.el (x-init-global-faces): Add default tag to specifiers, so they can be overridden by x-init-face-from-resources. Additionally specify the font name also with an x tag. Index: x-faces.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/x-faces.el,v retrieving revision 1.13 diff -u -u -r1.13 x-faces.el --- x-faces.el 1999/03/05 14:06:20 1.13 +++ x-faces.el 1999/03/11 01:23:43 ＠＠ -602,12 +602,12 ＠＠ (defun x-init-global-faces () (or (face-font 'default 'global) (set-face-font 'default - "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*") - 'global) + "-*-courier-medium-r-*-*-*-120-*-*-*-*-iso8859-*" + 'global '(x default))) (or (face-foreground 'default 'global) - (set-face-foreground 'default "black" 'global 'x)) + (set-face-foreground 'default "black" 'global '(x default))) (or (face-background 'default 'global) - (set-face-background 'default "gray80" 'global 'x))) + (set-face-background 'default "gray80" 'global '(x default)))) ;;; x-init-device-faces is responsible for initializing default ;;; values for faces on a newly created device. Footnotes: [1] I have seen only one report about this on c.e.xemacs which seems to suggest to me almost all people change the default gray to something else.

2 participants
1 comments

Re: font lock frustration in 21.0.65 25 years, 8 months

Didier Verna

Geoffrey Furnish writes: Geoffrey> Oh yeah, I forgot to mention that I tried doing that, and it didn't Geoffrey> work either. I also read the font-lock.el and concluded that it was Geoffrey> saying that <mode-name>-font-lcok-keywords was the most Geoffrey> authoritative setting. Personnaly, I have a 'setq on c++-font-lock-keywords-3 in my init file, and it works well (I use maximal decoration). -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

1 participants
0 comments

Re: font lock frustration in 21.0.65 25 years, 8 months

Didier Verna

Geoffrey Furnish writes: Geoffrey> (setq c++-font-lock-keywords c++-font-lock-keywords-gmf) Geoffrey> (add-hook 'c++-mode-hook '(lambda () (setq font-lock-keywords Geoffrey> c++-font-lock-keywords-gmf))) In general, when the first solution fails, it's often because of a fontification level magic that goes under you feet. Remeber that you have several levels of fontification controled by `font-lock-maximum-decoration'. In other words, it's safer to modify c++-font-lock-keywords-[1|2|...] and let the code decide which one it will use (which in turn sets c++-font-lock-keywords on the fly). 'makes me remember: currently, some keywords are defvar'ed in font-lock.el, some others are in their respective packages. This should be fixed (I mean decided once for all) one day. -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / E.N.S.T. INF C201.1 mailto:verna＠inf.enst.fr /_/ / /_/ / /__ / 46 rue Barrault Tel. (33) 01 45 81 73 46 75634 Paris cedex 13 Fax. (33) 01 45 81 31 19

2 participants
1 comments

Re: Probelm with VM in 21.0.65 25 years, 8 months

Jan Vroonhof

Geoffrey Furnish <furnish(a)actel.com> writes: > I have built 21.0.65 on both Linux and Solaris 2.6. I am using sumo > tarball from 3/5/99. On both systems, executing M-x vm, or hitting my > mail button on the tool bar which was previously customized to vm, > results in an error in the message box. Error says: There was a build problem with the VM package in that tarball. Wait for tommorows new tarball. Tip: Always try to see if there is a new package before reporting problems. Options->Manage Packages->List & Install will help you. Jan

1 participants
0 comments

font lock frustration in 21.0.65 25 years, 8 months

Geoffrey Furnish

Hello again, Another problem I've been having. Again with 21.0.65, but also with various 21 strain betas I've tried over the last few months. I have lots of font-lock-keyword definitions I've historically used in preference to the default ones. I used to be able to reliably configure my font lock colorization by putting in my .emacs, things like: (setq c++-font-lock-keywords c++-font-lock-keywords-gmf) and then whenever I'd load a C++ file, font lock would set font-lock-keywords to the value of c++-font-lock-keywords. Well, that's still how the documentation reads in the font lock code, but in the 21 strain betas, it doesn't seem to work for me. I've been trying to figure this out for a couple of months (okay, I'm not so hot with elisp, just kind of blundering about in the mist), but recently I finally recovered what I was after by doing this: (add-hook 'c++-mode-hook '(lambda () (setq font-lock-keywords c++-font-lock-keywords-gmf))) which is probably proof that I'm an elisp bozo, but anyway, I can't find any other way to get my own keyword alists to overide the ones built into XEmacs. Is this a bug in the XEmacs 21 betas, or can someone explain to me how the situation with personal customization of such things may have changed since the 20 series XEmacsen? This is the one area of XEmacs that seems to give me frustration every time I upgrade, so I always check the FAQ, and it doesn't address this kind of thing. I would be willing to contribute some prose on the subject, if only I knew what to say! Thanks. -- Geoffrey Furnish Actel Corporation furnish(a)actel.com Senior Staff Engineer 955 East Arques Ave voice: 408-522-7528 Placement & Routing Sunnyvale, CA 94086-4533 fax: 408-328-2303

1 participants
0 comments

Re: Fix for crash: skip-syntax-backward("_w") 25 years, 8 months

Jan Vroonhof

Gunnar Evermann <ge204(a)eng.cam.ac.uk> writes: > > * search.c (skip_chars): Work around gcc compiler bug. > > Fix long-suffering skip-syntax-backward crash. > > I personally think this is a Good Thing[TM] but didn't we decide not > to work around this bug? If read the solution correctly it is another case of the problem where a function/code (possibly with side effects) given as an argument to the function is not executed at the right point (i.e. before the function call) when the compiler is optimizing (and presumably doing some inlining). If that is this the case then I remember seeing comments that XEmacs is working around these problems at other points in the code. If it is OK there, it is OK here. Jan

2 participants
1 comments

XEmacs aborts without nice messages if it can't find itself 25 years, 8 months

Hamish Macdonald

This bug report will be sent to the XEmacs Development Team, not to your local site managers!! Please write in English, because the XEmacs maintainers do not have translators to read other languages for them. In XEmacs 21.2 "Clio" [Lucid] (sparc-sun-solaris2.7) of Tue Mar 9 1999 on rhea configured using `configure --prefix=/export/users/hamishm --verbose --site-prefixes=/export/users/hamishm' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Around line 1695 of emacs.c, XEmacs does some DLL initialization using the value of Vinvocation_directory. I was running XEmacs in batch mode from a cron job, and it looked like the shell was finding xemacs OK, but was passing argv[0] as "xemacs", but passing a PATH which didn't include the executable directory. As a result of this, Vinvocation_name was set to "xemacs", and Vinvocation_directory was set to nil. During the DLL initialization, some code attempts to access string properties of Vinvocation_directory. Since we are doing error checking, this results in an abort. I think that a less drastic error message could be presented (in fact, without the HAVE_SHLIB definition, I think that I would get the standard "emacs can't find its environment" stuff I vaguely recall from the past. Hamish.

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 March 1999