December 1999 - XEmacs-Beta - XEmacs Mailing List Archives

Re: check process state before accessing coding_stream (fix PR#1061) 24 years, 11 months

Didier Verna

Stephen J. Turnbull wrote: > If you start under X, won't you get X resources globally for that kind > of thing (menubar strings), regardless of which platform the frame is > on? It depends on how you use the resources. Basically, you have two alternativces: widgets based on Xt benefit automatically from their X resources settings. But you can also define your own set of resources, not related to any kind of widget, and retreive them manually. In the former case, for instance specifying LabelString resources for a Motif menubar, the resources will apply only to Motif menubars. In the latter case, the resources are yours so you do what you want with them. However, you have to be connected to an X display in order to get them. The X resources mechanism is attractive because it does already a fairly important ammount of things for you, a bit like specifiers: you can have different locales on different displays, display/locale/machine specific resources etc. However, using them as the primary method for setting things not related to X only (like colors, faces...) is wrong because it's the lazy way, and it's not as general as what we really need. Even for X-only stuff, using the X resources is arguable. Here's an example that just comes to my mind: take the background pixmap attribute of the default face[2]. This is typically a very-X-related feature that people most probably set in their resources file. But, look, now that Eterm exists, we could perfectly make this attribute work on (some) tty's, by changing Eterm's background. I don't think this would be difficult to implement, but I'm not sure how it would currently behave with respect to X resources and frames opened on both X and Eterm. This shows that even stuff that is traditionally X related would be better thought of in an abstract way. Footnotes: [2] BTW, this attribute annoys me: it's not, or should not be an attribute of the default face. It should be an attribute of the XEmacs frames. Faces should have a 'transparent background property instead. -- / / _ _ 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

1 participants
0 comments

Re: Merging customize support 24 years, 11 months

William M. Perry

Per Abrahamsen <abraham(a)dina.kvl.dk> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Sure. We should really just try to emulate the real font model that is in > > Emacs 21 right now though. This would be a huge win for cross-platform > > setting of font resources. > > In Emacs 21 :bold and :italic are being fased out in favor of :weight > and :slant. :bold and :italic are still recognized by `defface' for > backward compatibility, but not by `customize-face'. > > Do you want XEmacs 21.2 to go the same way? We should stay consistent of course, but what I _really_ meant was that the new face model that Emacs uses internally should be adopted by XEmacs. This is basically moving font.el into the core C code and making it nice and studly. So to make a face in Emacs 21 now, you do: (make-face 'foo) (set-face-attribute 'foo nil :family "lucidatypewriter" :width 'normal :height 200 :weight 'normal :foreground "red" :background "pink" :strike-through t) and you get It keeps a face cache on a per-frame basis. The actual code to implement the font matching is trivial. I think what we'd need to do is add a new device method for 'realize_font' that gets passed a property list. This way if windows wants to support dropcaps or other funky face properties that would be a bitch under X or TTY, it can. -Bill P.

5 participants
8 comments

dl canna (Was: Re: ITP: emacs20-dl and some dl modules for emacs) 24 years, 11 months

Karl M. Hegbloom

I wonder if you've heard of this? Perhaps a dl-wnn and dl-canna would be good additions to XEmacs? >>>>> "Takuo" == Takuo KITAME <kitame(a)northeye.org> writes: Takuo> Hello. I intent to package emacs20-dl. emacs20-dl means Takuo> emacs20 with Dynamic Loading architecture(dl). dl will Takuo> provides by emacs-20.4-dl patch. About dl, Takuo> http://www.m17n.org/mule/dynamic-loading/ (In Japanese) Takuo> [...] Takuo> And I will intent to package some emacs dl modules. Takuo> Modules are dl-wnn, dl-canna and hmac.

2 participants
1 comments

OK I give up 24 years, 11 months

Matthew O. Persico

Maybe it's too much egg nog, but I cannot for the life of me figure out how to change the font for buffer tabs. I tried a few customization variables (I did a C-ha on 'tab') but no dice. Anyone care to point me to TFM I should be R'ing 'cause I'm lost. Thanks. Oh yes - 21.2.24 on Solaris 2.6 -- Matthew O. Persico "Some days, 'user' is a four-letter word."

2 participants
1 comments

Re: OK I give up 24 years, 11 months

Karl M. Hegbloom

>>>>> "Matthew" == Matthew O Persico <mpersico(a)erols.com> writes: Matthew> Maybe it's too much egg nog, but I cannot for the life of Matthew> me figure out how to change the font for buffer tabs. I Matthew> tried a few customization variables (I did a C-ha on Matthew> 'tab') but no dice. Anyone care to point me to TFM I Matthew> should be R'ing 'cause I'm lost. Maybe it's not all there yet... I set `buffers-tab-face' to 'bold, and they have not changed.

1 participants
0 comments

Re: "Fix" for Progressbar crash....(and the Gutters exit?) 24 years, 11 months

Karl M. Hegbloom

On my machine, there is: /usr/X11R6/include/X11/Xaw{,3d} ... and /usr/include/X11 -> ../X11R6/include/X11/ I've found that it is important that /usr/X11R6/lib is BEFORE /usr/X11R6/lib/Xaw3d in /etc/ld.so.conf, otherwise, XEmacs is built with flat athena headers, but run-time links to athena3d. Hope this helps.

6 participants
6 comments

[crash] Assertion failure while using Gnus. 24 years, 11 months

Karl M. Hegbloom

Pressed space in Gnus on a long article with (presumably) either a MIME enclosed or UUencoded photograph in it. I think you've seen this one before. It's done it to me several times. Fatal error: assertion failed, file /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2/src/insdel.c, line 1117, BUFFER_LIVE_P (buf) Program received signal SIGABRT, Aborted. 0x403205d1 in kill () from /lib/libc.so.6 (gdb) where #0 0x403205d1 in kill () from /lib/libc.so.6 #1 0x403202b8 in raise () from /lib/libc.so.6 #2 0x40321911 in abort () from /lib/libc.so.6 #3 0x8086fea in assert_failed () at /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2/src/emacs.c:2825 #4 0x8115ffd in bufpos_to_bytind (buf=0x6, x=0) at /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2/src/insdel.c:1117 #5 0x8080db4 in Fgoto_char (position=0, buffer=136907124) at /usr/local/src/PKG/unstable/main/xemacs/xemacs-21.2/src/editfns.c:223 [...] Let me know if you want the rest of the stack dump, or whatever I can do to help. :) libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6 (0x4001c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x40054000) libpng.so.2 => /usr/lib/libpng.so.2 (0x40097000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400be000) libz.so.1 => /usr/lib/libz.so.1 (0x400de000) libcompface.so.1 => /usr/lib/libcompface.so.1 (0x400ed000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x400f9000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40107000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40119000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40161000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x4016d000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4020c000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40216000) libdl.so.2 => /lib/libdl.so.2 (0x4022c000) libdb.so.3 => /lib/libdb.so.3 (0x40230000) libgpm.so.1 => /usr/lib/libgpm.so.1 (0x4026b000) libncurses.so.4 => /lib/libncurses.so.4 (0x40271000) libesd.so.0 => /usr/lib/libesd.so.0 (0x402b0000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402b8000) libm.so.6 => /lib/libm.so.6 (0x402cb000) libopenldap.so.1 => /usr/lib/libopenldap.so.1 (0x402e8000) liblber-openldap.so.1 => /usr/lib/liblber-openldap.so.1 (0x402fd000) libc.so.6 => /lib/libc.so.6 (0x40302000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

1 participants
0 comments

[crash] More info... 24 years, 11 months

Karl M. Hegbloom

With flat Xaw, the `editable-list-gui' buttons STILL flicker and flash.

1 participants
0 comments

[crash] 24 years, 11 months

Karl M. Hegbloom

[ Cross posted to debian-devel: Please advise. I don't know a lot about this stuff yet. ] I was editting a Debian bug report (against perl-5.005-base; POSIX.pm is broken) with EDITOR set to `xg', my script that runs XEmacs if there's no gnuserv, or gnuclient if there is a gnuserv... I clicked the [Done] button, clicked [Yes] on the dialog box, and XEmacs crashed, with the following to say... (luckily, I just happened to be running it under gdb inside a screen.) Also attached is the Installation file. It linked against Xaw3d/libXaw, even though I told it `athena', not `athena3d'... Hmmm. I wonder if I have the flat athena -dev kit installed even? I'd better check before I send this... It's there. Looks like it's part of the base X11 -dev installation... Hmmm. What's wierd, is that in the filesystem, the symlink from /usr/X11R6/lib/Xaw.so.6 points to Xaw.so.6.1, which is sitting right next to it. In the subdirectory Xaw3d, "libXaw.so.6" (NOT "libXaw3d.so.6") is a symlink back out a level to the libXaw3d.so.6.1 library. All through the (attached) config.log, things are linked with `-lXaw'. When XEmacs starts, it says: /usr/local/src/XEmacs/xemacs-21.2/src/xemacs: Symbol `toggleClassRec' has different size in shared object, consider re-linking /usr/local/src/XEmacs/xemacs-21.2/src/xemacs: Symbol `labelClassRec' has different size in shared object, consider re-linking I will try running with a LD_PRELOAD and see what happens... Hey, in /etc/ld.so.conf, the Xaw3d lib is listed FIRST, at the top of the file. I bet that's what's wrong. Do yous think so? Should I report this as a bug against the Debian Xaw3d package? I think that's the correct course of action here. I'm starting to think I ought not send this after all... Ok, I've verified that if I use a LD_PRELOAD pointing to the flat libXaw.so.6.1, the "Symbol" errors don't print on startup. (And with the same LD_PRELOAD, ldd of course shows the flat libXaw) That is likely what caused this and several other crashes. I can see that it's not the fault of the XEmacs developers, but an error in the system configuration. I will edit /etc/ld.so.conf, and investigate the libXaw3d-dev package. % ldd /usr/local/src/XEmacs/xemacs-21.2/src/xemacs libXaw.so.6 => /usr/X11R6/lib/Xaw3d/libXaw.so.6 (0x4001c000) libtiff.so.3 => /usr/lib/libtiff.so.3 (0x4006f000) libpng.so.2 => /usr/lib/libpng.so.2 (0x400b2000) libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400d9000) libz.so.1 => /usr/lib/libz.so.1 (0x400f9000) libcompface.so.1 => /usr/lib/libcompface.so.1 (0x40108000) libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40114000) libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40122000) libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40134000) libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x4017c000) libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40188000) libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40227000) libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40231000) libdl.so.2 => /lib/libdl.so.2 (0x40247000) libdb.so.3 => /lib/libdb.so.3 (0x4024b000) libgpm.so.1 => /usr/lib/libgpm.so.1 (0x40286000) libncurses.so.4 => /lib/libncurses.so.4 (0x4028c000) libesd.so.0 => /usr/lib/libesd.so.0 (0x402cb000) libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x402d3000) libm.so.6 => /lib/libm.so.6 (0x402e6000) libopenldap.so.1 => /usr/lib/libopenldap.so.1 (0x40303000) liblber-openldap.so.1 => /usr/lib/liblber-openldap.so.1 (0x40318000) libc.so.6 => /lib/libc.so.6 (0x4031d000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

3 participants
2 comments

Macintosh support rolled into 21.2? 24 years, 11 months

William M. Perry

Should we roll the minimal support for MacOS into the 21.2 release? The 20.4 release of Emacs has been folded into the latest releases. http://my.ispchannel.com/~pjarvis/xemacs.html -bp

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