March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Andy Piper

This fixes the lazy redisplay GC bug + some others. This doesn't fix the "wrong buffer selected in new frame" problem. andy 2000-03-19 Andy Piper <andy(a)xemacs.org> * glyphs.c (image_instance_hash): be careful about which items we hash on. * glyphs-widget.c (tab_control_set_property): record into pending items rather than the actual items. * glyphs-x.c (x_update_widget): use pending items to update with. * glyphs-msw.c (mswindows_tab_control_update): use pending items to update with. * glyphs.c (mark_image_instance): mark pending items. * window.c (Fset_window_configuration): record the buffer. (Fselect_window): totally revert previous change which breaks many things. 2000-03-18 Andy Piper <andy(a)xemacs.org> * glyphs-msw.c (mswindows_tab_control_update): force selected item. * files.el (find-file-noselect): undo change that shouldn't have gone in. * glyphs.c (image_instantiate): don't allow the minibuffer as a window domain cache, otherwise we get inconsistencies at startup. There is something fishy at startup which can lead to the minibuffer being the selected window when the gutter content is instantiated. * gui.c (parse_gui_item_tree_list): add probably unneccessary gcpros. (parse_gui_item_tree_children): ditto. (parse_gui_item_tree_item): ditto. * glyphs.c (Fupdate_widget_instances): return something. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

1 participants
0 comments

another crash 24 years, 8 months

Ben Wing

Anyone seen this before? compact_string_chars() line 3048 + 3 bytes gc_sweep() line 3211 garbage_collect_1() line 3518 Ffuncall(int 1, long * 0x0082eac8) line 3174 execute_optimized_program(unsigned char * 0x01e6ae50, int 2, long * 0x01def9f0) line 751 + 16 bytes funcall_compiled_function(long 31657368, int 1, long * 0x0082ed9c) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082ed98) line 3258 + 17 bytes execute_optimized_program(unsigned char * 0x01e081d0, int 6, long * 0x01c268d0) line 751 + 16 bytes funcall_compiled_function(long 29979328, int 3, long * 0x0082f07c) line 519 + 53 bytes Ffuncall(int 4, long * 0x0082f078) line 3258 + 17 bytes execute_optimized_program(unsigned char * 0x0082f260, int 5, long * 0x01e08ed0) line 751 + 16 bytes Fbyte_code(long 31787588, long 31493824, long 11) line 2410 + 38 bytes Feval(long 30220484) line 3023 + 187 bytes condition_case_1(long 30221648, long (long)* 0x01069cf3 Feval(long), long 30220484, long (long, long)* 0x01067573 run_condition_case_handlers(long, long), long 28360708) line 1640 + 7 bytes condition_case_3(long 30220484, long 28360708, long 30221648) line 1724 + 27 bytes execute_rare_opcode(long * 0x0082f578, unsigned char * 0x01e6ae7a, int 143) line 1276 + 19 bytes execute_optimized_program(unsigned char * 0x01e6ae70, int 3, long * 0x01e08e50) line 657 + 17 bytes funcall_compiled_function(long 31657396, int 0, long * 0x0082f850) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082f84c) line 3258 + 17 bytes execute_optimized_program(unsigned char * 0x01e52810, int 3, long * 0x01e2d210) line 751 + 16 bytes funcall_compiled_function(long 31657172, int 0, long * 0x0082fbac) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082fba8) line 3258 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x01e26400, int 1, long * 0x0082fba8, int 0) line 3715 + 13 bytes run_hook_with_args(int 1, long * 0x0082fba8, int 0) line 3728 + 23 bytes Frun_hooks(int 1, long * 0x0082fba8) line 3582 + 19 bytes run_hook(long 31742844) line 3829 + 11 bytes catch_them_squirmers_run_hook(long 28454356) line 4273 + 9 bytes condition_case_1(long 28360804, long (long)* 0x0106cb72 catch_them_squirmers_run_hook(long), long 28454356, long (long, long)* 0x0106cd55 allow_quit_safe_run_hook_caught_a_squirmer(long, long), long 31486676) line 1640 + 7 bytes safe_run_hook_trapping_errors(char * 0x011bea28, long 28454356, int 1) line 4340 + 51 bytes run_pre_idle_hook() line 2041 + 19 bytes Fnext_event(long 35641876, long 28360708) line 2207 Fcommand_loop_1() line 566 + 16 bytes command_loop_1(long 28360708) line 491 condition_case_1(long 28360804, long (long)* 0x0104a107 command_loop_1(long), long 28360708, long (long, long)* 0x01049b1c cmd_error(long, long), long 28360708) line 1640 + 7 bytes command_loop_3() line 252 + 35 bytes command_loop_2(long 28360708) line 264 internal_catch(long 28438532, long (long)* 0x01049c6c command_loop_2(long), long 28360708, int * 0x00000000) line 1306 + 7 bytes initial_command_loop(long 28360708) line 301 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x01b49480, char * * 0x01cdd500, int 0) line 1872 + 9 bytes main(int 1, char * * 0x01b49480, char * * 0x01cdd500) line 2291 + 21 bytes mainCRTStartup + 211 bytes _start() line 183 KERNEL32! 77e9bc52() -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

2 participants
1 comments

motion screwiness in latest cvs 24 years, 8 months

Jeff Miller

i'm running the latest cvs of 21.2. using gnus in a prior build, if i used # to mark an article, the article would be marked, and the cursor would be moved to the next article. now, i hit # and the article is marked, but the cursor does not move down to the next article. In fact, if i mark an article, use the arrow key to move down, mark that article, the cursor jumps back up to the top of the summary buffer. I don't see any error messages or anything like that. The only error I do see, is when running vm. When it starts up, I get a bunch of "error in font-lock-pre-idle-hook" messages. Jeff

3 participants
2 comments

isearch broken 24 years, 8 months

Andy Piper

Search for something. Hit C-a (or anything that used to make isearch quit) you jump back to where the search started. This is extremely annoying, I have had to resort to clicking with the mouse to actually leave point somewhere near where I want it. andy -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

3 participants
4 comments

Re: package hierarchy location [was: Re:] 24 years, 8 months

Michael Sperber

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> Oh yeah, another thing waiting to be completed: I put in a change to Ben> package loading so it will find the packages in a structure like this: Ben> .../xemacs-packages/ Ben> .../xemacs-21.2.30/ Ben> which is exactly what's needed for a truly unified tarball. This is a bad idea. We had discussed it before, and you agreed it was a bad idea. I'd like to dig up the xemacs-review archives on this, but someone will need to tell me what the authentification procedure is. Oh yeah, can we *please* have subjects so something like this doesn't slip by. -- Cheers =8-} Chipsy Friede, Völkerverständigung und überhaupt blabla

1 participants
0 comments

Re: package changes 24 years, 8 months

Jan Vroonhof

Ben Wing <ben(a)666.com> writes: > I have also been thinking about adding the ability for a package to > specify a Lisp form to evaluate to indicate > whether it should be loaded. Sounds like a good idea. (Preferable a similar form could be put in the package index so the package install tools can be less stupid). Michael Sperber has an idea like this in his planned new design, that stalled. Maybe you should contact him or read the archive? Bonus points for still allowing packages to be used under 21.1.x if possible. Jan

1 participants
0 comments

Re: 24 years, 8 months

Adrian Aichner

>>>>> "Ben" == Ben Wing <ben(a)666.com> writes: Ben> Currently I'm working on some process stuff (implementing Ben> `call-process' in Lisp, so it works under MSWin). If I ever Hi Ben, please note me down as a guinea pig for the subprocess stuff. I am eagerly waiting for this. Best regards, Adrian

1 participants
0 comments

Re: 24 years, 8 months

Jan Vroonhof

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Where are we as far as nailing things down for a 21.2 release? > Stabilizing your widget stuff was one of the pre-release > objectives. What else? - Actually making use of any of the widget stuff beyond the tabs? - Ironing out the remaining kinks in the new menu structure. - The dumper support. - Package support fixes (i.e. starting from allowing a xemacs-<version>-all.tar.gz file upto finding a solution to replace News). I am supposing it is too late to actually implement a great overhaul of the package code that was discussed a few moons ago. I wanted to complete the custom themes stuff, but in its current state it can lie dormant if we wish. So it won't delay any release if I do not find the time. I think we should also release a few betas with clash-detection enabled to have it exercised. Jan

2 participants
2 comments

Re: 24 years, 8 months

Hrvoje Niksic

Kyle Jones <kyle_jones(a)wonderworks.com> writes: > Where are we as far as nailing things down for a 21.2 release? > Stabilizing your widget stuff was one of the pre-release objectives. > What else? Portable dumper was the other one. Maybe Ben has things he wants to finish by 21.2?

2 participants
1 comments

Re: 24 years, 8 months

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > wmperry(a)aventail.com (William M. Perry) writes: > > > Well, other than that the current version of Emacs/W3 won't run > > because somebody is treating a keyword as a variable. Haven't been > > able to figure out where though. Bleah. > > Uhm. (setq debug-on-error t)? You'd think, eh? :) Big gobbledy-gook of bytecode, and the error doesn't happen if the .el file is loaded. > Note that in XEmacs it's legal to say (setq :foo :foo). > (setq :foo :bar) signals an error, though. -Bill P.

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 March 2000