Mercurial > hg > xemacs-beta
annotate modules/README @ 1268:fffe735e63ee
[xemacs-hg @ 2003-02-07 11:50:50 by ben]
fixes for menu crashes + better preemption behavior
This contains two related changes:
(1) Fix problems with reentrant calling of lwlib and associated
crashes when selecting menu items.
(2) Improve redisplay handling of preemption. Turn on lazy lock
and hold down page-down or page-up and you'll see what I mean.
They are related because they both touch on the code that retrieves
events and handles the internal queues.
console-msw.h, event-msw.c, event-stream.c, events.h, menubar-msw.c, menubar-x.c, menubar.h: mswindows_protect_modal_loop() has been generalized to
event_stream_protect_modal_loop(), and moved to event-stream.c.
mswindows_in_modal_loop ->in_modal_loop likewise. Changes in
event-msw.c and menubar-msw.c for the new names and calling format
(use structures instead of static variables in menubar-msw.c).
Delete former in_menu_callback and use in_modal_loop in its place.
Remove emacs_mswindows_quit_check_disallowed_p(), superseded by
in_modal_loop. Use event_stream_protect_modal_loop() in
pre_activate_callback() so that we get no lwlib reentrancy.
Rearrange some of the code in event-msw.c to be grouped better.
Make mswindows_drain_windows_queue() respect in_modal_loop and
do nothing if so.
cmdloop.c, event-stream.c: Don't conditionalize on LWLIB_MENUBARS_LUCID when giving error when
in_modal_loop, and give better error.
event-Xt.c, event-gtk.c: If in_modal_loop, only retrieve process and timeout events.
Don't retrieve any X events because processing them can lead
to reentrancy in lwlib -> death.
event-stream.c: Remove unused parameter to check_event_stream_ok() and change
all callers.
lisp.h, event-stream.c: Rearrange some functions for increased clarity -- in particular,
group all the input-pending/QUIT-related stuff together, and
put right next to next-event stuff, to which it's related.
Add the concept of "HOW_MANY" -- when asking whether user input
is pending, you can ask if at least HOW_MANY events are pending,
not just if any are. Add parameter to detect_input_pending()
for this. Change recursive_sit_for from a Lisp_Object (which
could only be Qt or Qnil) to an int, like it should be.
event-Xt.c, event-gtk.c, event-xlike-inc.c: New file.
Abstract out similar code in event_{Xt/gtk}_pending_p() and write
only once, using include-file tricks. Rewrite this function to
implement HOW_MANY and only process events when not in_modal_loop.
event-msw.c: Implement HOW_MANY and only process events when not in_modal_loop.
event-tty.c: Implement HOW_MANY.
redisplay.c: Add var `max-preempts' to control maximum number of preempts.
(#### perhaps not useful) Rewrite preemption check so that,
rather than preempting when any user events are available, only
preempt when a certain number (currently 4) of them are backed up.
This effectively allows redisplay to proceed to completion in the
presence of a fast auto-repeat (usually the auto-repeating is
generated dynamically as necessary), and you get much better
display behavior with lazy-lock active.
event-unixoid.c: Comment changes.
event-stream.c: Rewrite discard-input much more simply and safely using the
drain-queue functions. I think the old version might loop
forever if called when in_modal_loop.
SEMI-UNRELATED CHANGES:
-----------------------
event-stream.c: Turn QUIT-checking back on when running the pre-idle hook so it
can be quit out of.
indent.c: Document exact functioning of `vertical-motion' better, and its
differences from GNU Emacs.
| author | ben |
|---|---|
| date | Fri, 07 Feb 2003 11:50:54 +0000 |
| parents | 25e260cb7994 |
| children | da1365dd3f07 |
| rev | line source |
|---|---|
| 996 | 1 This directory contains a number of XEmacs dynamic modules. These |
| 2 modules can be loaded directly with the command 'M-x load-module'. | |
| 3 However, the preferred method of loading a module is to issue a | |
| 4 "(require 'module-name)" command to the Lisp interpreter. This will | |
| 5 store information so that a later "(unload-feature 'module-name)" can | |
| 6 succeed. | |
| 388 | 7 |
| 996 | 8 To compile one of these modules, simply enter the desired directory, |
| 9 type 'configure', and then 'make'. If you are building the module for | |
| 10 an installed XEmacs, then 'make install' will place the module in the | |
| 11 appropriate directory for XEmacs to find it later (assuming you have | |
| 12 permission to write to that directory). A subsequent 'load-module' or | |
| 13 'require' will then load the module, as described above. | |
| 388 | 14 |
| 996 | 15 Each of these demonstrates different features and limitations of the |
| 16 XEmacs module loading technology. For a complete discussion on XEmacs | |
| 17 dynamic modules, please consult the XEmacs Module Writers Guide, which | |
| 18 can be found in the ../info directory. | |
| 388 | 19 |
| 996 | 20 For those wanting to get started with module writing, please see the |
| 21 'sample' directory. It contains two subdirectories: internal and | |
| 22 external. The 'internal' subdirectory contains the framework needed to | |
| 23 migrate some core piece of XEmacs functionality into code that can | |
| 24 either be compiled into the core or built as a separate module. The | |
| 25 'external' subdirectory contains the somewhat simpler framework needed | |
| 26 to build a module separately from XEmacs. These should be considered | |
| 27 starting places for module writing. |
