mirrors/zsh
1
0
Fork 0
mirror of git://git.code.sf.net/p/zsh/code synced 2025-01-30 02:52:12 +01:00
Code Releases Activity

Delete duplicated text in development guide.

Browse source
This commit is contained in:
Bart Schaefer 2001-04-14 16:34:14 +00:00
parent d7417bdc0e
commit 7286f7bc37
2 changed files with 7 additions and 74 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
ChangeLog
View file

@ -1,3 +1,8 @@
2001-04-14 Bart Schaefer <schaefer@zsh.org>
* unposted: Etc/zsh-development-guide: The entire section on hook
functions was repeated twice; delete one copy.
2001-04-13 Oliver Kiddle <opk@zsh.org>
* 13982: Completion/Base/Utility/_multi_parts,

76
Etc/zsh-development-guide
View file

@ -630,80 +630,6 @@ that are changed or called very often. These functions,
structure defining the hook instead of the name and otherwise behave
like their counterparts.
Modules can also define function hooks. Other modules can then add
functions to these hooks to make the first module call these functions
instead of the default.
Again, an array is used to define hooks:
static struct hookdef foohooks[] = {
HOOKDEF("foo", foofunc, 0),
};
The first argument of the macro is the name of the hook. This name
is used whenever the hook is used. The second argument is the default
function for the hook or NULL if no default function exists. The
last argument is used to define flags for the hook. Currently only one
such flag is defined: `HOOKF_ALL'. If this flag is given and more than
one function was added to the hook, all functions will be called
(including the default function). Otherwise only the last function
added will be called.
The functions that can be used as default functions or that can be
added to a hook have to be defined like:
/**/
static int
foofunc(Hookdef h, void *data)
{
...
}
The first argument is a pointer to the struct defining the hook. The
second argument is an arbitrary pointer that is given to the function
used to invoke hooks (see below).
The functions to register and de-register hooks look like those for
the other things that can be defined by modules:
/**/
int
boot_foo(Module m)
{
int ret;
ret = addhookdefs(m->nam, foohooks, sizeof(foohooks)/sizeof(*foohooks))
...
}
...
/**/
int
cleanup_foo(Module m)
{
deletehookdefs(m->nam, foohooks, sizeof(foohooks)/sizeof(*foohooks));
...
}
Modules that define hooks can invoke the function(s) registered for
them by calling the function `runhook(name, data)'. The first argument
is the name of the hook and the second one is the pointer given to the
hook functions as their second argument. Hooks that have the `HOOKF_ALL'
flag call all function defined for them until one returns non-zero.
The return value of `runhook()' is the return value of the last hook
function called or zero if none was called.
To add a function to a hook, the function `addhookfunc(name, func)' is
called with the name of the hook and a hook function as arguments.
Deleting them is done by calling `deletehookfunc(name, func)' with the
same arguments as for the corresponding call to `addhookfunc()'.
Alternative forms of the last three function are provided for hooks
that are changed or called very often. These functions,
`runhookdef(def, data)', `addhookdeffunc(def, func)', and
`deletehookdeffunc(def, func)' get a pointer to the `hookdef'
structure defining the hook instead of the name and otherwise behave
like their counterparts.
Finally, modules can define wrapper functions. These functions are
called whenever a shell function is to be executed.
@ -731,6 +657,7 @@ The first two arguments should only be used to pass them to
is the name of the function to be executed. The arguments passed to
the function can be accessed vie the global variable `pparams' (a
NULL-terminated array of strings).
The return value of the wrapper function should be zero if it calls
`runshfunc()' itself and non-zero otherwise. This can be used for
wrapper functions that only need to run under certain conditions or
@ -778,6 +705,7 @@ de-registered. But if there is some module-global state that has to be
finalized (e.g. some memory that has to be freed) and that is used by
the wrapper functions finalizing this data in the cleanup function
won't work.
This is why there are two functions each for the initialization and
finalization of modules. The `boot'- and `cleanup'-functions are run
whenever the user calls `zmodload' or `zmodload -u' and should only