jed-extra

[Paul Boekholt]

On Thu, 24 Nov 2005 12:53:12 +0100, "G. Milde" <g.milde at web.de> said:

> > > I think we should ask for consens, whether jed-extra initialization should
> > > contain autoloads for 
> > >    * user-callable functions only 
> > >       + low memory footprint and fast startup
> > >    * all functions that shall be usable from outside the defining script
> > >       + simpler use of "non-standard library functions" in scripts
> > >         (no explicit autoloads needed)
> > >       + better advertisement: functions can be found via Help>Apropos

> > For the libraries, I'd say just autoload every function.  

> We could consider using Make_ini_Scope == 2 to create autoloads for all
> non-private functions. This would produce some non-needed autoloads but as
> the coast of an autoload is not too large, this might be tolerable. The
> worst "offenders" could either be excluded from auto-scanning in
> Make_ini_Exclusion_List or fitted with an <INITIALIZATION> block.

> However, we have to consider the add_completion()-s as well. The number of
> possible completions is limited and although the limit is raised nowadays
> it could become an issue. Also, it is not very helpfull if there are
> many completions that possibly do not work with M-x.

> This is why I modified make_ini to allow setting the scope for autoload-
> and add_completion-generation independently. Now it is possible to have e.g.
> autoloads for all (non-hidden) global definitions and add_completion for
> explicitely public ones only.

> This results in an ini.sl of 711 lines for jed-extra. 

That's rather a lot.  My problem was with the 89 or so functions in
*utils.sl, solving that shouldn't blow up ini.sl to 711 lines.

> If this seems too large (for me it does), this would mean to do
> special run of make_ini on the "libraries" (in my categorization in
> jed-extra/debian/contents.txt they are called "utils") The easiest way would
> be to sort them in a separate directory (we are sorting anyway, so this is a
> small change).
This is how I manage these files myself (in the utils/ directory).

> > For other scripts, unless there is an <INITIALIZATION> section, I doubt
> > if any automated scanning can identify which functions should have an
> > autoload.  Jed-extra could include scripts from e.g. Dino or Klaus Schmid
> > who may use different styles, so I think the possibilities of automating the
> > build by scanning the sources are limited.

> I would go for an pragmatic approach here. 

> * As long as there are no scripts that pose problems, use the auto-generation.

> * If problems arise:
>    * try to convince the upstream author to adapt the mode,
>    * put the mode on the Make_ini_Exclusion_List and initialize in
>      50jed-extra.sl, or
>    * provide a dpatch  

> I know there are some things that cannot be solved automatically, especially
> as ini.sl is not a config file.  E.g. both apsmode and print.sl provide a
> function print_buffer(). The autoload should therefore be in 50jed-extra.sl. 

> > More urgently, do the jed-extra scripts work as the package is now, or
> > are you getting lots of undefined function errors?  

> I did not test. Only some "road-testing" of my own modes.

> > I've tried to locate the functions that probably require an autoload outside
> > the mode they are used in:

> > public define close_buffer() % (buf = whatbuf())
> > public define menu_checkbox() % menu, name, var, fun1, [fun2]

> No problem with explicitely public definitions. (Although the last version of
> my modes have some of them changed.)

> > define run_blocal_hook() % (hook, [args])
> > define window_set_rows(rows)
> > define rebind() % (old_fun, new_fun, keymap=what_keymap(), key_prefix="")

> There are currently no autoloads for these. Providing autoloads for all
> global funs in the "utils" will solve this.
That would solve my problem.

> > static define menu_do_toggle(var)
> > static define menu_do_radio();
> > static define menu_make_radio(menu, var, names, values, fun)
> > static define menu_do_radio(a)

> I do not think it is a good idea to provide autoloads to static functions
> (and I do not know whether this is possible at all).
Actually these lines shouldn't be in the output - they are there because
menutils/menutils.sl matches both patterns (the filename matches *utils/*.sl,
and the file matches Id.*paul), so it was compared with itself.