Hi, Neil Jerram <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Ludovic Courtès) writes: > >> * Completion >> >> Currently, `gds-complete-symbol' only completes symbols based on those >> defined in the current module of the attached Guile process. This is >> fine, but it would be nice if a completion function compatible with >> `hippie-expand' was provided, so that one can plug it in the middle of >> other completion functions. > > I don't yet know what this means in detail, because I've never looked > at how hippie works. I'll take a look soonish, but if you happened to > work it out for me first I shouldn't mind! I'm not an Emacs expert, so I'm afraid I won't be able to provide you with the exact patch needed to make it work. ;-) `hippie-expand' works by calling the functions listed in `hippie-expand-try-functions-list' which is documented as follows: The list of expansion functions tried in order by `hippie-expand'. To change the behavior of `hippie-expand', remove, change the order of, or insert functions in this list. These should be one-argument functions that are passed a previous completion result. Hippie provides a number of such functions out of the box: `try-complete-file-name', `try-complete-lisp-symbol', etc. Unfortunately, from a quick look at `hippie-exp.el', it seems that these functions pass their result by mutating `he-expand-list' which is not exported. Thus, in order to implement hippie-compatible completion functions, either hippie-expand has to be adapted, or your own completion function has to be made part of hippie-expand (which it not possible in your case). :-( >> * Module Unloading/Reloading >> >> When one is writing code and periodically testing it via GDS, it may >> sometimes be useful to tell GDS to entirely unload/reload a given >> module. This would be particularly helpful when testing features that >> span several modules. I don't know exactly what would be feasible in >> this area, and this would certainly require support from Guile itself. >> >> Also, I don't know what other Scheme/Lisp development environments allow >> for in this respect. Does that sound like a useful usage pattern? > > I completely agree as regards reloading, and I'm sure from my own > experience that it is a frequently useful usage pattern. > > The implementation is just "load the relevant file", I believe; the > only slightly tricky part is working out the most convenient possible > interface. > > I'm not sure about unloading. I don't recall ever wanting to do it in > practice, and I'm not sure Guile has any way of achieving it. Unloading would allow the modules' name spaces to be cleaned up before one reloads it, thus potentially avoiding mysterious side-effects. I believe module unloading could be achieved either by restarting a Guile process or by "undefining" the module that is to be reloaded before reloading it: (nested-remove! the-root-module '(%app modules foo bar)) However, the name space of the module users would need to be updated as well. One possibility would be to keep a list of all existing modules (this can be done by "overloading" `make-module'). Another one would be to include as an object property of each module object the list of its users (perhaps by overloading `module-use!'). Upon reloading of a module, the `module-uses' list of its users would be traversed in order to remove the relevant interface and replace it with a new one obtained via `resolve-interface' (note: you need to know the options that must be provided to `resolve-interface' here). In either case, you'd then have to play with the innards of the module system which can be quite tricky. I played a bit in the REPL with the above and was unable to reload a module after I had removed it... I'm afraid these thoughts won't be very helpful. ;-) Thanks, Ludovic. _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel
