Hi, Eduardo Cavazos <[email protected]> writes:
> I got some basic and experimental support for symbol completion going. > > This is the latest 'r6rs-library-mode': > > http://proteus.freeshell.org/_suede-a/elisp/r6rs-library-mode.el > > This is a hacked version of Alex Shinn's 'scheme-complete': > > http://proteus.freeshell.org/_suede-a/elisp/scheme-complete-0.8.7.0.el > > Note; I'm *not* hardcoding any (additional) symbols; I dynamically > query the repl for the symbols available in the library that's > currently being edited. Of course, there needs to be some support for > this on the Scheme side of things. This sort of interaction with an underlying Scheme process has been suggested before, but I specifically avoided that when designing scheme-complete. There are two major problems with it - one is that most Scheme implementations are unable to provide much information about the symbols a library exports, notably they lack doc strings and type information. Also, in addition to basic type info scheme-complete also provides extended completion functions for some symbols, such as completing host names for tcp-connect, or system user names for get-user-info, etc. The other problem is that scheme-complete is by definition meant to be used on code that's in-progress (otherwise you wouldn't be editing it). So you may have several related modules in the same directory, and if you edit one, changes there should be reflected in completion info for the others. An underlying Scheme process may not know to look for modules in the current directory as opposed to a central repository, and even if it does it may not be able to compile or obtain type information from the partially complete files. scheme-complete is specifically forgiving of errors and tries to make as much sense as possible of incomplete Scheme code. -- Alex
