Copyright © 2002, 2003, 2004, 2005 Florent Georges

     [file drkm-lib.texi not included]

This manual describes drkm-lib, the drkm's GNU Emacs Lisp Library version 0.1.

What is drkm-lib ?
******************

Blah, blah, blah.

drkm
****

drkm-TMP
********

drkm-assert
***********

drkm-cl
*******

drkm-comments
*************

drkm-compat
***********

drkm-config
***********

Ce module définit un framework de configuration d'Emacs.  Il permet de configurer un mode (il devrait pouvoir configurer des packages, mais c'est pour l'instant plutôt des modes), cfr. drkm-conf:configure.  Il permet également de jouer au démarrage avec les fichiers subdirs.el et loaddefs.el, cfr. respectivement Config Subdirs et Config Loaddefs.

 -- Function: drkm-conf:init drkm-lib-dir
     Dirige l'initialisation personnelle d'Emacs, comme le load-path.  TODO: Fait beaucoup de choses.  Cfr. pour l'instant sa docstring, Config Subdirs et Config Loaddefs.

 -- Macro: drkm-conf:configure mode &key :config :auto-mode :interpreters :autoloads :autoload-files :font-lock :hooks :info-dirs

     Cette macro configure le mode mode, qui est un symbole non-quoté.

     Elle évalue une et une seule fois ses arguments (sauf mode).

     Elle délègue son travail aux fonctions, dans l'ordre, drkm-conf::configure-impl, drkm-conf::configure-config, drkm-conf::configure-font-lock, drkm-conf::configure-hooks, drkm-conf:add-list-to-info-path.  Voir la documentation de celles-ci pour plus de détails.

 -- Function: drkm-conf::configure-impl mode auto-mode interpreters autoloads autoload-files

 -- Function: drkm-conf::configure-config function feature
     Si function est nil, charge la feature.  Sinon, procède comme expliqué ci-desous.

     function est le symbole du mode à configurer, qui est une fonction.  Il faut requérir la feature lors du prochain appel de function.

     Selon la valeur de la function cell du symbole function, des choses différentes sont entreprises.

     Si function n'est pas liée à une fonction, on définit cette fonction, de manière à ce qu'à l'exécution, elle : (i) annulle sa définition (fboundp -> nil), (ii) charge la feature, (iii) exécute la fonction liée au symbole, avec les arguments reçus.

     Il faut donc que la feature définisse cette fonction.  Par exemple en chargeant un module exécutant un defun de cette fonction.

     Si function est un autoload, on remplace cette définition par une fonction qui, à l'éxécution : (i) replace l'autoload dans la définition de fonction du symbole, (ii) charge la feature, (iii) exécute la fonction liée au symbole, avec les arguments reçus.

     La feature peut donc définir cette fonction, par exemple en chargeant le module où elle est définie.  Sinon, la définition sera trouvée en fonction de l'autoload initial.

     Si function est une fonction, on crée un advice en tête de cette fonction, qui : (i) se supprime des advices de cette fonction, (ii) charge la feature, (iii) exécute la fonction liée au symbole, avec les arguments reçus.

     La feature ne devrait donc pas redéfinir la fonction, puisqu'elle est déjà définie.  Mais cela est possible.

     Dans tous les cas, c'est donc le même schéma.  On modifie la définition de fonction du symbole, de manière à ce qu'elle :

       restaure la définition originale ;

       charge la feature ;

       appelle effectivement la fonction avec les arguments qu'elle a elle-même reçus.

     feature est sensée configurer le mode mode, et la plupart du temps le définir.  Si le module définissant mode n'a pas encore été chargé, elle peut contrôler le moment du chargement.  Donc exécuter ce qui doit l'être avant le chargement du module, puis le charger, et enfin exécuter ce qui doit l'être après le chargement :

          (code-to-execute-before ...)
          (setq the-variable ...)

          (require 'the-mode)

          (code-to-execute-after ...)
          (setq the-constant ...)

          (provide 'config-the-mode)

 -- Function: drkm-conf::configure-font-lock mode &optional keywords

 -- Function: drkm-conf::configure-hooks mode &optional values

subdirs.el Files
================

Les fichiers subdirs.el permettent une certaine décentralisation de la configuration.  Leur intérêt se situe essentiellement au niveau de l'installation de packages.

Le principe est tout simple.  On part d'une liste de répertoires connus, que l'on parcours à la recherche de packages.  On charge (au moyen de load) le fichier subdirs.el présent dans ce répertoire.  Il peut alors ajouter certains des sous-répertoires au load-path, et recurser sur ceux-ci.

En fait, puisque l'on se sert de load, il s'agit de fichiers Emacs Lisp classiques, et ils peuvent faire tout et n'importe quoi. Il existe néanmoins quelques fonctions de support aux tâches les plus fréquentes dans ce genre de fichiers (l'ajout au load-path, l'ajout à Info-directory-list, la récursion sur les sous-répertoires, etc.), ce qui en fait en général de petits fichiers facilement maintenables.

L'intérêt est que ces fichiers se trouvent dans les répertoires qu'ils configurent.  Vous installez une nouvelle version d'un package, et vous aimez garder les noms de répertoire comprenant la version ?  Pas besoin de changer votre ~/.emacs (ou celui de chacun des utilisateurs de votre système).  Il suffit de modifier le subdirs.el du répertoire dans lequel vous avez installé le package.

Ils peuvent également contrôler le chargement (ou non) du fichier loaddefs.el de leur répertoire.  Config Loaddefs.

Leur lancement initial est dirigé par drkm-conf:init.

 -- User Option: drkm-conf:subdirs-file-name
     ...

 -- User Option: drkm-conf:subdirs-in-std-dirs-file-name
     ...

 -- Function: drkm-conf:subdirs-add-info-path info-dir &optional default-directory &key if-dir
     Ajoute des répertoires au path de recherche des fichiers Info, Info-directory-list.  info-dir peut être une chaîne de caractères ou une liste de chaînes de caractères.  Ces chaînes sont les noms des répertoires à ajouter.

     default-directory sert de répertoire courant pour les noms de répertoire relatifs.

     Si :if-dir est non-nil, seuls les répertoires contenant un fichier nommé dir sont pris en compte.  Il s'agit en effet d'une bonne pratique de fournir un fichier dir dans les répertoires du path des fichiers Info.

     TODO: Permettre que info-dir soit nil, auquel cas la liste est initialisée avec les noms des sous-répertoires de default-directory.

 -- Function: drkm-conf:subdirs-initialize-all-subdirs
     ...

 -- Function: drkm-conf:subdirs-initialize-dirs
     ...

loaddefs.el Files
=================

À RÉDIGER: [emacs]/lisp/autoloads.el fournit la base de la gestion des loaddefs.el, augmentée par cedet-autogen.el.  Cela semble suffisant, bien que je n'aime pas trop le mécanisme de sélection de fichiers de ce dernier. Son utilisation est :

     emacs -batch                            \
         -l cedet-autogen                    \
         -f cedet-batch-update-autoloads     \
         loaddefs.el [dir] [subdirs ...]

 -- User Option: drkm-conf:loaddefs-file-name
     TODO: ...

 -- User Option: drkm-conf:loaddefs-in-std-dirs-file-name
     TODO: ...

 -- User Option: drkm-conf:load-loaddefs-p
     TODO: ...

drkm-custom
***********

 -- Widget: drkm-cus:link
     Destiné à être employé associé au mot clef :link d'un defgroup ou d'un defcustom :

          (defgroup my-group nil
            ...
            :link '(drkm-cus:link "<INFO:my-pkg/Node My Group>"))

     On peut alors employer aussi bien des références d'Info (INFO), que des URLs (URL), des fichiers (FILE) ou des pages de wiki (WIKI).  Pour l'instant, seul l'accesseur d'Info est opérationel (càd que lorsque l'on clique sur le bouton associé, le lecteur Info s'ouvre à la bonne page).

drkm-elisp-doc
**************

drkm-errors
***********

drkm-face
*********

drkm-file
*********

drkm-font-lock
**************

drkm-fstyle-drkm
****************

drkm-ical
*********

drkm-key
********

drkm-log
********

drkm-occur
**********

drkm-test
*********

drkm-time
*********

drkm-vcard
**********

drkm-vcard-mode
***************

drkm-version-is
***************