p.boekholt at hetnet.nl
Thu Nov 24 12:18:07 UTC 2005
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.
More information about the Pkg-jed-devel