September 2000 - XEmacs-Beta - XEmacs Mailing List Archives

John A. Turner

[21.2, recent CVS update, Irix 6.5.6m, gcc 2.95.2] refer to this thread from xemacs-nt: http://www.xemacs.org/list-archives/xemacs-nt/200008/msg00008.html a followup indicated that it occurs on Unix as well, but I hadn't seen it until recently - the recipe in the msg works, but substitute the X form of the font, e.g. -*-lucidatypewriter-medium-*-*-sans-*-*-*-*-*-*-*-*" attached are two images that show what happens when flipping between windows in a regular session of XEmacs on Irix for me (not -vanilla) - note the changes in the scrollbar area -- John A. Turner, Ph.D. Senior Research Associate Blue Sky Studios, 44 S. Broadway, White Plains, NY 10601 http://www.blueskystudios.com/ (914) 259-6319

1 participants
0 comments

pcl-cvs doc sync? 24 years, 2 months

Neal D. Becker

I just grabbed/installed pcl-cvs PCL-CVS release v2_9_9. C-h i says: Next: Installation, Prev: (dir), Up: (dir) This info manual describes pcl-cvs which is a GNU Emacs front-end to CVS. It works with CVS version 1.9 and newer. This manual is updated to release 2.5 of pcl-cvs.

1 participants
0 comments

Re: efs bug? 24 years, 2 months

Neal D. Becker

>>>>> "Andreas" == Andreas Jaeger <aj(a)suse.de> writes: >>>>> nbecker writes: >> This is what I get from Manage Packages/list & install: Andreas> Which XEmacs version? Which OS? Andreas> This is AFAIK fixed in XEmacs 21.1.12. Value: "21.1 (patch 11) \"GTK\" XEmacs Lucid"

1 participants
0 comments

Re: efs bug? 24 years, 2 months

Andreas Jaeger

>>>>> nbecker writes: > This is what I get from Manage Packages/list & install: Which XEmacs version? Which OS? This is AFAIK fixed in XEmacs 21.1.12. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.inka.de http://www.suse.de/~aj

1 participants
0 comments

efs bug? 24 years, 2 months

Neal D. Becker

This is what I get from Manage Packages/list & install: 230 Anonymous access granted, restrictions apply. ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> quote cwd /pub/xemacs/packages/package-index.LATEST.pgp/ 550 /pub/xemacs/packages/package-index.LATEST.pgp/: Not a directory ftp> quote cwd /pub/xemacs/packages/ 250 CWD command successful. ftp> ls "-al" /tmp/efselFxdx 200 PORT command successful. 150 Opening ASCII mode data connection for file list. 226 Transfer complete. ftp>

1 participants
0 comments

Widget design [was: Should --with-widgets be the default?] 24 years, 2 months

Stephen J. Turnbull

Moved to -beta because this is general design discussion. >>>>> "Andy" == Andy Piper <andy(a)xemacs.org> writes: Andy> At 07:36 PM 8/23/00 +0900, Stephen J. Turnbull wrote: >> xemacs -vanilla followed by repeated `C-x 2's allows me >> to produce as many tab control widgets as I want, all >> instantiated for the *scratch* buffer. That can't be right. >> Nor do they go away when I start coalescing the windows. Andy> No that *is* correct. See [*] below. Andy> You are creating lots of different domains (windows) and Andy> there has to be a control for each. If you go back to one Andy> window and garbage collect they should go away eventually. This was not true under the pre-(sel.patch) setup, and I banged on that for quite a while. The only thing that ever made them go away was destroying the whole frame. They now go away immediately (with http://www.xemacs.org/list-archives/xemacs-patches/ ... ach, not there yet, look for Andy's patches dated 8/23 and subjects "Re: new dialogs: bug" and "Re: Tab selection crash fix ... NOT!! \"Houston, we, uh, crashed.\"") ***** [*] You are defining "correct" as "works as designed." That is important, of course, but I think that the design is making a lot of assumptions that probably will turn out to be not true for some applications. This will result in more bugs in the future. Above you _equate_ domains to windows. But for the tab control, that's wrong. The domain most relevant to a tab control is a set of buffers. It is true that most of the time the buffer-set to window correspondence is one-to-one and pretty stable. Furthermore, the most likely application (and the one currently implemented) for the tab control is to switch among buffers in a set in a given window. So for the buffer tabs application, this assumption is plausible. But it's wasteful; I don't see any reason at all why a frame should have more than one buffer tabs widget when only one will ever be displayed at a time. It seems to me that from the point of view of Emacs a glyph is really a three-level object. The top level is a specifier, ie, a mapping from domains to instantiation methods. The middle level is the instantiation method for a given domain. The bottom level is the on-screen realization. For a character glyph, the top layers are trivial (ignoring the complexity of faces). For each domain, the instantiation method is to pass the character on. So in the domain, you simply pass the character to the display. The display looks up the bitmap in a font, and blits it to the screen. No computation and no caches needed for handling this kind of glyph. (The display is a black box, I am deliberately abstracting from it here.) For a pixmap glyph from a PNG file, things are somewhat more complex. The top level basically has to decide whether the domain handles pixmaps or not. If it does, it passes the file name to the instantiation method. The method then does some expensive i/o, decodes the pixmap in memory, and passes the pixmap to the display, which then blits it to the screen. Here, the i/o and decoding are expensive, as is passing the pixmap itself (in X11 anyway, as this may involve a fairly large network transaction). So there are two opportunities for caching here, one at the display level, and one of the decoded pixmap. AFAIK we actually have the X server cache the pixmap, and when this image is gc-ed, we call XFreePixmap on the pixmap. Now, we could do exactly the same thing with a widget glyph. No? However, we do want to be more efficient than that. First, let's define a `widget glyph' to be a glyph from the point of view of XEmacs. It is a Lisp object. On the other hand, a `ws-widget' is a toolkit object. There are three differences between widget glyphs and image glyphs that I can see. (1) The entity that handles the ws-widget for us is the toolkit, rather than the display server for the pixmap. Just a different level of black box. (2) ws-widgets are "alive". This means that, unlike pixmaps, we can't just paint over their displayed image; we need to keep track of whether a ws-widget is supposed to be displayed or not, and deactivate is if not. (Of course, we should and do clean up pixmaps too. Otherwise you get those obnoxious birdturds like when font metrics are hosed. But pixmaps don't eat CPU and cause flicker and all that ugliness.) As far as I can see this has no direct implications for caching. (3) A ws-widget is, from our point of view, its own screen image. That means that a widget glyph that is displayed in multiple places in the same domain needs to use multiple ws-widgets. By contrast, we can XCopyArea (or its equivalent for other WSes) an X Pixmap freely. (4) ws-widgets are much heavier objects than even pixmaps. So we would like to avoid creating and destroying them. The question is "how many do we need?" The answer is, typically, "as many as are being displayed at one time in the window system parent." (3) means we need at least that many. But we usually don't need any more, because widgets can be moved about and their features changed as necessary. (3) and (4) together imply that free'd ws-widgets ought to be cached. But they should be cached by the object that determines the restrictions on moving them. In general, this is the window system parent, or, actually the Lisp object that manages that object. (I guess they could even be reparented, but that's a can of worms I'd rather not open. Although I guess if we want to embed an instance of say xanim in an XEmacs buffer, we would need to do exactly that.) In this case, the Emacs frame, not the Emacs window. Of course, if there are other expensive operations to conduct on ws-widgets that would be entailed by using the same ws-widget in multiple domains, the caching strategy should take that into account. But I can't see any that would be forced simply by having two different Emacs windows in the same Emacs frame. In particular, for both the progress gauge and the buffers tab control, they live in the gutter, which is part of the frame, not any particular window. It seems to me that what should happen is that you create a (Lisp) buffers tab control, it instantiates a (ws-widget) tab control for the frame in the gutter, with callbacks to change buffers when it is activated. The same operation should install a Lisp function on some `buffer-configuration-change-hook' which informs the ws-widget about the new set of relevant buffers and the active one. The Lisp tab control object maintains enough state to reinitialize the ws-widget tab control when the Lisp object wants to display itself. I don't see any reason for the tab widget, either the Lisp object or the ws-widget, to know or care about the Emacs window configuration. BTW, some things I find disconcerting about the current behavior: (1) If two buffers in the same mode are displayed simultaneously in the same frame, then using the tab to switch buffers switches windows, not buffers in the current window. This behavior makes sense for the keystroke equivalent, but if I'm moving the mouse anyway click-to- focus makes more sense than using the tab control. If I use the tab control I expect the buffer to end up in the top window. (2) Splitting windows horizontally does _not_ increase the number of tab controls (but seems to work fine). Coalesing horizontally split windows doesn't decrease the number of tab controls, either. -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

2 participants
3 comments

Re: [Palle Girgensohn <girgen@partitur.se>] Re: pcl-cvs bug: Cannot open load file: mule 24 years, 2 months

Andreas Jaeger

>>>>> Michael Sperber writes: > I got this report. Andreas or Steve, can this be fixed? [...] > OK. Thanks. BUT, the package list (package-index.LATEST is bad! It has > both 1.47 and 1.49 listed, hence I get this with a fresh package index > file: The package-index is the worst part of the whole package scheme. I seem to have problems with it every release :-(. Any ideas to get rid of this file are welcome. I've edited the file manually on ftp.xemacs.org, it should be fixed now. Andreas -- Andreas Jaeger SuSE Labs aj(a)suse.de private aj(a)arthur.inka.de http://www.suse.de/~aj

1 participants
0 comments

[Palle Girgensohn <girgen@partitur.se>] Re: pcl-cvs bug: Cannot open load file: mule 24 years, 2 months

Michael Sperber

I got this report. Andreas or Steve, can this be fixed? -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: gtk-xemacs shrink windows 24 years, 2 months

William M. Perry

Simon Josefsson <simon(a)josefsson.org> writes: > (Is this the proper place for gtk-xemacs bug reports?) > > Entering/Quiting groups in Gnus seem to horizontally shrink the XEmacs > window by a few pixels. I assume this is because the menubar change. > > After reading some groups, you find yourself with a rather smallish > xemacs window.. :-) This should be fixed in the latest CVS snapshot. Fawking menubar. -Bill P.

1 participants
0 comments

syntax-table text properties 24 years, 2 months

Matt Tucker

Greetings, My apologies if this is not the proper forum for this; it seemed the most appropiate at first glance. I've been using XEmacs for some time, having transitioned from FSF Emacs about a year ago. While I very much prefer it overall, the one thing I've missed is correct handling of Perl code. As far as I've been able to make out, the primary feature preventing XEmacs from correctly dealing with Perl code (due to its general hairyness) is the concept of attaching overriding syntax-tables to specific characters in a buffer. This functionality was introduced in FSF Emacs between v19.33 and v20.2. I've been told that some effort was made to introduce this feature to the XEmacs folks, but that there was little interest. I'm willing to do the work required to incorporate this functionality, but I wanted to be sure that my changes would be accepted, and would be in line with the general philosophies of XEmacs development (which seem to differ from FSF's in a number of ways). The changes I'm proposing (as taken from FSF Emacs) are essentially: 1. A new text property 'syntax-table, which is one of: - a syntax table Used instead of the buffer's to determine the syntax for this character - (syntax-code . matching-char) Specifies the syntax for this occurence of the character I'm assuming 'matching-char' would be the balancing character, although I haven't been able to determine whether this is the case from the FSF code/documentation - nil Equivalent to the property not existing: default to the buffer's syntax table 2. Two new syntax classes: - generic comment delimiter Starts or ends a special kind of comment. Any generic comment delimiter matches any other comment delimiter, but not a comment starter or comment ender. Intended for use in the syntax-table text property. - generic string delimiter Analagous to the generic comment delimiter, for strings. These are the classes added in FSF Emacs, presumably to account for the case where the language could allow one type of comment embedded within another type. One would not want the embedded comment to end the enclosing one. But it also seems like 'generic-*-starter' and 'generic-*-ender' would be required to avoid ambiguity. An example of this sort of situation in Perl would be the string: qq(This string shouldn't be terminated by the apostrophe.); 3. Modifications to the syntax handling routines to honor occurrences of the syntax-table property for characters which have it set. Any code which currently requests the syntax type for a given character would have to first examine that character's 'syntax-table property before defaulting to the buffer's table. FSF Emacs uses the concept of a 'global syntax state' which is maintained and updated as the pointer is moved through the buffer by the syntax handling routines. This seems overkill to me, since the correct syntax type could simply be determined for any given character position on demand. I would appreciate any comments anyone might have on this. Please CC me, as I'm not subscribed to the list.

2 participants
1 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 September 2000