cleanup of code related to xfree(), better KKCC backtrace capabilities, document XD_INLINE_LISP_OBJECT_BLOCK_PTR, fix some memory leaks, other code cleanup -------------------- ChangeLog entries follow: -------------------- src/ChangeLog addition: 2010-03-24 Ben Wing <ben@xemacs.org> * array.h: * array.h (XD_LISP_DYNARR_DESC): * dumper.c (pdump_register_sub): * dumper.c (pdump_store_new_pointer_offsets): * dumper.c (pdump_reloc_one_mc): * elhash.c: * gc.c (lispdesc_one_description_line_size): * gc.c (kkcc_marking): * lrecord.h: * lrecord.h (IF_NEW_GC): * lrecord.h (enum memory_description_type): * lrecord.h (enum data_description_entry_flags): * lrecord.h (struct opaque_convert_functions): Rename XD_LISP_OBJECT_BLOCK_PTR to XD_INLINE_LISP_OBJECT_BLOCK_PTR and document it in lrecord.h. * data.c: * data.c (finish_marking_weak_lists): * data.c (continue_marking_ephemerons): * data.c (finish_marking_ephemerons): * elhash.c (MARK_OBJ): * gc.c: * gc.c (lispdesc_indirect_count_1): * gc.c (struct): * gc.c (kkcc_bt_push): * gc.c (kkcc_gc_stack_push): * gc.c (kkcc_gc_stack_push_lisp_object): * gc.c (kkcc_gc_stack_repush_dirty_object): * gc.c (KKCC_DO_CHECK_FREE): * gc.c (mark_object_maybe_checking_free): * gc.c (mark_struct_contents): * gc.c (mark_lisp_object_block_contents): * gc.c (register_for_finalization): * gc.c (mark_object): * gc.h: * lisp.h: * profile.c: * profile.c (mark_profiling_info_maphash): Clean up KKCC code related to DEBUG_XEMACS. Rename kkcc_backtrace() to kkcc_backtrace_1() and add two params: a `size' arg to control how many stack elements to print and a `detailed' arg to control whether Lisp objects are printed using `debug_print()'. Create front-ends to kkcc_backtrace_1() -- kkcc_detailed_backtrace(), kkcc_short_backtrace(), kkcc_detailed_backtrace_full(), kkcc_short_backtrace_full(), as well as shortened versions kbt(), kbts(), kbtf(), kbtsf() -- to call it with various parameter values. Add an `is_lisp' field to the stack and backtrace structures and use it to keep track of whether an object pushed onto the stack is a Lisp object or a non-Lisp structure; in kkcc_backtrace_1(), don't try to print a non-Lisp structure as a Lisp object. * elhash.c: * extents.c: * file-coding.c: * lrecord.h: * lrecord.h (IF_NEW_GC): * marker.c: * marker.c (Fmarker_buffer): * mule-coding.c: * number.c: * rangetab.c: * specifier.c: New macros IF_OLD_GC(), IF_NEW_GC() to simplify declaration of Lisp objects when a finalizer may exist in one but not the other. Use them appropriately. * extents.c (finalize_extent_info): Don't zero out data->soe and data->extents before trying to free, else we get memory leaks. * lrecord.h (enum lrecord_type): Make the first lrecord type have value 1 not 0 so that 0 remains without implementation and attempts to interpret zeroed memory as a Lisp object will be more obvious. * array.c (Dynarr_free): * device-msw.c (msprinter_delete_device): * device-tty.c (free_tty_device_struct): * device-tty.c (tty_delete_device): * dialog-msw.c (handle_directory_dialog_box): * dialog-x.c: * emacs.c (free_argc_argv): * emodules.c (attempt_module_delete): * file-coding.c (chain_finalize_coding_stream_1): * file-coding.c (chain_finalize_coding_stream): * glyphs-eimage.c: * glyphs-eimage.c (jpeg_instantiate_unwind): * glyphs-eimage.c (gif_instantiate_unwind): * glyphs-eimage.c (png_instantiate_unwind): * glyphs-eimage.c (tiff_instantiate_unwind): * imgproc.c: * imgproc.c (build_EImage_quantable): * insdel.c (uninit_buffer_text): * mule-coding.c (iso2022_finalize_detection_state): * objects-tty.c (tty_finalize_color_instance): * objects-tty.c (tty_finalize_font_instance): * objects-tty.c (tty_font_list): * process.c: * process.c (finalize_process): * redisplay.c (add_propagation_runes): * scrollbar-gtk.c: * scrollbar-gtk.c (gtk_free_scrollbar_instance): * scrollbar-gtk.c (gtk_release_scrollbar_instance): * scrollbar-msw.c: * scrollbar-msw.c (mswindows_free_scrollbar_instance): * scrollbar-msw.c (unshow_that_mofo): * scrollbar-x.c (x_free_scrollbar_instance): * scrollbar-x.c (x_release_scrollbar_instance): * select-x.c: * select-x.c (x_handle_selection_request): * syntax.c: * syntax.c (uninit_buffer_syntax_cache): * text.h (eifree): If possible, whenever we call xfree() on a field in a structure, set the field to 0 afterwards. A lot of code is written so that it checks the value being freed to see if it is non-zero before freeing it -- doing this and setting the value to 0 afterwards ensures (a) we won't try to free twice if the cleanup code is called twice; (b) if the object itself stays around, KKCC won't crash when attempting to mark the freed field. * rangetab.c: Add a finalization method when not NEW_GC to avoid memory leaks. (#### We still get memory leaks when NEW_GC; need to convert gap array to Lisp object).

@c -*-texinfo-*-
@c This is part of the XEmacs Lisp Reference Manual.
@c Copyright (C) 1998 Oliver Graf <ograf@fga.de>
@c Original reference is (c) 1990, 1991, 1992, 1993, 1994 Free Software Foundation, Inc.
@c See the file lispref.texi for copying conditions.
@setfilename ../../info/dragndrop.texi
@node Drag and Drop, Modes, Scrollbars, Top
@chapter Drag and Drop
@cindex drag and drop

@emph{WARNING}: the Drag'n'Drop API is still under development and the
interface may change! The current implementation is considered experimental.

  Drag'n'drop is a way to transfer information between multiple applications.
To do this several GUIs define their own protocols. Examples are CDE, Motif,
KDE, MSWindows, GNOME, and many more. To catch all these protocols, XEmacs
provides a generic API.

One prime idea behind the API is to use a data interface that is
transparent for all systems. The author thinks that this is best
archived by using URL and MIME data, cause any internet enabled system
must support these for email already. XEmacs also already provides
powerful interfaces to support these types of data (tm and w3).

@menu
* Supported Protocols:: Which low-level protocols are supported.
* Drop Interface::      How XEmacs handles a drop from another application.
* Drag Interface::      Calls to initiate a drag from XEmacs.
@end menu

@node Supported Protocols
@section Supported Protocols

The current release of XEmacs only support a small set of Drag'n'drop
protocols. Some of these only support limited options available in the API.

@menu
* CDE dt::              Common Desktop Environment used on suns.
* MSWindows OLE::       Mr. Gates way of live.
* Loose ends::          The other protocols.
@end menu

@node CDE dt
@subsection CDE dt
@cindex CDE dt

CDE stands for Common Desktop Environment. It is based on the Motif
widget library. It's drag'n'drop protocol is also an abstraction of the
Motif protocol (so it might be possible, that XEmacs will also support
the Motif protocol soon).

CDE has three different types: file, buffer, and text. XEmacs only uses
file and buffer drags. The API will disallow full URL drags, only file
method URLs are passed through.

Buffer drags are always converted to plain text.

@node MSWindows OLE
@subsection MSWindows OLE
@cindex MSWindows OLE

Only allows file drags and drops.

@node Loose ends
@subsection Loose ends

The following protocols will be supported soon: Xdnd, Motif, Xde (if I
get some specs).

In particular Xdnd will be one of the protocols that can benefit from
the XEmacs API, cause it also uses MIME types to encode dragged data.

@node Drop Interface
@section Drop Interface
@cindex drop
@cindex Drop API

For each activated low-level protocol, an internal routine will catch
incoming drops and convert them to a dragdrop-drop type
misc-user-event.

This misc-user-event has its function argument set to
@code{dragdrop-drop-dispatch} and the object contains the data of the drop
(converted to URL/MIME specific data). This function will search the variable
@code{experimental-dragdrop-drop-functions} for a function that can handle the
dropped data.

To modify the drop behavior, the user can modify the variable
@code{experimental-dragdrop-drop-functions}. Each element of this list
specifies a possible handler for dropped data. The first one that can handle
the data will return @code{t} and exit. Another possibility is to set a
extent-property with the same name. Extents are checked prior to the
variable.

The customization group @code{drag-n-drop} shows all variables of user
interest.

@node Drag Interface
@section Drag Interface
@cindex drag
@cindex Drag API

This describes the drag API (not implemented yet).