March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: More on make-face-larger 25 years, 1 month

Jan Vroonhof

"Kirill 'Big K' Katsnelson" <kkm(a)dtmx.com> writes: > I traced it down to frob-face-property, where I broke a bunch of legs on my > code walk-through. I understand completely. I am the last person to dive deep in the function I think (for the custom specifier stuff, I also fixed some bugs). > If anybody can read this function, that'd be great. Try understanding modify-specifier-instances first. I wrote that for Andy as a "frob-*-property-light". (Frob face property needs to do some more magic with devices). > (specifier-spec-list (face-font 'default)) > => nil This is a nono. frob-face-property assumes that there always is a global value on the default face. Jan P.S. make-face-large needs to be replaced by make-face-size so I can ditch font.el from faces.el completely.

2 participants
1 comments

Re: frequent 21.2b31 crashes on Irix 25 years, 1 month

Gunnar Evermann

"John A. Turner" <turner(a)blueskystudios.com> writes: > yes, I leave the terminal around as well, and I don't background gdb, > but still don't get a lisp backtrace... maybe it's because I'm using > Cygnus' gdb with the Insight frontend? maybe I'll try starting gdb > w/o the GUI and see if that helps... > I don't do that... I just do gdb `which xemacs` in a term window... If you start xemacs under gdb's control (as opposed to using gdb post-mortem to analyse the core dump) then you'll get the gdb prompt back as soon as the fatal signal (ABORT, SEGV,...) is generated, before our signal handler (which in due course would generate the lisp backtrace) is called. You can get the lisp backtrace by either continuing execution from gdb or by calling 'lbt' if you use our .gdbinit. Gunnar

2 participants
1 comments

[comp.emacs.xemacs] cannot build xemacs-21.1.9 on mips-sgi-irix6.5 25 years, 1 month

Vin Shelton

Help Irix users! Can someone help this person (and maybe offer a patch to 21.1.9?) - vin

1 participants
0 comments

Re: Using wget to download packages 25 years, 1 month

Dr. Volker Zell

>>>>> "Rodney" == Rodney Stromlund <Rodney.Stromlund(a)wnco.com> writes: Rodney> I posted on comp.emacs.xemacs to see if there was any interest in using Rodney> wget to download packages as well as efs (for those with ftp port blocked). Rodney> I got some feedback saying to write an http proxy bases ftp client, but Rodney> that is a _lot_ more work than this. So, I wrote some code to use wget Rodney> with the package installation system. Rodney> The major addition I made was a new func called package-file-exists-p. Rodney> This uses wget to download the file and, if successful, returns t. If Rodney> wget fails to download the file, it returns nil. If wget downloading Rodney> isn't requested (via new variable `package-use-wget'), it calls Rodney> file-exists-p. So, this *should not* break existing code. Rodney> This code needs some spit and polish, but I am submitting it now to see Rodney> if there is any interest in including it in the distribution. If not, Rodney> I'll just leave it as is and use it for myself. If there is interest, Rodney> I'll add all the customize features, make sure it works with menus, etc... There is ... Rodney> I'm also cc'ing comp.emacs.xemacs so that those who need it can use it Rodney> and submit changes. I just tested it under the environemnt below and it *works*. System: WinNT 4.0/SP3 - 160 MB Ram Cygwin B20.1 with egcs-2.91.66 - cygwin1.dll - cygwin1-19990929.dll.gz - everything mounted binary, - CYGWIN = tty title binmode ntea nontsec Software: Xemacs-21.1 (XEmacs 21.1 "20 Minutes to Nikko" [Lucid] (i586-pc-cygwin32)) - http://www.xemacs.org/ I would definitely vote for inclusion of your patch as I'm living behind a firewall and can only use http. Ciao Volker

1 participants
0 comments

Re: frequent 21.2b31 crashes on Irix 25 years, 1 month

John A. Turner

>>>>> "JAT" == John A Turner <turner(a)blueskystudios.com> writes: JAT> quick followup... since changing to: JAT> JAT> (setq vm-frame-per-composition nil) (setq vm-frame-per-folder JAT> nil) JAT> JAT> I've seen no crashes >>>>> "GN" == Georg Nikodym <georgn(a)wireless-sys.com> writes: GN> Cool, I'm trying this now. I think I'm seeing the same thing: GN> GN> Fatal error: assertion failed, file /export/georgn/src/xemacs-21.2/src/lisp.h, line 588, RECORD_TYPEP (obj, lrecord_type_cons) GN> GN> ... GN> GN> Lisp backtrace follows: [snip] why couldn't I get a lisp backtrace? had debug-on-error set to t, but all I could get was the backtrace in gdb... -JT

2 participants
2 comments

Re: A real database for Emacs 25 years, 1 month

Jan Vroonhof

"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes: > Jan> Yes, but on many platforms static linking is a no-no anyway. > Jan> Especially binaries for linux distributions (that can control > Jan> the versions of all the libraries) should not be statically > Jan> linked. > > Bull. No its not. There are simply exceptions to the rule. I would be very annoyed if my linux distributor started linking everything static. > There are all sorts of good reasons for static linking, even on > Linux. For example, due to Adobe brain-deadness (sm), the standard > libjpeg is incompatible with Adobe Postscript (tm) usage. So > Ghostscript by default statically links a modified version of libjpeg, > with the Adobe brain-deadness built in. So Ghostscript does not need to be linked with libjpeg but with libadobe-jpeg-braindamage (probably conveniently named libjpeg by the Ghostscript sources.) > (Most Linux distributors ignore this for some reason. Sigh.) Because previously the ghostscript came with its own libjpeg just for convenience. Probably the Ghostscript documentation was not clear enough about the change [which doesn't surprise me because Ghostscripts documentation is at the very least "incoherent"]. Jan

1 participants
0 comments

21.2.25: tab not updated on C-x C-w 25 years, 1 month

Scott Blachowicz

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 (beta25) "Hephaestus" [Lucid] (i586-pc-win32) of Tue Dec 28 1999 on DELTA configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: Don't know if this is fixed in later betas, but...I just noticed that doing `C-x C-w' to write the current buffer to a different filename doesn't change the tab (but does change the modeline). For example, I do C-x C-f foo RET and the tab and the modeline both identify the buffer as "foo". Then, I do C-x C-w bar RET and the tab still says "foo" with the modeline saying "bar". Scott.Blachowicz(a)seaslug.org Recent keystrokes: o t SPC u p d a t e d SPC o n SPC C - x SPC C - w RET C-x 1 C-x k RET C-x k RET C-x k RET C-x C-f C-g c d SPC c : / t e m p RET C-x C-f f o o RET f u b a r SPC f u b a r C-x C-w b a r RET C-x ESC ESC M-p M-p M-p M-p M-p M-p M-n M-n M-n M-n M-n M-n M-n C-g M-x r e p o r t - e m a TAB RET Recent messages (most recent first): Quit Wrong type argument: natnump, -1 Wrote c:/temp/bar In time-stamp-region... In time-stamp-buffer... In sab:trim-trailing-whitespace-region In sab-scan-for-mode... In sab-scan-for-mode... (New file) c:/temp/

2 participants
1 comments

warnings in mule-canna 25 years, 1 month

Didier Verna

I'm annoyed by these warnings (which probably occur also in mule-wnn): /usr/local/src/XEmacs-21.2/src/mule-canna.c: In function `c2mu': /usr/local/src/XEmacs-21.2/src/mule-canna.c:1788: warning: overflow in implicit constant conversion /usr/local/src/XEmacs-21.2/src/mule-canna.c:1793: warning: overflow in implicit constant conversion /usr/local/src/XEmacs-21.2/src/mule-canna.c:1799: warning: overflow in implicit constant conversion /usr/local/src/XEmacs-21.2/src/gutter.c:93: warning: `frame_topmost_window' defined but not used They come from the fact that LEADING_BYTE_LATIN_ISO8859_1 and friends are really consecutive char's, but defined in an enumeration. That's all I had to say :-) -- / / _ _ Didier Verna http://www.inf.enst.fr/~verna/ - / / - / / /_/ / EPITA / LRDE mailto:didier＠epita.fr /_/ / /_/ / /__ / 14-16 rue Voltaire Tel. +33 (1) 44 08 01 77 94276 Kremlin-Bicêtre cedex Fax. +33 (1) 44 08 01 99

2 participants
1 comments

Re: A real database for Emacs 25 years, 1 month

Jan Vroonhof

SL Baur <steve(a)beopen.com> writes: > That is braindamage(TM) that is specifically made taboo in the binary > kit building guidelines. If the libraries were statically linked in > XEmacs binaries for distribution, there wouldn't be that problem. Yes, but on many platforms static linking is a no-no anyway. Especially binaries for linux distributions (that can control the versions of all the libraries) should not be statically linked. Using dlopen is really a much better solution IMO. Jan

2 participants
1 comments

Re: Gutters, backgrounds and flashing 25 years, 1 month

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > >Why does it keep using the "old" background color "OB". > > Because the face the tab uses is not the face of the whole gutter. I wonder > if this would go away if we had a specific gutter face that you could set > (currently defaults to gui-element). If you set gui-element to the same > colors as your tabs, what happens? I have (specifier-spec-list (face-background 'gui-element)) ---> ((global (nil . "Gray80"))) Not white... However I cannot see the white on repainting now as your fix to remove the flicker works too well :-) There is one glitch left. The gutter is not repainted in my new background color after that is set from my custom-set-faces. (From the first gutter painted after that things are OK). Oops just noticed another glitch. If there are two windows that contain buffers already in the tab window, switching the window with C-x o does not bring forward the correct tab. Jan

2 participants
1 comments

2025

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 2000