March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: Build Failure for Xemacs-21.2.32 24 years, 10 months

Adrian Aichner

>>>>> "Brent" == Brent B Powers <Brent.B.Powers(a)msdw.com> writes: Brent> xemacs.mak, as per Ben's changes, has Brent> !include "config.inc" Brent> But there is no config.inc in the tarball. Copy nt\config.inc.samp nt\config.inc Ben mentioned this in his e-mail, but it was easy to miss. STH, Adrian

1 participants
0 comments

Interesting bug 24 years, 10 months

Andy Piper

It seems if you let bind a constant string, e.g: (let ((mystr "\n")) ...) and then attach an extent to it, if you run this code the extents will *accumulate* rather than replace each other. Semantically when I let bind a constant string I would expect it to be extent free... andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
1 comments

X sequence lost 24 years, 10 months

Michael Sperber

With recent XEmacs, I've occasionally gotten strings of X protocol errors like the attached one. XEmacs dies a horrible death afterwards. With the today's CVS, I've gotten 2 in an hour. Anyone else seeing this? xemacs: X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 1 (X_CreateWindow) Resource id in failed request: 0x2000220 Serial number of failed request: 355649 Current serial number in output stream: 355655 xemacs: X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 1 (X_CreateWindow) Resource id in failed request: 0x2000221 Serial number of failed request: 355650 Current serial number in output stream: 355655 xemacs: X Error of failed request: BadIDChoice (invalid resource ID chosen for this connection) Major opcode of failed request: 1 (X_CreateWindow) Resource id in failed request: 0x2000222 Serial number of failed request: 355678 Current serial number in output stream: 355655 Xlib: unexpected async reply (sequence 0x56ea4)! Xlib: unexpected async reply (sequence 0x56f97)! Xlib: unexpected async reply (sequence 0x57350)! Xlib: unexpected async reply (sequence 0x57491)! xemacs: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 245 () Minor opcode of failed request: 4 Serial number of failed request: 393212 Current serial number in output stream: 357546 Xlib: sequence lost (0x674d7 > 0x574aa) in reply type 0x1! xemacs: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 245 () Minor opcode of failed request: 4 Serial number of failed request: 393212 Current serial number in output stream: 357801 Xlib: sequence lost (0x675d6 > 0x575a9) in reply type 0x1! Xlib: unexpected async reply (sequence 0x57892)! Xlib: unexpected async reply (sequence 0x57c79)! Xlib: unexpected async reply (sequence 0x58016)! Xlib: unexpected async reply (sequence 0x5832d)! Xlib: unexpected async reply (sequence 0x58ccf)! Xlib: unexpected async reply (sequence 0x58e1a)! Xlib: unexpected async reply (sequence 0x5a4c6)! Xlib: unexpected async reply (sequence 0x5a805)! Xlib: unexpected async reply (sequence 0x5b3fb)! Xlib: unexpected async reply (sequence 0x5c890)! Xlib: unexpected async reply (sequence 0x5cb35)! Xlib: unexpected async reply (sequence 0x5cf6d)! -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

Jan Vroonhof

<nic(a)niss.ac.uk> writes: > Sure many Linux distros come with gtk/Qt, but Sun, IBM, etc. boxes[1] > do not, This will probably be change soon because of Mozilla 5/Netscape 6. All it needs one killer app. (Although currently Mozilla takes "killer app" too literal sometimes). Jan

2 participants
1 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

Jens Lautenbacher

wmperry(a)aventail.com (William M. Perry) writes: > sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > > > >>>>> "Jens" == Jens Lautenbacher <jtl(a)schlund.de> writes: > > > > Jens> a) free > > Jens> b) stable enough > > Jens> c) available on enough platforms > > Jens> d) able to at least compete featurewise with the win32 toolkit > > > > Jens> is gtk. > > > > Unfortunately, Gtk doesn't integrate with the X environment. This is the > > most important requirement for native X users. Oh please, it's really funny why I can use gimp or gnome under X then and have a better user experience than with a "real" X app? > This is my biggest gripe with gtk (and Qt to almost the same extent), but > it is not something that is likely to change. If anything people are > bitching the opposite way 'x does not integrate with gnome, therefore it > sucks'. Feh. Indeed. People _will_ do this. Just simply stating that foo doesn't do bar (but which baz does), and completely ignoring that foo on the other hand serves very many other needs of people which baz never came around to deliver, is ridicolous, too. jtl

1 participants
0 comments

21.2.32 (31 too) - most of custom faces got lost 24 years, 10 months

Dmitry Yaitskov

Hi, Subj. I had re-defined most of faces in my XEmacs to use a dark background. All worked well till b31. Now in beta 32 the problem is still there - most of my customized faces look like (also redefined) default face. This is true for at least font lock and gnus. OTOH, modeline faces are fine (I changed them too). My XEmacs is cygwin. -- Cheers, -Dima.

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

Didier Verna

Charles G Waldman <cgw(a)fnal.gov> wrote: > It seems to me to be the GUI toolkit of the future, as opposed to Xt which > is "of the past", IMO. Xt is not much more in the past than X itself. No Xlib-only toolkit can be the "toolkit of the future". Giving up Xt just removes one or two really important problems, but also prevents you from using useful features that people are accustomed to use. The "toolkit of the future" will be "the toolkit using the future replacement for X"[1]. Footnotes: [1] http://www.berlin-consortium.org ? -- / / _ _ 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: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

William M. Perry

sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: > >>>>> "Jens" == Jens Lautenbacher <jtl(a)schlund.de> writes: > > Jens> Now we have a growing set of features that can be used to a varying > Jens> extent on various platforms, and as far as I can tell, for all the nice > Jens> graphics stuff it's the win32 platform that works best. The only toolkit that is > > Jens> a) free > Jens> b) stable enough > Jens> c) available on enough platforms > Jens> d) able to at least compete featurewise with the win32 toolkit > > Jens> is gtk. > > Unfortunately, Gtk doesn't integrate with the X environment. This is the > most important requirement for native X users. This is my biggest gripe with gtk (and Qt to almost the same extent), but it is not something that is likely to change. If anything people are bitching the opposite way 'x does not integrate with gnome, therefore it sucks'. Feh. -bp

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

William M. Perry

Ben Wing <ben(a)666.com> writes: > You wrote to me awhile ago about this and asked about documentation, and I > dictated a response but never got it sent, so here it is: > > I don't think there's any more documentation on how things work under Xt but it > should be clear. The EmacsFrame widget is the widget corresponding to the X > window that Emacs draws into and there is a handler for expose events called > from Xt which arranges for the invalidated areas to get redrawn. I think this > used to happen as part of the handler itself but now it is delayed until the > next call to redisplay. > > However, one thing that you absolutely must not do is remove the Xt > support. This would be an incredibly unfriendly thing to do as it would > prevent people from using any widget set other than Qt or GTK. Keep in > mind that people run XEmacs on all sorts of different versions of X in > Unix, and Xt is the standard and the only toolkit that probably exists on > all of these systems. this is the main reason I suggested getting rid of the (menubar|toolbar)-as-part-of-the-frame paradigm we have now. If we went to just using gutters to hold those things, and had device methods for creating the widgets/etc, all would be well with the world. I think. > Pardon me if I've misunderstood your intentions w.r.t. this. I'd never remove it completely. It would just be in the gtk-aware version that Xt wouldn't be an option. Which is unfortunate. > As for how you would implement GTK support, it will not be very hard to > convert redisplay to draw into a GTK window instead of an Xt window. In > fact redisplay basically doesn't know about Xt at all, except in the > portion that handles updating menubars and scrollbars and stuff that's > directly related to Xt. It looks like redisplay-x.c is fairly 'clean' in that respect. I imagine what I'll end up having to do is reimplement event-Xt.c as event-gtk.c (making sure to handle both gtk and tty events) and probably introduce device-gtk.c, but still use x- as the prefix for everything to avoid rewriting the world to deal with gtk- prefixed equivalents. Xt and gtk are going to be mutually exclusive, so... its not the pretties though. > What you'd probably want to do is create a new set of event routines to > replace the ones in event-Xt.c. On the display side you could conceivably > create a new device type but you probably wouldn't want to do that > because it would be an externally visible change at the Lisp level. You > might simply want to put a flag on each frame indicating what sort of > toolkit the frame was created under and put conditions in the redisplay > code and the code to update toolbars and menubars and so forth to test > this flag and do the appropriate thing. Hmm... I'm going to have to start writing all this up and circulate it. Ahhh, design documents. :) -bp

1 participants
0 comments

Re: A gtk/kde-xemacs... a modest toolbar/menubar proposal... 24 years, 10 months

Jan Vroonhof

Charles G Waldman <cgw(a)fnal.gov> writes: > In particular, I can imagine that patches to Gtk to allow for > simultaneous windows on different displays might be welcome. The snag could be that it would need incompatible interface changes for Gtk. However if the OO in Gtk is done well there shouldn't be that much of a problem. > I intend, when I get some time, to take a closer look at the Gtk > sources to see if this would in fact be a feasable modification. Just remember that the hard part is the error handling. The current Gtk (default) error handling is of the "call exit" type, exactly the same problem as we have on Xt. I would like to see this happen, Jan

1 participants
0 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