On Tue, Jun 9, 2009 at 6:50 PM, Tobias C. Rittweiler
Juan Jose Garcia-Ripoll wrote:Examples? People may have to adapt SWANK:*READTABLE-ALIST*, or
> I was also made aware that using form number is not really useful when
> the code changes the readtable or use #+ or #-. Indeed, this is the
> case in a couple of libraries and should be a major problem debugging
alternatively use named-readtables at
Are the new changes on the debugger and inspector documented? What can
> Things are as follows. First, Slime will have to be upgraded to
> understand the environment produced by C functions (basically it
> involves calling si::decode-ihs-env)
be used to discriminate the current version from what was there before?
In my experience, form numbers work better than file positions because
> Second, ECL is being changed to record not the form number, but the
> precise file position at which the form was read. Please understand
> that this is a complicated change -- we might not get it right the
> first time -- since it involves detecting forms that are ignorable
> (#+/- conditionals, comments, etc).
there's somewhat less chance that they turn wrong on interactive
modification of the files.
Notice, now that you're working on it, that Slime can first go to a
tentative position (computed from form number, or given by file/line
position), and then search for a given snippet in a short region around
that position. The snippet comes from the Lisp implementation, e.g. the
first, say, 128 characters of a toplevel form.
Notice further, that Slime can cope with form paths. A form path is the
path into the tree that the source of a toplevel form represents. This
way, you can get various highlighting of the actual offending subforms
rather than the whole toplevel form.