March 2000 - XEmacs-Beta - XEmacs Mailing List Archives

Andy Piper

This actually fixes a whole bunch of bugs with gutters and friends that stopped progress gauges working properly. I have fixed these and it works reasonably under X and windows so I have turned it on for font-lock. NEWS documents how to turn it off if you don't like it. This also fixes the 100% CPU bug under cygwin. I am actually happy with the subwindow / gutter redisplay mechanism now. So we just need to fix any remaining bugs. andy 2000-03-16 Andy Piper <andy(a)xemacs.org> * NEWS: update for new features. * font-lock.el (font-lock-mode): use lprogress and friends for progress management. (font-lock-default-fontify-buffer): ditto. (font-lock-fontify-syntactically-region): ditto. (font-lock-fontify-keywords-region): ditto. (font-lock-revert-cleanup): fix reverting. (font-lock-revert-setup): ditto. * gutter-items.el (progress-use-echo-area): new variable. Use the echo area for progress gauges if non-nil. (clear-progress): remove echo area stuff and defer to clear-message. (append-progress): dispatch non-command events after each progress increment. Remove echo area stuff. (abort-progress): remove echo area stuff and defer to display-message. (raw-append-progress): ditto. Dispatch non-command events after gutter redisplay. (display-progress): defer echo area stuff to display-message. * event-Xt.c (emacs_Xt_force_event_pending): new function. Post a synthetic event to the native system. (reinit_vars_of_event_Xt): set force_event_pending to emacs_Xt_force_event_pending. * events.h (struct event_stream): add force_event_pending. * specifier.c (recompute_one_cached_specifier_in_window): add comment. * redisplay.c (redisplay_frame): don't call update_frame_subwindows. Reset subwindow cachels when subwindows_changed, removing this was an optimization too far. * redisplay-output.c (compare_runes): reorganize so that we catch glyph changes when we want them. Set optimize_output when this would help layouts. (redisplay_output_layout): remove frame_really_changed, use optimize_output instead. * redisplay-msw.c (mswindows_output_display_block): reset optimize_output after outputting a glyph. * redisplay-x.c (x_output_display_block): ditto. * redisplay-tty.c (tty_output_display_block): ditto. * gutter.c: (specifier_vars_of_gutter): use new spec changed functions. (gutter_specs_changed): do specific gutter positions. (top_gutter_specs_changed): new function. Only update the specified gutter specs. (bottom_gutter_specs_changed): ditto. (left_gutter_specs_changed): ditto. (right_gutter_specs_changed): ditto. * gui.c (gui_item_hash_internal): new function, does a real hash. (gui_item_id_hash): use it. (gui_item_hash): hash the eval'ed gui_item. * gui-x.c (popup_selection_callback): send an eval event to call Fupdate_widget_instances. * gui-msw.c (mswindows_handle_gui_wm_command): send an eval event to call Fupdate_widget_instances. * glyphs.h (struct Lisp_Image_Instance): add optimize_output flag. (IMAGE_INSTANCE_OPTIMIZE_OUTPUT): access it. * glyphs.c: (update_frame_subwindows): deleted. (Fupdate_widget_instances): new function for updating the dirty state of widgets that might have changed. (syms_of_glyphs): add Qupdate_widget_instances. (full_list_hash): hash a list completely. (image_instance_hash): use it for items and properties. * frame-msw.c (mswindows_size_frame_internal): remove unused variable. * faces.h (struct face_cachel): fix comment. * event-stream.c (Fdispatch_non_command_events): new function. Process non-command events, forcing an event cycle beforehand. (syms_of_event_stream): declare. (event_stream_force_event_pending): new function. Force an event on the native event queue so that an event cycle will occur next time we check. * event-msw.c: (struct ntpipe_shove_stream): (mswindows_enqueue_dispatch_event): (mswindows_dequeue_dispatch_event): (mswindows_cancel_dispatch_event): (mswindows_pump_outstanding_events): (mswindows_drain_windows_queue): (mswindows_handle_paint): (mswindows_wnd_proc): (mswindows_key_to_emacs_keysym): (get_process_input_waitable): (emacs_mswindows_delete_stream_pair): re-indent file. (mswindows_need_event): do not process further fds if the windows fd is set, otherwise you get endless XM_BUMPQUEUE cycles. This fixes the 100% cpu problem. (reinit_vars_of_event_mswindows): set force_event_pending to 0. * gutter-items.el (clear-progress): (abort-progress): indentation changes. (display-progress): don't clear progress. (append-progress): compare messages with equal. (raw-append-progress): use dispatch-non-command-events to flush widget creation events. -------------------------------------------------------------- Dr Andy Piper Senior Consultant Architect, BEA Systems Ltd

2 participants
3 comments

Re: EUDC crash with 21.2.31 on Solaris 2.7 24 years, 8 months

Raymond Toy

>>>>> "Jan" == Jan Vroonhof <vroonhof(a)math.ethz.ch> writes: Jan> "John A. Turner" <turner(a)blueskystudios.com> writes: >> oh, I didn't realize I should be doing that as well - I thought I was >> seeing a different crash from the one in this thread Jan> Oops, sorry. I meant I wanted Raymond to do that... Although Andy Jan> thinks it might a garbage collect thing, in that case setting Jan> always_gc should make it easier to reproduce. This is getting weirder and weirder. I tried it again, except I set always_gc a bit earlier. It runs forever, eventually producing an error message: Wrong type: listp: ?o. But xemacs doesn't crash. On a different run, without setting always_gc, but evaluating some random stuff in the *scratch* buffer, I get the message: Invalid byte code: "byte code stack overflow" But this doesn't always happen. The behavior seems to be totally random, except that my recipe crashes xemacs 100% of the time. I don't know what to do now. Ray

1 participants
0 comments

Re: 24 years, 8 months

Jan Vroonhof

Andy Piper <andy(a)xemacs.org> writes: > 5. How do I get gnuserv to work. Note that I have had a mail form Guy, who did the NT port of Gnuserv to discuss a real merge. That would be the best solution. If any of you (Hrovje, Francois) has time to do so (I cannot test on NT anyway) that would be perfect. Jan P.S. I'll CC Guy to let him know that I did get his mail and its filed under "too important for a trivial answer". Unfortunately work on that category is hampered by real life. Both the mind an the flesh are weak but the thesis advisor is strong :-(.

1 participants
0 comments

tabs/font-lock/vc-hooks bad interaction 24 years, 8 months

Olivier Galibert

With a .emacs reduced to: (require 'font-lock) (require 'vc-hooks) Do in a cvs-checkout'ed directory (xemacs/src for instance): xemacs alloc.c C-x 5 2 (in the new frame) C-x C-f dumper.c In the new frame the active tab will still be on alloc.c. OG.

2 participants
1 comments

nasty crash 24 years, 8 months

Ben Wing

I've hit this exact same crash twice today; no other crashes today. (The infinite throw bomb seems to have resolved itself, probably with those gcpro's I added. But this one is something else. In both case, I think I may have been scrolling with the wheel on my mouse (this was definitely the case the second time), and I have lazy-lock enabled, which explains the pre-idle-hook; lazy-lock was definitely being called. What's more interesting is that while lazy-lock is doing its thing, it does a select-window, which calls record-buffer, which runs some hook (clearly an Andy hook). The problem here is that this call to condition_case_unwind is impossible. garbage_collect_1 puts only one thing onto the specpdl stack (a record-unwind-protect), and yet when the specpdl stack is unwound (and should only process the record-unwind-protect), it instead processes condition_case_unwind(), which shouldn't be there. (It should be somewhere lower on the stack.) Looking at unbind_to_hairy(), I think I see a logic error. If so, it's amazing we are able to run ok at all. void unbind_to_hairy (int count) { int quitf; check_quit (); /* make Vquit_flag accurate */ quitf = !NILP (Vquit_flag); Vquit_flag = Qnil; ++specpdl_ptr; ^^^^^^^^^^^^^^^^^^^^ ++specpdl_depth_counter; ^^^^^^^^^^^^^^^^^^^^ while (specpdl_depth_counter != count) { --specpdl_ptr; --specpdl_depth_counter; if (specpdl_ptr->func != 0) /* An unwind-protect */ (*specpdl_ptr->func) (specpdl_ptr->old_value); else { /* We checked symbol for validity when we specbound it, so only need to call Fset if symbol has magic value. */ Lisp_Symbol *sym = XSYMBOL (specpdl_ptr->symbol); if (!SYMBOL_VALUE_MAGIC_P (sym->value)) sym->value = specpdl_ptr->old_value; else Fset (specpdl_ptr->symbol, specpdl_ptr->old_value); } The two flagged lines cause unbind_to to try and unbind the entry past the end of the stack, as well as the stack end entry, which could cause all sorts of fucked up behavior. I'm going to try removing them and seeing what happens. Stack trace: NTDLL! 77f9d715() error_check_cons(long 35731556) line 589 + 59 bytes condition_case_unwind(long 35731556) line 1525 + 9 bytes unbind_to_hairy(int 45) line 4658 + 18 bytes unbind_to(int 45, long 20172152) line 4633 + 174 bytes garbage_collect_1() line 3608 + 15 bytes Ffuncall(int 2, long * 0x0082d838) line 3169 execute_optimized_program(unsigned char * 0x014b7790, int 7, long * 0x013cb26c) line 747 + 16 bytes funcall_compiled_function(long 20914232, int 2, long * 0x0082db18) line 519 + 53 bytes Ffuncall(int 3, long * 0x0082db14) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x014b7750, int 3, long * 0x013cb1a8) line 747 + 16 bytes funcall_compiled_function(long 20914092, int 1, long * 0x0082ddec) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082dde8) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x00e47598, int 7, long * 0x013d288c) line 747 + 16 bytes funcall_compiled_function(long 20926132, int 4, long * 0x0082e1b4) line 519 + 53 bytes Ffuncall(int 5, long * 0x0082e1b0) line 3253 + 17 bytes Fapply(int 6, long * 0x0082e1b0) line 3426 + 16 bytes Ffuncall(int 7, long * 0x0082e1ac) line 3239 + 14 bytes execute_optimized_program(unsigned char * 0x014b7710, int 7, long * 0x013cb1c4) line 747 + 16 bytes funcall_compiled_function(long 20914120, int 2, long * 0x0082e494) line 519 + 53 bytes Ffuncall(int 3, long * 0x0082e490) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x014b74b0, int 5, long * 0x013cb2cc) line 747 + 16 bytes funcall_compiled_function(long 20914260, int 2, long * 0x0082e77c) line 519 + 53 bytes Ffuncall(int 3, long * 0x0082e778) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x014b6ce0, int 6, long * 0x013cb41c) line 747 + 16 bytes funcall_compiled_function(long 20914372, int 1, long * 0x0082eabc) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082eab8) line 3253 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x0155ce80, int 2, long * 0x0082eab8, int 0) line 3704 + 13 bytes run_hook_with_args(int 2, long * 0x0082eab8, int 0) line 3717 + 23 bytes va_run_hook_with_args(long 19991168, int 1) line 3788 + 18 bytes Frecord_buffer(long 22234416) line 1423 + 17 bytes Fselect_window(long 35454408, long 20172152) line 3376 + 12 bytes Ffuncall(int 2, long * 0x0082ebc4) line 3218 + 93 bytes execute_optimized_program(unsigned char * 0x014fb3e0, int 2, long * 0x014c3c10) line 747 + 16 bytes funcall_compiled_function(long 36319072, int 1, long * 0x0082ee98) line 519 + 53 bytes Ffuncall(int 2, long * 0x0082ee94) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x014fb380, int 6, long * 0x013d4b60) line 747 + 16 bytes funcall_compiled_function(long 20929296, int 3, long * 0x0082f178) line 519 + 53 bytes Ffuncall(int 4, long * 0x0082f174) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x0082f35c, int 5, long * 0x014c3c60) line 747 + 16 bytes Fbyte_code(long 36284332, long 21773392, long 11) line 2406 + 38 bytes Feval(long 35732876) line 3018 + 187 bytes condition_case_1(long 35761328, long (long)* 0x010696b7 Feval(long), long 35732876, long (long, long)* 0x01066f13 run_condition_case_handlers(long, long), long 20172152) line 1644 + 7 bytes condition_case_3(long 35732876, long 20172152, long 35761328) line 1728 + 27 bytes execute_rare_opcode(long * 0x0082f674, unsigned char * 0x014fb34a, int 143) line 1272 + 19 bytes execute_optimized_program(unsigned char * 0x014fb340, int 3, long * 0x014c3d00) line 657 + 17 bytes funcall_compiled_function(long 36319100, int 0, long * 0x0082f94c) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082f948) line 3253 + 17 bytes execute_optimized_program(unsigned char * 0x014dd130, int 3, long * 0x014b6a60) line 747 + 16 bytes funcall_compiled_function(long 36318876, int 0, long * 0x0082fca8) line 519 + 53 bytes Ffuncall(int 1, long * 0x0082fca4) line 3253 + 17 bytes run_hook_with_args_in_buffer(buffer * 0x01534530, int 1, long * 0x0082fca4, int 0) line 3704 + 13 bytes run_hook_with_args(int 1, long * 0x0082fca4, int 0) line 3717 + 23 bytes Frun_hooks(int 1, long * 0x0082fca4) line 3571 + 19 bytes run_hook(long 36367700) line 3818 + 11 bytes catch_them_squirmers_run_hook(long 20006864) line 4262 + 9 bytes condition_case_1(long 20171960, long (long)* 0x0106c536 catch_them_squirmers_run_hook(long), long 20006864, long (long, long)* 0x0106c719 allow_quit_safe_run_hook_caught_a_squirmer(long, long), long 37001588) line 1644 + 7 bytes safe_run_hook_trapping_errors(char * 0x01267a74, long 20006864, int 1) line 4329 + 51 bytes run_pre_idle_hook() line 2007 + 19 bytes Fnext_event(long 39751880, long 20172152) line 2173 Fcommand_loop_1() line 566 + 16 bytes command_loop_1(long 20172152) line 491 condition_case_1(long 20171960, long (long)* 0x01049997 command_loop_1(long), long 20172152, long (long, long)* 0x010493ac cmd_error(long, long), long 20172152) line 1644 + 7 bytes command_loop_3() line 252 + 35 bytes command_loop_2(long 20172152) line 264 internal_catch(long 20011136, long (long)* 0x010494fc command_loop_2(long), long 20172152, int * 0x00000000) line 1310 + 7 bytes initial_command_loop(long 20172152) line 301 + 25 bytes STACK_TRACE_EYE_CATCHER(int 1, char * * 0x014b11d0, char * * 0x014b0200, int 0) line 1828 + 9 bytes main(int 1, char * * 0x014b11d0, char * * 0x014b0200) line 2192 + 19 bytes mainCRTStartup() line 338 + 17 bytes 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.

4 participants
6 comments

Progress gauges! 24 years, 8 months

Hrvoje Niksic

Holy shit, those things look cool! :-) The only thing I dislike is that they're huge, and that the default colors are weird (black foreground on dark background) in my setup.

2 participants
1 comments

Re: Progress gauges! 24 years, 8 months

Hrvoje Niksic

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > The only thing I dislike is that they're huge, and that the default > colors are weird (black foreground on dark background) in my setup. Ah, the obligatory screenshot depicting the problem:

2 participants
1 comments

Aborting the progress gauge 24 years, 8 months

Hrvoje Niksic

When something unexpected happens to the progress gauge, it just sticks around in the minibuffer. It seems impossible to remove it. Changing buffers doesn't help. Opening a new frame helps, though. You can repeat it by starting the font-lock of a large buffer, and clicking somewhere in the echo area other than the "Stop" button. This results in "not over a window" error. I think the echo area progress gauge should behave like an echo area message -- removed at the first possible opportunity.

2 participants
1 comments

Progress gauges slowing things down 24 years, 8 months

Hrvoje Niksic

For some reason, progress gauge takes a very long time to come up and disappear. It seems as if there was a (sleep-for 1) hidden in the code. To repeat, try opening a very small .c file with progress gauges. The delay is very noticeable and quite annoying. I often hit this when replying to messages in Gnus (Gnus "message" mode uses font-lock for highlighting.)

2 participants
1 comments

Re: Modules API 24 years, 8 months

William M. Perry

Hrvoje Niksic <hniksic(a)iskon.hr> writes: > SL Baur <steve(a)beopen.com> writes: > > > May I respectfully request that the functionality of XtAppAddInput > > be added to the XEmacs event loop? > > I think Lisp code should never have to deal with "file descriptors". > There should be a standard way to hook into the event loop from C, > though. > > I remember that William Perry used something like that to get the GPM > support right. Bill, what do you think about this? Having something cleaner than what I had to do for the GPM code would be nice. Most of the nastiness in there is because I needed to generate the events though. The bit dealing with the 'fake' process is actually pretty simple. > > Under Unix, we use select loops, either via Xt, or via a home-brewed > > version when running tty-only. Does a similar functionality exist > > under MS-Windows? > > I don't think so. This kind of thing is much harder under Windows. > Remember Jonathan Harris' talk in Tsukuba last year? <shudder> That was definitely gruesome. :) -bp

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