view man/external-widget.texi @ 4677:8f1ee2d15784

Support full Common Lisp multiple values in C. lisp/ChangeLog 2009-08-11 Aidan Kehoe <kehoea@parhasard.net> * bytecomp.el : Update this file to support full C-level multiple values. This involves: -- Four new bytecodes, and special compiler functions to compile multiple-value-call, multiple-value-list-internal, values, values-list, and, since it now needs to pass back multiple values and is a special form, throw. -- There's a new compiler variable, byte-compile-checks-on-load, which is a list of forms that are evaluated at the very start of a file, with an error thrown if any of them give nil. -- The header is now inserted *after* compilation, giving a chance for the compilation process to influence what those checks are. There is still a check done before compilation for non-ASCII characters, to try to turn off dynamic docstrings if appopriate, in `byte-compile-maybe-reset-coding'. Space is reserved for checks; comments describing the version of the byte compiler generating the file are inserted if space remains for them. * bytecomp.el (byte-compile-version): Update this, we're a newer version of the byte compiler. * byte-optimize.el (byte-optimize-funcall): Correct a comment. * bytecomp.el (byte-compile-lapcode): Discard the arg with byte-multiple-value-call. * bytecomp.el (byte-compile-checks-and-comments-space): New variable, describe how many octets to reserve for checks at the start of byte-compiled files. * cl-compat.el: Remove the fake multiple-value implementation. Have the functions that use it use the real multiple-value implementation instead. * cl-macs.el (cl-block-wrapper, cl-block-throw): Revise the byte-compile properties of these symbols to work now we've made throw into a special form; keep the byte-compile properties as anonymous lambdas, since we don't have docstrings for them. * cl-macs.el (multiple-value-bind, multiple-value-setq) (multiple-value-list, nth-value): Update these functions to work with the C support for multiple values. * cl-macs.el (values): Modify the setf handler for this to call #'multiple-value-list-internal appropriately. * cl-macs.el (cl-setf-do-store): If the store form is a cons, treat it specially as wrapping the store value. * cl.el (cl-block-wrapper): Make this an alias of #'and, not #'identity, since it needs to pass back multiple values. * cl.el (multiple-value-apply): We no longer support this, mark it obsolete. * lisp-mode.el (eval-interactive-verbose): Remove a useless space in the docstring. * lisp-mode.el (eval-interactive): Update this function and its docstring. It now passes back a list, basically wrapping any eval calls with multiple-value-list. This allows multiple values to be printed by default in *scratch*. * lisp-mode.el (prin1-list-as-multiple-values): New function, printing a list as multiple values in the manner of Bruno Haible's clisp, separating each entry with " ;\n". * lisp-mode.el (eval-last-sexp): Call #'prin1-list-as-multiple-values on the return value of #'eval-interactive. * lisp-mode.el (eval-defun): Call #'prin1-list-as-multiple-values on the return value of #'eval-interactive. * mouse.el (mouse-eval-sexp): Deal with lists corresponding to multiple values from #'eval-interactive. Call #'cl-prettyprint, which is always available, instead of sometimes calling #'pprint and sometimes falling back to prin1. * obsolete.el (obsolete-throw): New function, called from eval.c when #'funcall encounters an attempt to call #'throw (now a special form) as a function. Only needed for compatibility with 21.4 byte-code. man/ChangeLog addition: 2009-08-11 Aidan Kehoe <kehoea@parhasard.net> * cl.texi (Organization): Remove references to the obsolete multiple-value emulating code. src/ChangeLog addition: 2009-08-11 Aidan Kehoe <kehoea@parhasard.net> * bytecode.c (enum Opcode /* Byte codes */): Add four new bytecodes, to deal with multiple values. (POP_WITH_MULTIPLE_VALUES): New macro. (POP): Modify this macro to ignore multiple values. (DISCARD_PRESERVING_MULTIPLE_VALUES): New macro. (DISCARD): Modify this macro to ignore multiple values. (TOP_WITH_MULTIPLE_VALUES): New macro. (TOP_ADDRESS): New macro. (TOP): Modify this macro to ignore multiple values. (TOP_LVALUE): New macro. (Bcall): Ignore multiple values where appropriate. (Breturn): Pass back multiple values. (Bdup): Preserve multiple values. Use TOP_LVALUE with most bytecodes that assign anything to anything. (Bbind_multiple_value_limits, Bmultiple_value_call, Bmultiple_value_list_internal, Bthrow): Implement the new bytecodes. (Bgotoifnilelsepop, Bgotoifnonnilelsepop, BRgotoifnilelsepop, BRgotoifnonnilelsepop): Discard any multiple values. * callint.c (Fcall_interactively): Ignore multiple values when calling #'eval, in two places. * device-x.c (x_IO_error_handler): * macros.c (pop_kbd_macro_event): * eval.c (Fsignal): * eval.c (flagged_a_squirmer): Call throw_or_bomb_out, not Fthrow, now that the latter is a special form. * eval.c: Make Qthrow, Qobsolete_throw available as symbols. Provide multiple_value_current_limit, multiple-values-limit (the latter as specified by Common Lisp. * eval.c (For): Ignore multiple values when comparing with Qnil, but pass any multiple values back for the last arg. * eval.c (Fand): Ditto. * eval.c (Fif): Ignore multiple values when examining the result of the condition. * eval.c (Fcond): Ignore multiple values when comparing what the clauses give, but pass them back if a clause gave non-nil. * eval.c (Fprog2): Never pass back multiple values. * eval.c (FletX, Flet): Ignore multiple when evaluating what exactly symbols should be bound to. * eval.c (Fwhile): Ignore multiple values when evaluating the test. * eval.c (Fsetq, Fdefvar, Fdefconst): Ignore multiple values. * eval.c (Fthrow): Declare this as a special form; ignore multiple values for TAG, preserve them for VALUE. * eval.c (throw_or_bomb_out): Make this available to other files, now Fthrow is a special form. * eval.c (Feval): Ignore multiple values when calling a compiled function, a non-special-form subr, or a lambda expression. * eval.c (Ffuncall): If we attempt to call #'throw (now a special form) as a function, don't error, call #'obsolete-throw instead. * eval.c (make_multiple_value, multiple_value_aset) (multiple_value_aref, print_multiple_value, mark_multiple_value) (size_multiple_value): Implement the multiple_value type. Add a long comment describing our implementation. * eval.c (bind_multiple_value_limits): New function, used by the bytecode and by #'multiple-value-call, #'multiple-value-list-internal. * eval.c (multiple_value_call): New function, used by the bytecode and #'multiple-value-call. * eval.c (Fmultiple_value_call): New special form. * eval.c (multiple_value_list_internal): New function, used by the byte code and #'multiple-value-list-internal. * eval.c (Fmultiple_value_list_internal, Fmultiple_value_prog1): New special forms. * eval.c (Fvalues, Fvalues_list): New Lisp functions. * eval.c (values2): New function, for C code returning multiple values. * eval.c (syms_of_eval): Make our new Lisp functions and symbols available. * eval.c (multiple-values-limit): Make this available to Lisp. * event-msw.c (dde_eval_string): * event-stream.c (execute_help_form): * glade.c (connector): * glyphs-widget.c (glyph_instantiator_to_glyph): * glyphs.c (evaluate_xpm_color_symbols): * gui-x.c (wv_set_evalable_slot, button_item_to_widget_value): * gui.c (gui_item_value, gui_item_display_flush_left): * lread.c (check_if_suppressed): * menubar-gtk.c (menu_convert, menu_descriptor_to_widget_1): * menubar-msw.c (populate_menu_add_item): * print.c (Fwith_output_to_temp_buffer): * symbols.c (Fsetq_default): Ignore multiple values when calling Feval. * symeval.h: Add the header declarations necessary for the multiple-values implementation. * inline.c: #include symeval.h, now that it has some inline functions. * lisp.h: Update Fthrow's declaration. Make throw_or_bomb_out available to all files. * lrecord.h (enum lrecord_type): Add the multiple_value type here.
author Aidan Kehoe <kehoea@parhasard.net>
date Sun, 16 Aug 2009 20:55:49 +0100
parents 42375619fa45
children 03ab78e48ef6
line wrap: on
line source

\input texinfo  @c -*-texinfo-*-
@setfilename ../info/external-widget.info
@settitle The External Client Widget

@ifinfo
@dircategory XEmacs Editor
@direntry
* External Widget: (external-widget).   External Client Widget.
@end direntry
@end ifinfo

@node Top, Using an External Client Widget,, (dir)

An @dfn{external client widget} is a widget that is part of another program
but functions as an Emacs frame.  This is intended to be a more
powerful replacement for standard text widgets.

@menu
* Using an External Client Widget::
* External Client Widget Resource Settings::
* Motif-Specific Info About the External Client Widget::
* External Client Widget Internals::
@end menu


@node Using an External Client Widget, External Client Widget Resource Settings, Top, Top
@chapter Using an External Client Widget

There are three different implementations of the external client widget.
One is designed for use in Motif applications and is linked with the
option @code{-lextcli_Xm}.  Another is designed for non-Motif
applications that still use the X toolkit; it is linked with the option
@code{-lextcli_Xt}.  The third is designed for applications that do not
use the X toolkit; it is linked with the option @code{-lextcli_Xlib}.
In order to use an external client widget in a client program that uses
the X toolkit (i.e. either of the first two options described above),
simply create an instance of widget type ExternalClient and link your
program with the appropriate library.  The corresponding header file is
called @file{ExternalClient.h}.

Documentation still needs to be provided for using the raw Xlib
version of the external client widget.

The external client widget will not do anything until an instance of
Emacs is told about this particular widget.  To do that, call the
function @code{make-frame}, specifying a value for the frame parameter
@code{window-id}.  This value should be a string containing the decimal
representation of the widget's X window ID number (this can be obtained
by the Xt function @code{XtWindow()}).  In order for the client program
to communicate this information to Emacs, a method such as sending a
ToolTalk message needs to be used.

Once @code{make-frame} has been called, Emacs will create a frame
that occupies the client widget's window.  This frame can be used just
like any other frame in Emacs.


@node External Client Widget Resource Settings, Motif-Specific Info About the External Client Widget, Using an External Client Widget, Top
@chapter External Client Widget Resource Settings

The external client widget is a subclass of the Motif widget XmPrimitive
and thus inherits all its resources.  In addition, the following new
resources are defined:

@table @samp
@item deadShell (class DeadShell)
A boolean resource indicating whether the last request to the
ExternalShell widget that contains the frame corresponding to this
widget timed out.  If true, no further requests will be made (all
requests will automatically fail) until a response to the last
request is received.  This resource should normally not be set by the
user.

@item shellTimeout (class ShellTimeout)
A value specifying how long (in milliseconds) the client should wait
for a response when making a request to the corresponding ExternalShell
widget.  If this timeout is exceeded, the client will assume that the
shell is dead and will fail the request and all subsequent requests
until a response to the request is received.  Default value is 5000,
or 5 seconds.
@end table

The shell that contains the frame corresponding to an external client
widget is of type ExternalShell, as opposed to standard frames, whose
shell is of type TopLevelShell.  The ExternalShell widget is a direct
subclass of Shell and thus inherits its resources.  In addition, the
following new resources are defined:

@table @samp
@item window (class Window)
The X window ID of the widget to use for this Emacs frame.  This is
normally set by the call to @code{x-create-frame} and should not be
modified by the user.

@item deadClient (class DeadClient)
A boolean resource indicating whether the last request to the
corresponding ExternalClient widget timed out.  If true, no further
requests will be made (all requests will automatically fail) until a
response to the last request is received.  This resource should
normally not be set by the user.

@item ClientTimeout (class ClientTimeout)
A value specifying how long (in milliseconds) the shell should wait
for a response when making a request to the corresponding ExternalClient
widget.  If this timeout is exceeded, the shell will assume that the
client is dead and will fail the request and all subsequent requests
until a response to the request is received.  Default value is 5000,
or 5 seconds.
@end table

Note that the requests that are made between the client and the shell
are primarily for handling query-geometry and geometry-manager requests
made by parent or child widgets.


@node Motif-Specific Info About the External Client Widget, External Client Widget Internals, External Client Widget Resource Settings, Top
@chapter Motif-Specific Info About the External Client Widget

By default, the external client widget has navigation type
@samp{XmTAB_GROUP}.

The widget traversal keystrokes are modified slightly from the standard
XmPrimitive keystrokes.  In particular, @kbd{@key{TAB}} alone does not
traverse to the next widget (@kbd{Ctrl-@key{TAB}} must be used instead),
but functions like a normal @key{TAB} in Emacs.  This follows the
semantics of the Motif text widget.  The traversal keystrokes
@kbd{Ctrl-@key{TAB}} and @kbd{Shift-@key{TAB}} are silently filtered by
the external client widget and are not seen by Emacs.

@node External Client Widget Internals, , Motif-Specific Info About the External Client Widget, Top
@chapter External Client Widget Internals

The following text is lifted verbatim from Ben Wing's comments in
@file{ExternalShell.c}.

This is a special Shell that is designed to use an externally-
provided window created by someone else (possibly another process).
That other window should have an associated widget of class
ExternalClient.  The two widgets communicate with each other using
ClientMessage events and properties on the external window.

Ideally this feature should be independent of Emacs.  Unfortunately
there are lots and lots of specifics that need to be dealt with
for this to work properly, and some of them can't conveniently
be handled within the widget's methods.  Some day the code may
be rewritten so that the embedded-widget feature can be used by
any application, with appropriate entry points that are called
at specific points within the application.

This feature is similar to the OLE (Object Linking & Embedding)
feature provided by MS Windows.

Communication between this shell and the client widget:

Communication is through ClientMessage events with message_type
EXTW_NOTIFY and format 32.  Both the shell and the client widget
communicate with each other by sending the message to the same
window (the "external window" below), and the data.l[0] value is
used to determine who sent the message.

The data is formatted as follows:

data.l[0] = who sent this message: external_shell_send (0) or
            external_client_send (1)
data.l[1] = message type (see enum en_extw_notify below)
data.l[2-4] = data associated with this message

EventHandler() handles messages from the other side.

extw_send_notify_3() sends a message to the other side.

extw_send_geometry_value() is used when an XtWidgetGeometry structure
   needs to be sent.  This is too much data to fit into a
   ClientMessage, so the data is stored in a property and then
   extw_send_notify_3() is called.

extw_get_geometry_value() receives an XtWidgetGeometry structure from a
   property.

extw_wait_for_response() is used when a response to a sent message
   is expected.  It looks for a matching event within a
   particular timeout.

The particular message types are as follows:

1) extw_notify_init (event_window, event_mask)

This is sent from the shell to the client after the shell realizes
its EmacsFrame widget on the client's "external window".  This
tells the client that it should start passing along events of the
types specified in event_mask.  event_window specifies the window
of the EmacsFrame widget, which is a child of the client's
external window.

extw_notify_init (client_type)

When the client receives an extw_notify_init message from the
shell, it sends back a message of the same sort specifying the type
of the toolkit used by the client (Motif, generic Xt, or Xlib).

2) extw_notify_end ()

This is sent from the shell to the client when the shell's
EmacsFrame widget is destroyed, and tells the client to stop
passing events along.

3) extw_notify_qg (result)

This is sent from the client to the shell when a QueryGeometry
request is received on the client.  The XtWidgetGeometry structure
specified in the QueryGeometry request is passed on in the
EXTW_QUERY_GEOMETRY property (of type EXTW_WIDGET_GEOMETRY) on the
external window.  result is unused.

In response, the shell passes the QueryGeometry request down the
widget tree, and when a response is received, sends a message of
type extw_notify_qg back to the client, with result specifying the
GeometryResult value.  If this value is XtGeometryAlmost, the
returned XtWidgetGeometry structure is stored into the same property
as above. [BPW is there a possible race condition here?]

4) extw_notify_gm (result)

A very similar procedure to that for extw_notify_qg is followed
when the shell's RootGeometryManager method is called, indicating
that a child widget wishes to change the shell's geometry.  The
XtWidgetGeometry structure is stored in the EXTW_GEOMETRY_MANAGER
property.

5) extw_notify_focus_in (), extw_notify_focus_out ()

These are sent from the client to the shell when the client gains
or loses the keyboard focus.  It is done this way because Xt
maintains its own concept of keyboard focus and only the client
knows this information.

@summarycontents
@contents
@bye