Matthew Love <[email protected]> writes: > I think I may have found a solution, let me know what you all think of > this. > > Instead of defining the orignal variable as a defvar or as a null > function, it seems the best route is to define it as a fluid variable, > as that seems to be the best variable type for this kind of usage.
Hmmm.. I'm not sure I understand what work the fluids are doing here, since the values for the prompt-*-fun variables are still being set directly by the function that calls prompt, and since the variables are no longer special variables the calling function must be in the prompt module. Certainly this would break my own code that uses prompt. Fluids may ultimately be the right way to go, though. The prompt module was an uneasy fit with the module system to begin with since it used special variables to do so much of its work, exposing a great deal of its internals. And even so prompt-extras and prompt-wm were declared in-module (though I'm not entirely sure why); my guess from the code is that prompt was written pre-modules and put into a module later. The idea would be to have the entry point into the prompt system (i.e., the prompt function) accept fluids pointing to the proper values for all of the prompt-*-fun, as well as anything else necessary (e.g., prompt-history) and initialize all the local prompt-* variables appropriately. Then all the prompt-for-* functions would have to be rewritten to call prompt in the new way. -- Jeremy Hankins <[email protected]> PGP fingerprint: 748F 4D16 538E 75D6 8333 9E10 D212 B5ED 37D0 0A03
