February 2001 - XEmacs-Beta - XEmacs Mailing List Archives

Custom "done" button takes away the current buffer 23 years, 9 months

Konstantin Malakhanov

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 (beta34) "Molpe" [Lucid] (i586-pc-win32) of Fri Jun 09 2000 on NEVERYON configured using `configure UNKNOWN' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: The "done" button in any customization buffer takes away the current buffer, not the customization buffer itself. It is very annoing, if you are sitting in another buffer and press "done" in the customization buffer - the buffer you were in will be gone! (buried or killed) -- Konstantin Malakhanov ISOWARE GmbH, Feithstr. 142, 58097 Hagen, Germany email: km(a)isoware.de Tel: 02331/8019-67 FAX: 02331/8019-99

3 participants
2 comments

Re: Down with weak lists! 23 years, 9 months

Michael Sperber

Reading back my own mail, I can see that I probably wasn't explicit enough about the interface change. Sorry about that. I'm suggesting that there be higher-level interfaces to weak-list-like data structures. - "Simple" weak lists have weak-list-car and weak-list-cdr. - The various types of weak alists have higher-level functions to access them like: weak-list-add-association weak-list-assq weak-list-assoc weak-list-map weak-list-mapc ... This way, people don't need access to the representation. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Down with weak lists! 23 years, 9 months

Michael Sperber

>>>>> "Hrvoje" == Hrvoje Niksic <hniksic(a)arsdigita.com> writes: Hrvoje> sperber(a)informatik.uni-tuebingen.de (Michael Sperber [Mr. Preprocessor]) writes: >> As to the present code base which uses weak lists: >> >> - *No* Lisp code presently. >> >> - Simple weak lists for extend children and frame subwindows which >> would be very easy to convert. >> >> - Specifier alists for windows, a really awkward case which would >> involve somewhat more special-casing as is the case presently. >> >> Are there any objections to this change in principle? Hrvoje> I object. You cannot know whether user code somewhere uses weak Hrvoje> lists. Well, I consider it very highly improbable. Few people understand exactly what they do, and not a single package or core Lisp file uses them presently. Hrvoje> They are very convenient for caching things, so I wouldn't Hrvoje> dismiss the possibility. I'm not suggesting the functionality be removed, I'm only talking about the interface. The current interface exposes too much implementation detail, and is difficult for a generic GC interface to handle. Hrvoje> Your weak-list-car/weak-list-cdr scheme has the flaw of not being able Hrvoje> to handle different *types* of weak lists. Sure it can, but you build on more primitive machinery. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

2 participants
1 comments

Re: Segv running tty gnuclient under an x gnuserv 23 years, 9 months

Jan Vroonhof

[Ben, Tomonori San, am I making sense?] Jan Vroonhof <jan.vroonhof(a)ntlworld.com> writes: > Sounds logical, as this was a major rewrite the of the text glyph code > > 2000-04-02 IKEYAMA Tomonori <tomonori(a)suiyokai.org> > > * redisplay.c (add_glyph_rune): Don't set 0 to bufpos for text > image glyph if allow_cursor. > (add_hscroll_rune): Don't allow cursor to border glyph. > (create_text_block): Ditto. > > * redisplay-output.c (redisplay_move_cursor): Do nothing even if > text not in buffer. > (redisplay_output_layout): Call ensure_face_cachel_complete for > text image glyph. > > > 2000-03-16 IKEYAMA Tomonori <tomonori(a)suiyokai.org> > > * redisplay.c (add_glyph_rune): Adding text image as text runes. > > * redisplay-output.c (redisplay_move_cursor): NO_CURSOR if text > not in buffer > > * redisplay-tty.c (tty_output_display_block): Delete the routine > for text image glyph > * redisplay-x.c (x_output_display_block): ditto > * redisplay-msw.c (mswindows_output_display_block): ditto Here is the relevant part of the patch patch... ＠＠ -1661,10 +1661,32 ＠＠ face = glyph_face (gb->glyph, data->window); if (NILP (face)) - rb.findex = data->findex; + findex = data->findex; else - rb.findex = get_builtin_face_cache_index (w, face); + findex = get_builtin_face_cache_index (w, face); + instance = glyph_image_instance (gb->glyph, data->window, + ERROR_ME_NOT, 1); + if (TEXT_IMAGE_INSTANCEP (instance)) + { + Lisp_Object string = XIMAGE_INSTANCE_TEXT_STRING (instance); + face_index orig_findex = data->findex; + Bytind orig_bufpos = data->bi_bufpos; + Bytind orig_start_col_enabled = data->bi_start_col_enabled; + + data->findex = findex; + data->bi_start_col_enabled = 0; + if (!allow_cursor) + data->bi_bufpos = 0; + add_bufbyte_string_runes (data, XSTRING_DATA (string), + XSTRING_LENGTH (string), 0); + data->findex = orig_findex; + data->bi_bufpos = orig_bufpos; + data->bi_start_col_enabled = orig_start_col_enabled; + return NULL; + } + + rb.findex = findex; rb.xpos = data->pixpos; rb.width = width; rb.bufpos = 0; /* glyphs are never "at" anywhere */ ＠＠ -1675,13 +1697,6 ＠＠ else rb.endpos = 0; rb.type = RUNE_DGLYPH; - /* #### Ben sez: this is way bogus if the glyph is a string. - You should not make the output routines have to cope with - this. The string could contain Mule characters, or non- - printable characters, or characters to be passed through - the display table, or non-character objects (when this gets - implemented), etc. Instead, this routine here should parse - the string into a series of runes. */ rb.object.dglyph.glyph = gb->glyph; rb.object.dglyph.extent = gb->extent; rb.object.dglyph.xoffset = xoffset; Note that for text glpyhs we no longer add the glpyh to the display structure. What if that is that was only reference to the glyph? Does this patch (untested) fix the problem? Index: src/redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.66 diff -u -r1.55.2.66 redisplay.c --- redisplay.c 2000/12/05 05:34:35 1.55.2.66 +++ redisplay.c 2001/02/11 23:57:31 ＠＠ -1676,7 +1676,11 ＠＠ data->findex = orig_findex; data->bi_bufpos = orig_bufpos; data->bi_start_col_enabled = orig_start_col_enabled; - return NULL; + /* We have added the text from the glyph here because + that is clean. However we still add the glyph to + the display structure so it is marked. */ + width = 0; + xoffset = 0; } rb.findex = findex; Index: src/redisplay-x.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-x.c,v retrieving revision 1.23.2.31 diff -u -r1.23.2.31 redisplay-x.c --- redisplay-x.c 2001/01/06 08:21:12 1.23.2.31 +++ redisplay-x.c 2001/02/11 23:57:32 ＠＠ -479,6 +479,10 ＠＠ break; case IMAGE_TEXT: + /* We kept the text glyph for marking + but already added the runes */ + break; + case IMAGE_POINTER: default: abort (); Index: src/redisplay-tty.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay-tty.c,v retrieving revision 1.15.2.18 diff -u -r1.15.2.18 redisplay-tty.c --- redisplay-tty.c 2000/10/31 05:06:25 1.15.2.18 +++ redisplay-tty.c 2001/02/11 23:57:33 ＠＠ -343,6 +343,10 ＠＠ break; case IMAGE_TEXT: + /* We kept the text glyph for marking + but already added the runes */ + break; + case IMAGE_POINTER: default: abort ();

3 participants
2 comments

Re: Your psgml patch. 23 years, 9 months

Adrian Aichner

>>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> |--==> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de> writes: >>>>>>> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de> writes: APA> Hello Steve, Jan! APA> I would like to fix the problem you both seem to be seeing. APA> Could you please send me output of cd oa/psgml; make -d -p bindist SY> Sent to you moments ago. APA> Perhaps these would be helpful as well: APA> OS SY> GNU/Linux 2.4.1 APA> make version SY> GNU make 3.79 GNU Make version 3.79.1, by Richard Stallman and Roland McGrath. Built for i686-pc-cygwin Copyright (C) 1988, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 2000 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Report bugs to <bug-make(a)gnu.org>. APA> shell version SY> GNU bash 2.04 GNU bash, version 2.04.5(12)-release (i686-pc-cygwin) Copyright 1999 Free Software Foundation, Inc. APA> XEmacs version SY> XEmacs 21.2 (beta44) "Thalia" [Lucid] (i686-pc-linux, Mule) (emacs-version) "XEmacs 21.1 (patch 13) \"Crater Lake\" [Lucid] (i386-pc-win32) of Thu Jan 11 2001 on ANDYP" Steve, could you please try to use XEmacs 21.1.XX to build PSGML? Perhaps that's where the problem is. Best regards, Adrian SY> -- SY> |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |------------------------------------<youngs(a)xemacs.org>---| -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

1 participants
0 comments

Re: Your psgml patch. 23 years, 9 months

Adrian Aichner

>>>>> "APA" == Adrian Aichner <Adrian.Aichner(a)t-online.de> writes: Hello Steve, Jan! I would like to fix the problem you both seem to be seeing. I was able to build with my psgml 1.2.2 sync patch applied both on Windows 2000 and linux (shell1.sourceforge.net). Could you please send me output of cd oa/psgml; make -d -p bindist (after running make distclean) or whatever gives any clues what might be wrong. Perhaps these would be helpful as well: OS make version shell version XEmacs version Best regards, Adrian >>>>> "SY" == Steve Youngs <youngs(a)xemacs.org> writes: SY> Hi Adrian SY> I'd really like to commit your psgml patch, but you broke the SY> Makefile. I think it has something to do with this bit: APA> Hi Steve, APA> I have just successfully built psgml with my patch applied on APA> shell1.sourceforge.net, which is a linux system. APA> What platform are you struggling with? APA> Are you using GNU make? APA> Stupid question alert! APA> Have you tried APA> cd oa/psgml; make distclean; make bindist APA> What are the error messages you get? APA> Please send me output of APA> make -d -p bindist APA> Best regards, APA> Adrian SY> ,---- SY> | GET_CDTD_FILES = \ SY> | (progn \ SY> | (find-file \ SY> | \"etc/ECAT\") \ SY> | (princ \ SY> | (replace-in-string \ SY> | (buffer-string) \ SY> | \"^FILE.*[ \\t]+\\\\([^ \\t]+\\\\)[ \\t]*\\n\" \ SY> | \" etc/\\\\1\")))) SY> `---- SY> Just send the fixed Makefile directly to me and I'll commit it with SY> your patch. SY> Thanks. SY> -- SY> |---<Steve Youngs>---------------<GnuPG KeyID: 9E7E2820>---| SY> | XEmacs - It's not just an editor. | SY> | It's a way of life. | SY> |------------------------------------<youngs(a)xemacs.org>---| APA> -- APA> Adrian Aichner APA> mailto:adrian＠xemacs.org APA> http://www.xemacs.org/ -- Adrian Aichner mailto:adrian＠xemacs.org http://www.xemacs.org/

2 participants
1 comments

Re: Segv running tty gnuclient under an x gnuserv 23 years, 9 months

Jan Vroonhof

Robert Pluim <rpluim(a)bigfoot.com> writes: > revision 1.55.2.50 > date: 2000/04/02 14:28:5pwd > 9; author: janv; state: Exp; lines: +29 -14 > Reimplement string glyps > > In fact, taking beta32 and bumping redisplay.c to 1.55.2.50 causes the > bug to happen. Jan, do you have any ideas here? (I know nothing about > the redisplay code) Sounds logical, as this was a major rewrite the of the text glyph code 2000-04-02 IKEYAMA Tomonori <tomonori(a)suiyokai.org> * redisplay.c (add_glyph_rune): Don't set 0 to bufpos for text image glyph if allow_cursor. (add_hscroll_rune): Don't allow cursor to border glyph. (create_text_block): Ditto. * redisplay-output.c (redisplay_move_cursor): Do nothing even if text not in buffer. (redisplay_output_layout): Call ensure_face_cachel_complete for text image glyph. 2000-03-16 IKEYAMA Tomonori <tomonori(a)suiyokai.org> * redisplay.c (add_glyph_rune): Adding text image as text runes. * redisplay-output.c (redisplay_move_cursor): NO_CURSOR if text not in buffer * redisplay-tty.c (tty_output_display_block): Delete the routine for text image glyph * redisplay-x.c (x_output_display_block): ditto * redisplay-msw.c (mswindows_output_display_block): ditto What thi patch did was that instead of using special cased stuff do do display text glyphs, it returns back to the normal textoutput routines. That removes a lot of extra code and as a side effect makes text glyphs mule-aware. Unfortunately I cannot reproduce the crash (although I was lazy and used 'xemacs -q -f gnuserv-start -f display-time instead). For me tty frame comes up with "/path/to/xpm/image/for/clock/digit.xpm" in the modeline and then at the next refresh becomes text. (If I switch focus back to the X frame it changes back to graphics. It seems to me that displaytime is using glyphs in the wrong way. Still XEmacs should not crash). What wonders me is which of the two texts causes the crash. I'll have another look at the change. > The above are my opinions, > and my opinions only. No, their mine as well! :-) Jan

1 participants
0 comments

this is a health check for xemacs-beta. 23 years, 9 months

Adrian Aichner

-- Adrian Aichner <adrian(a)xemacs.org>

1 participants
0 comments

Need a pointer, can't make bindist in packages 23 years, 9 months

Norbert Koch

Hi! I get the following error: [...] (cd /usr/local/users/support/nk/cvs/xemacs-packages/bindist; \ tar --exclude 'CVS' --exclude 'RCS' --exclude 'SCCS' --exclude '*~' --exclude '*.orig' --exclude '*.rej' --exclude '.#*' -cf /usr/local/users/support/nk/cvs/x emacs-packages/bindist/xemacs-base-1.49-pkg.tar \ `cat pkginfo/MANIFEST.xemacs-base`) (cd /usr/local/users/support/nk/cvs/xemacs-packages/bindist; \ gzip -v9 /usr/local/users/support/nk/cvs/xemacs-packages/bindist/xemacs-base-1 .49-pkg.tar;) /usr/local/users/support/nk/cvs/xemacs-packages/bindist/xemacs-base-1.49-pkg.tar : 73.2% -- replaced with /usr/local/users/support/nk/cvs/xemacs-packages/ bindist/xemacs-base-1.49-pkg.tar.gz xemacs -vanilla -batch \ -l package-info -f batch-update-package-info \ '1.49' /usr/local/users/support/nk/cvs/xemacs-packages/bindist/xemacs-ba se-1.49-pkg.tar.gz \ '' \ '' 'XEmacs Development Team <xemacs-beta(a)xemacs.org>' 'libs' Loading /sw/i386_fbsd3/xemacs-21.2/lib/xemacs/xemacs-packages/lisp/gnus/auto-aut oloads... (file auto-autoloads.el is newer) Loading /sw/i386_fbsd3/xemacs-21.2/lib/xemacs/xemacs-packages/lisp/psgml/auto-au toloads... (file auto-autoloads.el is newer) Loading /sw/i386_fbsd3/xemacs-21.2/lib/xemacs/xemacs-packages/lisp/vm/auto-autol oads... (file auto-autoloads.el is newer) Symbol's function definition is void: xemacs-base xemacs exiting . gmake[2]: *** [package-info] Error 255 gmake[2]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/lib s/xemacs-base' gmake[1]: *** [xemacs-base/bindist.target] Error 2 gmake[1]: Leaving directory `/usr/local/users/support/nk/cvs/xemacs-packages/lib s' gmake: *** [libs/bindist.target] Error 2 Any hints? TIA, norbert.

2 participants
2 comments

RE: font-lock problems with 2/9/2001 build 23 years, 9 months

Damon Lipparelli

Unfortunately, this doesn't seem to have had any noticable effect. -lipp ps: I had to hand apply the patch to the most recent 21.2 version of "font-lock.el" (1.76.2.28); I'm attaching what I ended up with.... -----Original Message----- From: Matt Tucker To: XEmacs Beta Cc: Damon Lipparelli Sent: 2/10/01 9:00 PM Subject: Re: font-lock problems with 2/9/2001 build -- Jeff Miller <jmiller(a)cablespeed.com> spake thusly: > Steve Youngs writes: > > |--==> "DL" == Damon Lipparelli <lipp(a)primus.com> writes: > > > > DL> Using the version of "font-lock.el" in the latest 21.2 build > > DL> (revision 1.7.2.28), loading any file which requires > > DL> font-lock seems to peg the CPU. Reverting to revision > > DL> 1.7.2.27 fixes things.... > > > > I'd say this has something to do with Matt Tucker's recent syntax > > table stuff. > > i just cvs'ed today and am running the latest. no problems here, but > i'm also using Ben's recent font-lock patch which I don't think has > made it to cvs yet. I would agree (that it's due to lacking that patch). Damon, do you think you could try the attached patch and see if it fixes the problem? If it does, perhaps Ben should get that patch committed soon? <<font-lock.el-slow.syntax.patch>>

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 February 2001