auto_mkindex is one of several commands documented at http://www.purl.org/tcl/home/man/tcl8.4/TclCmd/library.htm ---- [MSW] 2003-09-03: What does auto_mkindex buy us over auto_mkindex_old (which I prefer), given that auto_mkindex_old has a clear rule how to exclude procs from loading, and auto_mkindex doesn't ? Imagine e.g. you have a library of tcl stuff, with different (Gui or not) frontends all having a common init procedure which they cannot auto_load (yet) because they did not setup load pathes (auto_path). Now if you e.g. start in a non-gui case, calling an init function (let's call it xxx_init) which you put in an init.tcl, it's absolutely random which file ends up being loaded (or the last alphabetically sorted), which often is not the right thing - that last file could be using xxx_init to set up things, but when it's sourced could call it with some parameters which apply for the GUI case only. Checking against the argv0 won't help, as this same thing can also be in a subwindow / own toplevel when started from another (GUI) script in the bundle... So if someone has some insight to share on what the new auto_mkindex really buys us, I'm curious. ---- [RS] 2003-09-03: auto_mkindex_old does not exclude procs from loading - only they are not indexed. If the file is sourced because of another proc, all the ;procs will be loaded too. But with unique names ([namespace]s), conflicts should not occur. Also consider the [package] mechanism for more modular (and versioned) code management. ---- [MSW] 2003-09-03: Uh, sorry. I meant not being indexed. Yet not being indexed means you know which file will be loaded. Of course I can add a plethora of bookhandling code, too. And until package require doesn't accept anything as arg, it's pretty useless for variable behaviour, while you keep developing your packages. That was not the question either, I asked why abandon an easily controllable interface towards one where you either have to dig deeper, add more code or more complexity. file init-proc.tcl: ----- proc xxx_init {{do_this 0} {do_that 0} {do_gui 0}} { # do something shared # do something according to params } ----- file 1.tcl (executable, gui): > ; proc xxx_init ... > standalone usage: 1.tcl: xxx_init 1 0 1 > loaded: we need that init stuff, too ( as of the options ) file 2.tcl (executable, gui): > as 1.tcl file 3.tcl (executable, !gui): > ; proc xxx_init ... > standalone usage: 3.tcl: xxx_init file 4.tcl (executable, gui): > as 1.tcl 5 (statically compiled c program with tcl interpreter) > in Tcl_AppInit, call xxx_init. With new auto_mkindex > ran, 4.tcl will be loaded (has gui -> Bang!) > with old, init-proc.tcl will be loaded alternative to get old behaviour: source full/path/init-proc.tcl. rephrase alternative in other ways: '''abandon autoloading''' (in my case of course). uh huh. So that's what auto_mkindex(_new) buys me ? ---- [Tcl syntax help] - [Arts and crafts of Tcl-Tk programming] - [Category Command]O