This is ../info/lispref.info, produced by makeinfo version 4.0b from lispref/lispref.texi. INFO-DIR-SECTION XEmacs Editor START-INFO-DIR-ENTRY * Lispref: (lispref). XEmacs Lisp Reference Manual. END-INFO-DIR-ENTRY Edition History: GNU Emacs Lisp Reference Manual Second Edition (v2.01), May 1993 GNU Emacs Lisp Reference Manual Further Revised (v2.02), August 1993 Lucid Emacs Lisp Reference Manual (for 19.10) First Edition, March 1994 XEmacs Lisp Programmer's Manual (for 19.12) Second Edition, April 1995 GNU Emacs Lisp Reference Manual v2.4, June 1995 XEmacs Lisp Programmer's Manual (for 19.13) Third Edition, July 1995 XEmacs Lisp Reference Manual (for 19.14 and 20.0) v3.1, March 1996 XEmacs Lisp Reference Manual (for 19.15 and 20.1, 20.2, 20.3) v3.2, April, May, November 1997 XEmacs Lisp Reference Manual (for 21.0) v3.3, April 1998 Copyright (C) 1990, 1991, 1992, 1993, 1994, 1995 Free Software Foundation, Inc. Copyright (C) 1994, 1995 Sun Microsystems, Inc. Copyright (C) 1995, 1996 Ben Wing. Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Foundation. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the section entitled "GNU General Public License" is included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the section entitled "GNU General Public License" may be included in a translation approved by the Free Software Foundation instead of in the original English.  File: lispref.info, Node: Grabs, Prev: Server Data, Up: X Server Restricting Access to the Server by Other Apps ---------------------------------------------- - Function: x-grab-keyboard &optional device This function grabs the keyboard on the given device (defaulting to the selected one). So long as the keyboard is grabbed, all keyboard events will be delivered to XEmacs--it is not possible for other X clients to eavesdrop on them. Ungrab the keyboard with `x-ungrab-keyboard' (use an `unwind-protect'). Returns `t' if the grab was successful; `nil' otherwise. - Function: x-ungrab-keyboard &optional device This function releases a keyboard grab made with `x-grab-keyboard'. - Function: x-grab-pointer &optional device cursor ignore-keyboard This function grabs the pointer and restricts it to its current window. If optional DEVICE argument is `nil', the selected device will be used. If optional CURSOR argument is non-`nil', change the pointer shape to that until `x-ungrab-pointer' is called (it should be an object returned by the `make-cursor' function). If the second optional argument IGNORE-KEYBOARD is non-`nil', ignore all keyboard events during the grab. Returns `t' if the grab is successful, `nil' otherwise. - Function: x-ungrab-pointer &optional device This function releases a pointer grab made with `x-grab-pointer'. If optional first arg DEVICE is `nil' the selected device is used. If it is `t' the pointer will be released on all X devices.  File: lispref.info, Node: X Miscellaneous, Prev: X Server, Up: X-Windows Miscellaneous X Functions and Variables ======================================= - Variable: x-bitmap-file-path This variable holds a list of the directories in which X bitmap files may be found. If `nil', this is initialized from the `"*bitmapFilePath"' resource. This is used by the `make-image-instance' function (however, note that if the environment variable `XBMLANGPATH' is set, it is consulted first). - Variable: x-library-search-path This variable holds the search path used by `read-color' to find `rgb.txt'. - Function: x-valid-keysym-name-p keysym This function returns true if KEYSYM names a keysym that the X library knows about. Valid keysyms are listed in the files `/usr/include/X11/keysymdef.h' and in `/usr/lib/X11/XKeysymDB', or whatever the equivalents are on your system. - Function: x-window-id &optional frame This function returns the ID of the X11 window. This gives us a chance to manipulate the Emacs window from within a different program. Since the ID is an unsigned long, we return it as a string. - Variable: x-allow-sendevents If non-`nil', synthetic events are allowed. `nil' means they are ignored. Beware: allowing XEmacs to process SendEvents opens a big security hole. - Function: x-debug-mode arg &optional device With a true arg, make the connection to the X server synchronous. With false, make it asynchronous. Synchronous connections are much slower, but are useful for debugging. (If you get X errors, make the connection synchronous, and use a debugger to set a breakpoint on `x_error_handler'. Your backtrace of the C stack will now be useful. In asynchronous mode, the stack above `x_error_handler' isn't helpful because of buffering.) If DEVICE is not specified, the selected device is assumed. Calling this function is the same as calling the C function `XSynchronize', or starting the program with the `-sync' command line argument. - Variable: x-debug-events If non-zero, debug information about events that XEmacs sees is displayed. Information is displayed on stderr. Currently defined values are: * 1 == non-verbose output * 2 == verbose output  File: lispref.info, Node: ToolTalk Support, Next: LDAP Support, Prev: X-Windows, Up: Top ToolTalk Support **************** * Menu: * XEmacs ToolTalk API Summary:: * Sending Messages:: * Receiving Messages::  File: lispref.info, Node: XEmacs ToolTalk API Summary, Next: Sending Messages, Up: ToolTalk Support XEmacs ToolTalk API Summary =========================== The XEmacs Lisp interface to ToolTalk is similar, at least in spirit, to the standard C ToolTalk API. Only the message and pattern parts of the API are supported at present; more of the API could be added if needed. The Lisp interface departs from the C API in a few ways: * ToolTalk is initialized automatically at XEmacs startup-time. Messages can only be sent other ToolTalk applications connected to the same X11 server that XEmacs is running on. * There are fewer entry points; polymorphic functions with keyword arguments are used instead. * The callback interface is simpler and marginally less functional. A single callback may be associated with a message or a pattern; the callback is specified with a Lisp symbol (the symbol should have a function binding). * The session attribute for messages and patterns is always initialized to the default session. * Anywhere a ToolTalk enum constant, e.g. `TT_SESSION', is valid, one can substitute the corresponding symbol, e.g. `'TT_SESSION'. This simplifies building lists that represent messages and patterns.  File: lispref.info, Node: Sending Messages, Next: Receiving Messages, Prev: XEmacs ToolTalk API Summary, Up: ToolTalk Support Sending Messages ================ * Menu: * Example of Sending Messages:: * Elisp Interface for Sending Messages::  File: lispref.info, Node: Example of Sending Messages, Next: Elisp Interface for Sending Messages, Up: Sending Messages Example of Sending Messages --------------------------- Here's a simple example that sends a query to another application and then displays its reply. Both the query and the reply are stored in the first argument of the message. (defun tooltalk-random-query-handler (msg) (let ((state (get-tooltalk-message-attribute msg 'state))) (cond ((eq state 'TT_HANDLED) (message (get-tooltalk-message-attribute msg arg_val 0))) ((memq state '(TT_FAILED TT_REJECTED)) (message "Random query turns up nothing"))))) (defvar random-query-message '( class TT_REQUEST scope TT_SESSION address TT_PROCEDURE op "random-query" args '((TT_INOUT "?" "string")) callback tooltalk-random-query-handler)) (let ((m (make-tooltalk-message random-query-message))) (send-tooltalk-message m))  File: lispref.info, Node: Elisp Interface for Sending Messages, Prev: Example of Sending Messages, Up: Sending Messages Elisp Interface for Sending Messages ------------------------------------ - Function: make-tooltalk-message attributes Create a ToolTalk message and initialize its attributes. The value of ATTRIBUTES must be a list of alternating keyword/values, where keywords are symbols that name valid message attributes. For example: (make-tooltalk-message '(class TT_NOTICE scope TT_SESSION address TT_PROCEDURE op "do-something" args ("arg1" 12345 (TT_INOUT "arg3" "string")))) Values must always be strings, integers, or symbols that represent ToolTalk constants. Attribute names are the same as those supported by `set-tooltalk-message-attribute', plus `args'. The value of `args' should be a list of message arguments where each message argument has the following form: `(mode [value [type]])' or just `value' Where MODE is one of `TT_IN', `TT_OUT', or `TT_INOUT' and TYPE is a string. If TYPE isn't specified then `int' is used if VALUE is a number; otherwise `string' is used. If TYPE is `string' then VALUE is converted to a string (if it isn't a string already) with `prin1-to-string'. If only a value is specified then MODE defaults to `TT_IN'. If MODE is `TT_OUT' then VALUE and TYPE don't need to be specified. You can find out more about the semantics and uses of ToolTalk message arguments in chapter 4 of the `ToolTalk Programmer's Guide'. - Function: send-tooltalk-message msg Send the message on its way. Once the message has been sent it's almost always a good idea to get rid of it with `destroy-tooltalk-message'. - Function: return-tooltalk-message msg &optional mode Send a reply to this message. The second argument can be `reply', `reject' or `fail'; the default is `reply'. Before sending a reply, all message arguments whose mode is `TT_INOUT' or `TT_OUT' should have been filled in--see `set-tooltalk-message-attribute'. - Function: get-tooltalk-message-attribute msg attribute &optional argn Returns the indicated ToolTalk message attribute. Attributes are identified by symbols with the same name (underscores and all) as the suffix of the ToolTalk `tt_message_' function that extracts the value. String attribute values are copied and enumerated type values (except disposition) are converted to symbols; e.g. `TT_HANDLER' is `'TT_HANDLER', `uid' and `gid' are represented by fixnums (small integers), `opnum' is converted to a string, and `disposition' is converted to a fixnum. We convert `opnum' (a C int) to a string (e.g. `123' => `"123"') because there's no guarantee that opnums will fit within the range of XEmacs Lisp integers. [TBD] Use the `plist' attribute instead of C API `user' attribute for user-defined message data. To retrieve the value of a message property, specify the indicator for ARGN. For example, to get the value of a property called `rflag', use (get-tooltalk-message-attribute msg 'plist 'rflag) To get the value of a message argument use one of the `arg_val' (strings), `arg_ival' (integers), or `arg_bval' (strings with embedded nulls), attributes. For example, to get the integer value of the third argument: (get-tooltalk-message-attribute msg 'arg_ival 2) As you can see, argument numbers are zero-based. The type of each arguments can be retrieved with the `arg_type' attribute; however ToolTalk doesn't define any semantics for the string value of `arg_type'. Conventionally `string' is used for strings and `int' for 32 bit integers. Note that XEmacs Lisp stores the lengths of strings explicitly (unlike C) so treating the value returned by `arg_bval' like a string is fine. - Function: set-tooltalk-message-attribute value msg attribute &optional argn Initialize one ToolTalk message attribute. Attribute names and values are the same as for `get-tooltalk-message-attribute'. A property list is provided for user data (instead of the `user' message attribute); see `get-tooltalk-message-attribute'. Callbacks are handled slightly differently than in the C ToolTalk API. The value of CALLBACK should be the name of a function of one argument. It will be called each time the state of the message changes. This is usually used to notice when the message's state has changed to `TT_HANDLED' (or `TT_FAILED'), so that reply argument values can be used. If one of the argument attributes is specified as `arg_val', `arg_ival', or `arg_bval', then ARGN must be the number of an already created argument. Arguments can be added to a message with `add-tooltalk-message-arg'. - Function: add-tooltalk-message-arg msg mode type &optional value Append one new argument to the message. MODE must be one of `TT_IN', `TT_INOUT', or `TT_OUT', TYPE must be a string, and VALUE can be a string or an integer. ToolTalk doesn't define any semantics for TYPE, so only the participants in the protocol you're using need to agree what types mean (if anything). Conventionally `string' is used for strings and `int' for 32 bit integers. Arguments can initialized by providing a value or with `set-tooltalk-message-attribute'; the latter is necessary if you want to initialize the argument with a string that can contain embedded nulls (use `arg_bval'). - Function: create-tooltalk-message &optional no-callback Create a new ToolTalk message. The message's session attribute is initialized to the default session. Other attributes can be initialized with `set-tooltalk-message-attribute'. `make-tooltalk-message' is the preferred way to create and initialize a message. Optional arg NO-CALLBACK says don't add a C-level callback at all. Normally don't do that; just don't specify the Lisp callback when calling `make-tooltalk-message'. - Function: destroy-tooltalk-message msg Apply `tt_message_destroy' to the message. It's not necessary to destroy messages after they've been processed by a message or pattern callback, the Lisp/ToolTalk callback machinery does this for you.  File: lispref.info, Node: Receiving Messages, Prev: Sending Messages, Up: ToolTalk Support Receiving Messages ================== * Menu: * Example of Receiving Messages:: * Elisp Interface for Receiving Messages::  File: lispref.info, Node: Example of Receiving Messages, Next: Elisp Interface for Receiving Messages, Up: Receiving Messages Example of Receiving Messages ----------------------------- Here's a simple example of a handler for a message that tells XEmacs to display a string in the mini-buffer area. The message operation is called `emacs-display-string'. Its first (0th) argument is the string to display. (defun tooltalk-display-string-handler (msg) (message (get-tooltalk-message-attribute msg 'arg_val 0))) (defvar display-string-pattern '(category TT_HANDLE scope TT_SESSION op "emacs-display-string" callback tooltalk-display-string-handler)) (let ((p (make-tooltalk-pattern display-string-pattern))) (register-tooltalk-pattern p))  File: lispref.info, Node: Elisp Interface for Receiving Messages, Prev: Example of Receiving Messages, Up: Receiving Messages Elisp Interface for Receiving Messages -------------------------------------- - Function: make-tooltalk-pattern attributes Create a ToolTalk pattern and initialize its attributes. The value of attributes must be a list of alternating keyword/values, where keywords are symbols that name valid pattern attributes or lists of valid attributes. For example: (make-tooltalk-pattern '(category TT_OBSERVE scope TT_SESSION op ("operation1" "operation2") args ("arg1" 12345 (TT_INOUT "arg3" "string")))) Attribute names are the same as those supported by `add-tooltalk-pattern-attribute', plus `'args'. Values must always be strings, integers, or symbols that represent ToolTalk constants or lists of same. When a list of values is provided all of the list elements are added to the attribute. In the example above, messages whose `op' attribute is `"operation1"' or `"operation2"' would match the pattern. The value of ARGS should be a list of pattern arguments where each pattern argument has the following form: `(mode [value [type]])' or just `value' Where MODE is one of `TT_IN', `TT_OUT', or `TT_INOUT' and TYPE is a string. If TYPE isn't specified then `int' is used if VALUE is a number; otherwise `string' is used. If TYPE is `string' then VALUE is converted to a string (if it isn't a string already) with `prin1-to-string'. If only a value is specified then MODE defaults to `TT_IN'. If MODE is `TT_OUT' then VALUE and TYPE don't need to be specified. You can find out more about the semantics and uses of ToolTalk pattern arguments in chapter 3 of the `ToolTalk Programmer's Guide'. - Function: register-tooltalk-pattern pattern XEmacs will begin receiving messages that match this pattern. - Function: unregister-tooltalk-pattern pattern XEmacs will stop receiving messages that match this pattern. - Function: add-tooltalk-pattern-attribute value pattern indicator Add one value to the indicated pattern attribute. The names of attributes are the same as the ToolTalk accessors used to set them less the `tooltalk_pattern_' prefix and the `_add' suffix. For example, the name of the attribute for the `tt_pattern_disposition_add' attribute is `disposition'. The `category' attribute is handled specially, since a pattern can only be a member of one category (`TT_OBSERVE' or `TT_HANDLE'). Callbacks are handled slightly differently than in the C ToolTalk API. The value of CALLBACK should be the name of a function of one argument. It will be called each time the pattern matches an incoming message. - Function: add-tooltalk-pattern-arg pattern mode vtype &optional value Add one fully-specified argument to a ToolTalk pattern. MODE must be one of `TT_IN', `TT_INOUT', or `TT_OUT'. VTYPE must be a string. VALUE can be an integer, string or `nil'. If VALUE is an integer then an integer argument (`tt_pattern_iarg_add') is added; otherwise a string argument is added. At present there's no way to add a binary data argument. - Function: create-tooltalk-pattern Create a new ToolTalk pattern and initialize its session attribute to be the default session. - Function: destroy-tooltalk-pattern pattern Apply `tt_pattern_destroy' to the pattern. This effectively unregisters the pattern. - Function: describe-tooltalk-message msg &optional stream Print the message's attributes and arguments to STREAM. This is often useful for debugging.  File: lispref.info, Node: LDAP Support, Next: PostgreSQL Support, Prev: ToolTalk Support, Up: Top LDAP Support ************ XEmacs can be linked with a LDAP client library to provide Elisp primitives to access directory servers using the Lightweight Directory Access Protocol. * Menu: * Building XEmacs with LDAP support:: How to add LDAP support to XEmacs * XEmacs LDAP API:: Lisp access to LDAP functions * Syntax of Search Filters:: A brief summary of RFC 1558  File: lispref.info, Node: Building XEmacs with LDAP support, Next: XEmacs LDAP API, Prev: LDAP Support, Up: LDAP Support Building XEmacs with LDAP support ================================= LDAP support must be added to XEmacs at build time since it requires linking to an external LDAP client library. As of 21.2, XEmacs has been successfully built and tested with * OpenLDAP 1.2 () * University of Michigan's LDAP 3.3 () * LDAP SDK 1.0 from Netscape Corp. () Other libraries conforming to RFC 1823 will probably work also but may require some minor tweaking at C level. The standard XEmacs configure script auto-detects an installed LDAP library provided the library itself and the corresponding header files can be found in the library and include paths. A successful detection will be signalled in the final output of the configure script.  File: lispref.info, Node: XEmacs LDAP API, Next: Syntax of Search Filters, Prev: Building XEmacs with LDAP support, Up: LDAP Support XEmacs LDAP API =============== XEmacs LDAP API consists of two layers: a low-level layer which tries to stay as close as possible to the C API (where practical) and a higher-level layer which provides more convenient primitives to effectively use LDAP. The low-level API should be used directly for very specific purposes (such as multiple operations on a connection) only. The higher-level functions provide a more convenient way to access LDAP directories hiding the subtleties of handling the connection, translating arguments and ensuring compliance with LDAP internationalization rules and formats (currently partly implemented only). * Menu: * LDAP Variables:: Lisp variables related to LDAP * The High-Level LDAP API:: High-level LDAP lisp functions * The Low-Level LDAP API:: Low-level LDAP lisp primitives * LDAP Internationalization:: I18n variables and functions  File: lispref.info, Node: LDAP Variables, Next: The High-Level LDAP API, Prev: XEmacs LDAP API, Up: XEmacs LDAP API LDAP Variables -------------- - Variable: ldap-default-host The default LDAP server hostname. A TCP port number can be appended to that name using a colon as a separator. - Variable: ldap-default-port Default TCP port for LDAP connections. Initialized from the LDAP library. Default value is 389. - Variable: ldap-default-base Default base for LDAP searches. This is a string using the syntax of RFC 1779. For instance, "o=ACME, c=US" limits the search to the Acme organization in the United States. - Variable: ldap-host-parameters-alist An alist of per host options for LDAP transactions. The list elements look like `(HOST PROP1 VAL1 PROP2 VAL2 ...)' HOST is the name of an LDAP server. A TCP port number can be appended to that name using a colon as a separator. PROPN and VALN are property/value pairs describing parameters for the server. Valid properties: `binddn' The distinguished name of the user to bind as. This may look like `cn=Babs Jensen,o=ACME,c=US', see RFC 1779 for details. `passwd' The password to use for authentication. `auth' The authentication method to use, possible values depend on the LDAP library XEmacs was compiled with, they may include `simple', `krbv41' and `krbv42'. `base' The base for the search. This may look like `cÿ, o¬me', see RFC 1779 for syntax details. `scope' One of the symbols `base', `onelevel' or `subtree' indicating the scope of the search limited to a base object, to a single level or to the whole subtree. `deref' The dereference policy is one of the symbols `never', `always', `search' or `find' and defines how aliases are dereferenced. `never' Aliases are never dereferenced `always' Aliases are always dereferenced `search' Aliases are dereferenced when searching `find' Aliases are dereferenced when locating the base object for the search `timelimit' The timeout limit for the connection in seconds. `sizelimit' The maximum number of matches to return for searches performed on this connection. - Variable: ldap-verbose If non-`nil', LDAP operations will echo progress messages. Defaults to `nil'.  File: lispref.info, Node: The High-Level LDAP API, Next: The Low-Level LDAP API, Prev: LDAP Variables, Up: XEmacs LDAP API The High-Level LDAP API ----------------------- The following functions provide the most convenient interface to perform LDAP operations. All of them open a connection to a host, perform an operation (add/search/modify/delete) on one or several entries and cleanly close the connection thus insulating the user from all the details of the low-level interface such as LDAP Lisp objects *note The Low-Level LDAP API::. Note that `ldap-search' which used to be the name of the high-level search function in XEmacs 21.1 is now obsolete. For consistency in the naming as well as backward compatibility, that function now acts as a wrapper that calls either `ldap-search-basic' (low-level search function) or `ldap-search-entries' (high-level search function) according to the actual parameters. A direct call to one of these two functions is preferred since it is faster and unambiguous. - Command: ldap-search-entries filter &optional host attributes attrsonly withdn Perform an LDAP search. FILTER is the search filter *note Syntax of Search Filters:: HOST is the LDAP host on which to perform the search. ATTRIBUTES is the specific attributes to retrieve, `nil' means retrieve all. ATTRSONLY if non-`nil' retrieves the attributes only without their associated values. If WITHDN is non-`nil' each entry in the result will be prepended with its distinguished name DN. Additional search parameters can be specified through `ldap-host-parameters-alist'. The function returns a list of matching entries. Each entry is itself an alist of attribute/value pairs optionally preceded by the DN of the entry according to the value of WITHDN. - Function: ldap-add-entries entries &optional host binddn passwd Add entries to an LDAP directory. ENTRIES is a list of entry specifications of the form `(DN (ATTR . VALUE) (ATTR . VALUE) ...)' where DN the distinguished name of an entry to add, the following are cons cells containing attribute/value string pairs. HOST is the LDAP host, defaulting to `ldap-default-host'. BINDDN is the DN to bind as to the server. PASSWD is the corresponding password. - Function: ldap-modify-entries entry-mods &optional host binddn passwd Modify entries of an LDAP directory. ENTRY_MODS is a list of entry modifications of the form `(DN MOD-SPEC1 MOD-SPEC2 ...)' where DN is the distinguished name of the entry to modify, the following are modification specifications. A modification specification is itself a list of the form `(MOD-OP ATTR VALUE1 VALUE2 ...)' MOD-OP and ATTR are mandatory, VALUES are optional depending on MOD-OP. MOD-OP is the type of modification, one of the symbols `add', `delete' or `replace'. ATTR is the LDAP attribute type to modify. HOST is the LDAP host, defaulting to `ldap-default-host'. BINDDN is the DN to bind as to the server. PASSWD is the corresponding password. - Function: ldap-delete-entries dn &optional host binddn passwd Delete an entry from an LDAP directory. DN is the distinguished name of an entry to delete or a list of those. HOST is the LDAP host, defaulting to `ldap-default-host'. BINDDN is the DN to bind as to the server. PASSWD is the corresponding password.  File: lispref.info, Node: The Low-Level LDAP API, Next: LDAP Internationalization, Prev: The High-Level LDAP API, Up: XEmacs LDAP API The Low-Level LDAP API ---------------------- The low-level API should be used directly for very specific purposes (such as multiple operations on a connection) only. The higher-level functions provide a more convenient way to access LDAP directories hiding the subtleties of handling the connection, translating arguments and ensuring compliance with LDAP internationalization rules and formats (currently partly implemented only). See *note The High-Level LDAP API:: Note that the former functions `ldap-*-internal' functions have been renamed in XEmacs 21.2 * Menu: * The LDAP Lisp Object:: * Opening and Closing a LDAP Connection:: * Low-level Operations on a LDAP Server::  File: lispref.info, Node: The LDAP Lisp Object, Next: Opening and Closing a LDAP Connection, Prev: The Low-Level LDAP API, Up: The Low-Level LDAP API The LDAP Lisp Object .................... An internal built-in `ldap' lisp object represents a LDAP connection. - Function: ldapp object This function returns non-`nil' if OBJECT is a `ldap' object. - Function: ldap-host ldap Return the server host of the connection represented by LDAP. - Function: ldap-live-p ldap Return non-`nil' if LDAP is an active LDAP connection.  File: lispref.info, Node: Opening and Closing a LDAP Connection, Next: Low-level Operations on a LDAP Server, Prev: The LDAP Lisp Object, Up: The Low-Level LDAP API Opening and Closing a LDAP Connection ..................................... - Function: ldap-open host &optional plist Open a LDAP connection to HOST. PLIST is a property list containing additional parameters for the connection. Valid keys in that list are: `port' The TCP port to use for the connection if different from `ldap-default-port' or the library builtin value `auth' The authentication method to use, possible values depend on the LDAP library XEmacs was compiled with, they may include `simple', `krbv41' and `krbv42'. `binddn' The distinguished name of the user to bind as. This may look like `c=com, o=Acme, cn=Babs Jensen', see RFC 1779 for details. `passwd' The password to use for authentication. `deref' The dereference policy is one of the symbols `never', `always', `search' or `find' and defines how aliases are dereferenced. `never' Aliases are never dereferenced. `always' Aliases are always dereferenced. `search' Aliases are dereferenced when searching. `find' Aliases are dereferenced when locating the base object for the search. The default is `never'. `timelimit' The timeout limit for the connection in seconds. `sizelimit' The maximum number of matches to return for searches performed on this connection. - Function: ldap-close ldap Close the connection represented by LDAP.  File: lispref.info, Node: Low-level Operations on a LDAP Server, Prev: Opening and Closing a LDAP Connection, Up: The Low-Level LDAP API Low-level Operations on a LDAP Server ..................................... `ldap-search-basic' is the low-level primitive to perform a search on a LDAP server. It works directly on an open LDAP connection thus requiring a preliminary call to `ldap-open'. Multiple searches can be made on the same connection, then the session must be closed with `ldap-close'. - Function: ldap-search-basic ldap filter &optional base scope attrs attrsonly withdn verbose Perform a search on an open connection LDAP created with `ldap-open'. FILTER is a filter string for the search *note Syntax of Search Filters:: BASE is the distinguished name at which to start the search. SCOPE is one of the symbols `base', `onelevel' or `subtree' indicating the scope of the search limited to a base object, to a single level or to the whole subtree. The default is `subtree'. ATTRS is a list of strings indicating which attributes to retrieve for each matching entry. If `nil' all available attributes are returned. If ATTRSONLY is non-`nil' then only the attributes are retrieved, not their associated values. If WITHDN is non-`nil' then each entry in the result is prepended with its distinguished name DN. If VERBOSE is non-`nil' then progress messages are echoed The function returns a list of matching entries. Each entry is itself an alist of attribute/value pairs optionally preceded by the DN of the entry according to the value of WITHDN. - Function: ldap-add ldap dn entry Add ENTRY to a LDAP directory which a connection LDAP has been opened to with `ldap-open'. DN is the distinguished name of the entry to add. ENTRY is an entry specification, i.e., a list of cons cells containing attribute/value string pairs. - Function: ldap-modify ldap dn mods Modify an entry in an LDAP directory. LDAP is an LDAP connection object created with `ldap-open'. DN is the distinguished name of the entry to modify. MODS is a list of modifications to apply. A modification is a list of the form `(MOD-OP ATTR VALUE1 VALUE2 ...)' MOD-OP and ATTR are mandatory, VALUES are optional depending on MOD-OP. MOD-OP is the type of modification, one of the symbols `add', `delete' or `replace'. ATTR is the LDAP attribute type to modify. - Function: ldap-delete ldap dn Delete an entry to an LDAP directory. LDAP is an LDAP connection object created with `ldap-open'. DN is the distinguished name of the entry to delete.  File: lispref.info, Node: LDAP Internationalization, Prev: The Low-Level LDAP API, Up: XEmacs LDAP API LDAP Internationalization ------------------------- The XEmacs LDAP API provides basic internationalization features based on the LDAP v3 specification (essentially RFC2252 on "LDAP v3 Attribute Syntax Definitions"). Unfortunately since there is currently no free LDAP v3 server software, this part has not received much testing and should be considered experimental. The framework is in place though. - Function: ldap-decode-attribute attr Decode the attribute/value pair ATTR according to LDAP rules. The attribute name is looked up in `ldap-attribute-syntaxes-alist' and the corresponding decoder is then retrieved from `ldap-attribute-syntax-decoders'' and applied on the value(s). * Menu: * LDAP Internationalization Variables:: * Encoder/Decoder Functions::  File: lispref.info, Node: LDAP Internationalization Variables, Next: Encoder/Decoder Functions, Prev: LDAP Internationalization, Up: LDAP Internationalization LDAP Internationalization Variables ................................... - Variable: ldap-ignore-attribute-codings If non-`nil', no encoding/decoding will be performed LDAP attribute values - Variable: ldap-coding-system Coding system of LDAP string values. LDAP v3 specifies the coding system of strings to be UTF-8. You need an XEmacs with Mule support for this. - Variable: ldap-default-attribute-decoder Decoder function to use for attributes whose syntax is unknown. Such a function receives an encoded attribute value as a string and should return the decoded value as a string. - Variable: ldap-attribute-syntax-encoders A vector of functions used to encode LDAP attribute values. The sequence of functions corresponds to the sequence of LDAP attribute syntax object identifiers of the form 1.3.6.1.4.1.1466.1115.121.1.* as defined in RFC2252 section 4.3.2. As of this writing, only a few encoder functions are available. - Variable: ldap-attribute-syntax-decoders A vector of functions used to decode LDAP attribute values. The sequence of functions corresponds to the sequence of LDAP attribute syntax object identifiers of the form 1.3.6.1.4.1.1466.1115.121.1.* as defined in RFC2252 section 4.3.2. As of this writing, only a few decoder functions are available. - Variable: ldap-attribute-syntaxes-alist A map of LDAP attribute names to their type object id minor number. This table is built from RFC2252 Section 5 and RFC2256 Section 5.  File: lispref.info, Node: Encoder/Decoder Functions, Prev: LDAP Internationalization Variables, Up: LDAP Internationalization Encoder/Decoder Functions ......................... - Function: ldap-encode-boolean bool A function that encodes an elisp boolean BOOL into a LDAP boolean string representation. - Function: ldap-decode-boolean str A function that decodes a LDAP boolean string representation STR into an elisp boolean. - Function: ldap-decode-string str Decode a string STR according to LDAP-CODING-SYSTEM. - Function: ldap-encode-string str Encode a string STR according to LDAP-CODING-SYSTEM. - Function: ldap-decode-address str Decode an address STR according to LDAP-CODING-SYSTEM and replacing $ signs with newlines as specified by LDAP encoding rules for addresses. - Function: ldap-encode-address str Encode an address STR according to LDAP-CODING-SYSTEM and replacing newlines with $ signs as specified by LDAP encoding rules for addresses.  File: lispref.info, Node: Syntax of Search Filters, Prev: XEmacs LDAP API, Up: LDAP Support Syntax of Search Filters ======================== LDAP search functions use RFC1558 syntax to describe the search filter. In that syntax simple filters have the form: ( ) `' is an attribute name such as `cn' for Common Name, `o' for Organization, etc... `' is the corresponding value. This is generally an exact string but may also contain `*' characters as wildcards `filtertype' is one `=' `~=', `<=', `>=' which respectively describe equality, approximate equality, inferiority and superiority. Thus `(cn=John Smith)' matches all records having a canonical name equal to John Smith. A special case is the presence filter `(=*' which matches records containing a particular attribute. For instance `(mail=*)' matches all records containing a `mail' attribute. Simple filters can be connected together with the logical operators `&', `|' and `!' which stand for the usual and, or and not operators. `(&(objectClass=Person)(mail=*)(|(sn=Smith)(givenname=John)))' matches records of class `Person' containing a `mail' attribute and corresponding to people whose last name is `Smith' or whose first name is `John'.  File: lispref.info, Node: PostgreSQL Support, Next: Internationalization, Prev: LDAP Support, Up: Top PostgreSQL Support ****************** XEmacs can be linked with PostgreSQL libpq run-time support to provide relational database access from Emacs Lisp code. * Menu: * Building XEmacs with PostgreSQL support:: * XEmacs PostgreSQL libpq API:: * XEmacs PostgreSQL libpq Examples::  File: lispref.info, Node: Building XEmacs with PostgreSQL support, Next: XEmacs PostgreSQL libpq API, Up: PostgreSQL Support Building XEmacs with PostgreSQL support ======================================= XEmacs PostgreSQL support requires linking to the PostgreSQL libpq library. Describing how to build and install PostgreSQL is beyond the scope of this document. See the PostgreSQL manual for details. If you have installed XEmacs from one of the binary kits on (), or are using an XEmacs binary from a CD ROM, you may have XEmacs PostgreSQL support by default. `M-x describe-installation' will tell you if you do. If you are building XEmacs from source, you need to install PostgreSQL first. On some systems, PostgreSQL will come pre-installed in /usr. In this case, it should be autodetected when you run configure. If PostgreSQL is installed into its default location, `/usr/local/pgsql', you must specify `--site-prefixes=/usr/local/pgsql' when you run configure. If PostgreSQL is installed into another location, use that instead of `/usr/local/pgsql' when specifying `--site-prefixes'. As of XEmacs 21.2, PostgreSQL versions 6.5.3 and 7.0 are supported. XEmacs Lisp support for V7.0 is somewhat more extensive than support for V6.5. In particular, asynchronous queries are supported.  File: lispref.info, Node: XEmacs PostgreSQL libpq API, Next: XEmacs PostgreSQL libpq Examples, Prev: Building XEmacs with PostgreSQL support, Up: PostgreSQL Support XEmacs PostgreSQL libpq API =========================== The XEmacs PostgreSQL API is intended to be a policy-free, low-level binding to libpq. The intent is to provide all the basic functionality and then let high level Lisp code decide its own policies. This documentation assumes that the reader has knowledge of SQL, but requires no prior knowledge of libpq. There are many examples in this manual and some setup will be required. In order to run most of the following examples, the following code needs to be executed. In addition to the data is in this table, nearly all of the examples will assume that the free variable `P' refers to this database connection. The examples in the original edition of this manual were run against Postgres 7.0beta1. (progn (setq P (pq-connectdb "")) ;; id is the primary key, shikona is a Japanese word that ;; means `the professional name of a Sumo wrestler', and ;; rank is the Sumo rank name. (pq-exec P (concat "CREATE TABLE xemacs_test" " (id int, shikona text, rank text);")) (pq-exec P "COPY xemacs_test FROM stdin;") (pq-put-line P "1\tMusashimaru\tYokuzuna\n") (pq-put-line P "2\tDejima\tOozeki\n") (pq-put-line P "3\tMusoyama\tSekiwake\n") (pq-put-line P "4\tMiyabiyama\tSekiwake\n") (pq-put-line P "5\tWakanoyama\tMaegashira\n") (pq-put-line P "\\.\n") (pq-end-copy P)) => nil * Menu: * libpq Lisp Variables:: * libpq Lisp Symbols and DataTypes:: * Synchronous Interface Functions:: * Asynchronous Interface Functions:: * Large Object Support:: * Other libpq Functions:: * Unimplemented libpq Functions::  File: lispref.info, Node: libpq Lisp Variables, Next: libpq Lisp Symbols and DataTypes, Prev: XEmacs PostgreSQL libpq API, Up: XEmacs PostgreSQL libpq API libpq Lisp Variables -------------------- Various Unix environment variables are used by libpq to provide defaults to the many different parameters. In the XEmacs Lisp API, these environment variables are bound to Lisp variables to provide more convenient access to Lisp Code. These variables are passed to the backend database server during the establishment of a database connection and when the `pq-setenv' call is made. - Variable: pg:host Initialized from the PGHOST environment variable. The default host to connect to. - Variable: pg:user Initialized from the PGUSER environment variable. The default database user name. - Variable: pg:options Initialized from the PGOPTIONS environment variable. Default additional server options. - Variable: pg:port Initialized from the PGPORT environment variable. The default TCP port to connect to. - Variable: pg:tty Initialized from the PGTTY environment variable. The default debugging TTY. Compatibility note: Debugging TTYs are turned off in the XEmacs Lisp binding. - Variable: pg:database Initialized from the PGDATABASE environment variable. The default database to connect to. - Variable: pg:realm Initialized from the PGREALM environment variable. The default Kerberos realm. - Variable: pg:client-encoding Initialized from the PGCLIENTENCODING environment variable. The default client encoding. Compatibility note: This variable is not present in non-Mule XEmacsen. This variable is not present in versions of libpq prior to 7.0. In the current implementation, client encoding is equivalent to the `file-name-coding-system' format. - Variable: pg:authtype Initialized from the PGAUTHTYPE environment variable. The default authentication scheme used. Compatibility note: This variable is unused in versions of libpq after 6.5. It is not implemented at all in the XEmacs Lisp binding. - Variable: pg:geqo Initialized from the PGGEQO environment variable. Genetic optimizer options. - Variable: pg:cost-index Initialized from the PGCOSTINDEX environment variable. Cost index options. - Variable: pg:cost-heap Initialized from the PGCOSTHEAP environment variable. Cost heap options. - Variable: pg:tz Initialized from the PGTZ environment variable. Default timezone. - Variable: pg:date-style Initialized from the PGDATESTYLE environment variable. Default date style in returned date objects. - Variable: pg-coding-system This is a variable controlling which coding system is used to encode non-ASCII strings sent to the database. Compatibility Note: This variable is not present in InfoDock.