February 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Re: widget and tabs fix 24 years, 3 months

ALTMARK＠de.ibm.com

Thanks, Andy, this fixes things for me. The only two issues left (apart from that widget-don't-fill-frame stuff) as far as I can see: The buffers-tab face problem Karl has reported. In b28, I was also able to set at least foreground and background color. This doesn't work anymore under b29. It looks like that sometimes tabs are still visible whose corresponding buffers already have been killed. E.g.: xemacs -vanilla (Splash buffer appears and *scratch* tab is shown) C-x C-f .emacs RET (First *scratch* buffer is displayed and then the desired file. *scratch* and .emacs tabs are visible.) M-x kill-this-buffer RET (.emacs buffer disappears, *scratch* is displayed, BUT: still *scratch* AND .emacs tabs are visible. Selecting the .emacs tab shows an empty buffer.) M-x list-buffers RET (.emacs buffer is still in the buffer list. I can mark it to be deleted and press 'x' and now the empty .emacs buffer is gone.) Markus

1 participants
0 comments

Re: Stop mswindows leaking DDE strings 24 years, 3 months

Adrian Aichner

>>>>> "Jonathan" == Jonathan Harris <jhar(a)tardis.ed.ac.uk> writes: Jonathan> Kirill wrote: >> * event-msw.c (mswindows_dde_callback): Extraneous ';' removed. >> >> - I do not understand the DDE code either. Like with the previous >> fix, side effects can reveal themselves. Jonathan> I'm not sure that I understand it either - and I wrote Jonathan> it. Your fix looks correct. The only reason why the code Jonathan> worked before is that it is never called in practice. Jonathan> While looking at the DDE code I found this additional problem: Jonathan> 2000-02-13 Jonathan Harris <jhar(a)tardis.ed.ac.uk> Jonathan> * device-msw.c (mswindows_delete_device): Jonathan> Free DDE string handles. Hi Jonathan, hi All, file handle leakage appears to be fixed in xemacs-21.1.9. Before, running M-! (shell-command) dir RET would increment the open handle count by two. Now the handles are closed when the shell-command finishes. Great, now I will stay well below my usual 500 open file handles :-) Cheers, Adrian

1 participants
0 comments

Re: widget and tabs fix 24 years, 3 months

Karl Kleinpaste

Karl Kleinpaste wrote: >> Unfortunately, the customization of the tab face still doesn't >> take, as seen in the MIMEd .gif below. Andy Piper <andy(a)xemacs.org> writes: > Looks as expected to me. What were you expecting to see? I customize this to use black-on-wheat tabs: '(buffers-tab ((t (:foreground "black" :background "wheat"))) t) But in the .gif I sent, showing the customize buffer in which that selection was made, you can also see that the tab for the customize buffer itself is still black-on-white.

1 participants
0 comments

Re: Gnus broken with current CVS XEmacs 21.1.9 version 24 years, 3 months

Jason R Mastaler

Vin Shelton <acs(a)xemacs.org> writes: > What is the status of this? Jason Mastaler reported that the latest > CVS gnus does not work against 21.1.9; is there a patch for XEmacs? There is now a patch for Gnus. See <URL:http://www.gnus.org/list-archives/ding/200002/msg00194.html> Florian Weimer tells me he has committed it to Gnus CVS. I don't know whether this alleviates the need for an XEmacs patch or not.

1 participants
0 comments

Re: Gnus broken with current CVS XEmacs 21.1.9 version 24 years, 3 months

Vin Shelton

What is the status of this? Jason Mastaler reported that the latest CVS gnus does not work against 21.1.9; is there a patch for XEmacs? - vin >>>>> On 08 Dec 1999, Yoshiki Hayashi <t90553(a)m.ecc.u-tokyo.ac.jp> said: Yoshiki> Andreas Jaeger <aj(a)suse.de> writes: Yoshiki> Then, Gnus wasn't running fine on XEmacs 21.2 for some Yoshiki> months? According to the ChangeLog XEmacs 21.2 has Yoshiki> coding-system-get after 1999-06-28. >> >> No, it should have worked for 21.2 since lisp/mule/mule-charset-el >> has: (defalias 'get-charset-property 'get) Yoshiki> Err, sorry, now I understand the problem. I thought it was Yoshiki> (coding-system-get ... 'mime-charset) thing. Yoshiki> [...] >> >> >> Two problems with the code: >> >> >> >> The first one is XEmacs: >> >> XEmacs now has coding-system-get - but it doesn't have >> >> get-charset-property. If we have coding-system-get should we also >> >> have get-charset-property? >> Yoshiki> Yes, it would be nice if we have them. Yoshiki> But then again, this is MULE API problem. Some codes are Yoshiki> synched with FSF and some codes are not. We really really Yoshiki> really need to define API and stick with them. Until that Yoshiki> happens, application needs to have workaround. This case, Yoshiki> Gnus. >> >> Should we move those to 21.2 also? Yoshiki> ^^^^ Yoshiki> You mean 21.1. >> 1999-05-26 SL Baur <steve(a)gneiss.etl.go.jp> >> >> * mule/mule-charset.el (charset-after): New function. >> (charset-direction): Synch with Mule, update docstring. >> (get-charset-property): New function. >> (put-charset-property): New function. >> (charset-plist): New function. Yoshiki> Probably yes, as we know it makes Gnus happy. Like Yoshiki> coding-system-get, it doesn't behave the way FSF does, Yoshiki> though. This is caused by the two big problems XEmacs/MULE Yoshiki> has: No API, bad interaction between mule-base and core. Yoshiki> I guess this will continue for a while. Sigh. Yoshiki> -- Yoshiki> Yoshiki Hayashi

1 participants
0 comments

Crash in Latest 21.2 from CVS 24 years, 3 months

Vin Shelton

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 (beta29) "Hestia" [Lucid] (i686-pc-linux) of Thu Feb 17 2000 on zion.ne.mediaone.net configured using `configure --prefix=/usr/local/xemacs-21.2-2000-02-17 --with-gcc --site-includes=/usr/local/include --site-libraries=/usr/local/lib --infopath=/usr/local/info --with-mule=no --compiler=/usr/bin/gcc '--cflags=-O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-math -fno-exceptions' --with-dialogs=no --with-widgets=no --package-path=/usr/local/xemacs-packages' Please describe exactly what actions triggered the bug and the precise symptoms of the bug: I was moving the mouse (perhaps over the modeline) and kaboom! Here's the backtrace: #0 0x402902d1 in __kill () from /lib/libc.so.6 #1 0x8085d79 in fatal_error_signal () #2 0xbfffed24 in ?? () #3 0x8085cde in assert_failed () #4 0x80f60cc in text_query_geometry () #5 0x80f5aaa in image_instance_layout () #6 0x80f2f45 in instantiate_image_instantiator () #7 0x80f807d in image_instantiate () #8 0x80891ba in call_with_suspended_errors_1 () #9 0x808956e in call_with_suspended_errors () #10 0x8164079 in specifier_instance_from_inst_list () #11 0x81643ba in specifier_instance () #12 0x80d116a in update_face_cachel_data () #13 0x80d1a0e in get_builtin_face_cache_index () #14 0x80d3b8a in reset_face_cachels () #15 0x8141bb9 in redisplay_window () #16 0x814279d in redisplay_frame () #17 0x8142a8a in redisplay_device () #18 0x8142d45 in redisplay_without_hooks () #19 0x8149c88 in redisplay () #20 0x80ba10b in Fnext_event () #21 0x806b1d8 in Fcommand_loop_1 () #22 0x806b43f in command_loop_1 () #23 0x80881cb in condition_case_1 () #24 0x806b582 in command_loop_2 () #25 0x808f130 in internal_catch () #26 0x806a9f4 in initial_command_loop () #27 0x8084014 in xemacs_21_2_b29_i686_pc_linux () #28 0x80847da in main () #29 0x402894a5 in __libc_start_main () from /lib/libc.so.6 #30 0x815b0000 in ?? () Cannot access memory at address 0xe853. (gdb) Recent keystrokes: button1 button1up M-x r e p o r t - TAB RET Recent messages (most recent first): Loading emacsbug...done Loading emacsbug... Loading emacs...done Loading pending-del...done Loading pending-del... Loading byte-optimize...done Loading byte-optimize... Loading bytecomp...done Loading bytecomp... Loading /home/acs/.recent-files.el...done Here's the installation info: uname -a: Linux zion.ne.mediaone.net 2.2.15pre7 #3 SMP Wed Feb 9 22:10:20 EST 2000 i686 unknown /usr/local/src/xemacs-21.2-2000-02-17/configure '--prefix=/usr/local/xemacs-21.2-2000-02-17' '--with-gcc' '--site-includes=/usr/local/include' '--site-libraries=/usr/local/lib' '--infopath=/usr/local/info' '--with-mule=no' '--compiler=/usr/bin/gcc' '--cflags=-O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-math -fno-exceptions' '--with-dialogs=no' '--with-widgets=no' '--package-path=/usr/local/xemacs-packages' XEmacs 21.2-b29 "Hestia" configured for `i686-pc-linux'. Where should the build process find the source code? /usr/local/src/xemacs-21.2-2000-02-17 What installation prefix should install use? /usr/local/xemacs-21.2-2000-02-17 What operating system and machine description files should XEmacs use? `s/linux.h' and `m/intel386.h' What compiler should XEmacs be built with? /usr/bin/gcc -O3 -malign-double -pipe -march=pentiumpro -mcpu=pentiumpro -ffast-math -fno-exceptions Should XEmacs use the GNU version of malloc? yes (Using Doug Lea's new malloc from the GNU C Library.) Should XEmacs use the relocating allocator for buffers? no What window system should XEmacs use? x11 Where do we find X Windows header files? /usr/X11R6/include Where do we find X Windows libraries? /usr/X11R6/lib Additional header files: /usr/local/include Additional libraries: /usr/local/lib Athena library to link: Xaw Athena header include path: X11/Xaw Compiling in support for XAUTH. Compiling in support for XPM images. Compiling in support for PNG image handling. Compiling in support for (builtin) GIF image handling. Compiling in support for JPEG image handling. Compiling in support for TIFF image handling. Compiling in support for X-Face message headers. Compiling in native sound support. Compiling in support for Enlightened Sound Daemon (ESD). Compiling in support for Berkeley DB. Compiling in support for ncurses. Compiling in support for GPM (General Purpose Mouse). Compiling in support for proper WM_COMMAND handling. Using Lucid menubars. Using Lucid scrollbars. Compiling in dynamic shared object module support. movemail will use "dot-locking" for locking mail spool files. Compiling in extra code for debugging. WARNING: --------------------------------------------------------- WARNING: Compiling in support for runtime error checking. WARNING: XEmacs will run noticeably more slowly as a result. WARNING: Error checking is on by default for XEmacs beta releases. WARNING: --------------------------------------------------------- - vin

1 participants
0 comments

Portable dumper ideas 24 years, 3 months

Martin Buchholz

I had trouble understanding the alignment code, especially align_table. Ideas: Use ALIGNOF maybe? The maximum alignment required should be perhaps (from opaque.h) typedef union { struct { Lisp_Object obj; } obj; struct { void *p; } p; struct { double d; } d; } max_align_t; We could move max_align_t to lisp.h, and have size_t max_alignment = ALIGNOF (max_align_t); Wouldn't we get a tremendous performance boost by having the lrecord_implementations_table indices be constant? We would lose a level of indirection on every FOOP, because it would not have to examine lrecord_implementations_table itself.

3 participants
11 comments

widget and tabs fix 24 years, 3 months

Andy Piper

This should fix all the tab redisplay problems under X as well as some that were introduced under mswindows. I am also hopeful that this fixes the crashes that some were seeing. Please try this out and let me know of anything that doesn't work. The only thing I currently have outstanding to fix is the fact that the tab widget doesn't fill the frame so colors can look a little odd. Martin if this cures things for people it would be nice if 21.2.30 could be soon. andy 2000-02-17 Andy Piper <andy(a)xemacs.org> * redisplay.h: declare mark_redisplay_structs. * redisplay.c (redisplay_window): (redisplay_frame): don't check subwindows_state_changed. (mark_redisplay): mark gutters here. * glyphs.c: (instantiate_image_instantiator): always layout if we haven't done so already. (allocate_image_instance): don't mark as dirty. (update_subwindow): bind inhibit_quit. * gutter.c (mark_gutters): new function. * glyphs-x.c (x_update_widget): Always resize to get round a widget bug. * glyphs-msw.c (mswindows_tab_control_update): remove `;' that was breaking absolutely everything. * gutter.h: declare mark_gutters. 2000-02-16 Andy Piper <andy(a)xemacs.org> * buffer.el (switch-to-buffer): give norecord argument to set-window-buffer instead of explicitly recording. * gutter-items.el (buffers-tab-switch-to-buffer): don't record if we have to pick a window. 2000-02-15 Andy Piper <andy(a)xemacs.org> * xlwgauge.c (GaugeExpose): remove shadows. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

3 participants
4 comments

Re: widget and tabs fix 24 years, 3 months

Karl Kleinpaste

Very nice, and almost there; many thanx. Unfortunately, the customization of the tab face still doesn't take, as seen in the MIMEd .gif below. --karl

2 participants
1 comments

Re: tab breakage yet again (XEmacs 21.2.29 is released.) 24 years, 3 months

Karl Kleinpaste

"John A. Turner" <turner(a)blueskystudios.com> writes: > I hope you don't mean that as harshly as it sounds. The whole point > of the beta process is to beat on new features and (hopefully) help > fix them. > If you're only interested in code that's "right", wait for a release. Well, I meant it strongly enough to indicate that I'm annoyed that an odd definition of "progress" is present, and I think such annoyance is justified. I certainly expect new features to have bugs to be shaken out. But tabs began appearing sometime in the early 21.2.teens, here we are at .29, and today tabs can't even correlate with buffers present. No, I don't expect code that's merely "right". This is a beta list, after all, and I know that. I'm on it because I like/want/need some of the features present in 21.2 and I'm pretty good at stressing certain odd corners of XEmacs to uncover bugs; when things get bad enough, as they unavoidably do, I just sit tight on N-1 and wait for the N+1 version in hope of something less unstable. On the other hand, a concept of "improvement" needs to be considered, not merely "updated" and "different": I ask, in an honest and earnest tone, whether the .29 state of tabs was tested at all, by anybody, for it to be in this condition. Andy, I don't mean to offend you personally, but one does have to wonder what experimentation with a fix happens before it lands in CVS. Is it any surprise that such wonderment exists, when tabs literally don't work at all? Regrets to any others I might have also offended.

5 participants
6 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 2000