[slime-devel] Re: Improvement request to M-.

[Helmut Eller]

Chris Capel <pdf23ds at gmail.com> writes:

> Interestingly enough--and this isn't a condemnation of SLIME in any
> way--Visual Studio.NET has full capabilities to look up the source location
> of any variable or definition in the current project. This seems to be
> implemented completely in the editor, which means that it has to be able to
> parse C#. Funny.

Parsing the source code with something other than the compiler doesn't
work so well with Lisp, or for that matter, any language that has
extensible syntax.  If a macro expands to a defun, then parsing the
source isn't enough.  You also have to expand the macro.  There are
also issues with packages and reader-macros.  

If you are satisfied with the simple cases, i.e., if the source code
actually looks like "(def.* foo", then you can use TAGS files.

> In the vein of copying from VS.NET, I think a neat thing that might be
> relatively easy to implement is to highlight unmatched parentheses in a
> form, using as a context the area between the top-level text closest before
> the point ("(defun" or "(defmacro") and the top-level text after the point.
> This way it's easy to tell when you need more parentheses somewhere. Or
> maybe it could be even closer to where the actual parenthesis is needed, by
> comparing the ideal indentation (as per lisp-indent-line) to the current
> indentation of the lines.
>
> I suppose this would be a rather ambitious project, and of dubious value.
> But definitely neat.

Emacs already shows text around the opening paren when you type
')'. So it't not that hard to know when the expression has enough ))).
Some people also add 'check-paren to their local-write-file-hooks.

Helmut.