[editor-hints-devel] Re: Initial message to create gmane.lisp.editors.hints.devel group.

Robert Goldman rpgoldman at sift.info
Fri Jan 18 16:05:44 UTC 2008


Tobias C. Rittweiler wrote:
[...]
> 
> Its current TODO list looks as follows:
> 
> 
> * Named readtables:
> 
>   Create a namespace for readtable analogously to that of packages.
> 
>   `(IN-READTABLE :FOO)' are supposed to be recognized by editors,
>   to properly deal with different readtables when evaluating stuff.

I'd suggest that the editors be able to handle readtable specifications
in the mode line, as well.  Indeed, since the mode line is the directive
to the editor, I'm inclined to think that the mode line should take
precedence....  But I certainly haven't thought deeply about this..
> 
> * Indentation:
> 
>   Add a facility to specify how symbols are supposed to be indented.
>   I.e. something like a DECLAIM-INDENTATION (being based upon a
>   PROCLAIM-INDENTATION function) which store indentation information
>   in some retrievable way. So that editors can rely on that
>   information from a running Lisp image.
> 
>   This requires some research about the indentation specification
>   schemes that different Lisp systems (Lisp machines, Symbolics'
>   Genera, GNU Emacs, Lispworks, AllegroCL) use. And then define
>   a practical denominator.

I don't believe that the Allegro CL environment actually has an
indentation specification scheme.  Allegro CL's environment, for me at
least, is just Emacs (but I don't use Allegro Composer).  So I think it
will be easy for us to just handle emacs.
>   
> * Documentation retrieval:
> 
>   Add the facility to support project-specific documentation
>   retrieval on a per symbol basis. 
> 
>   It's common that editors provide the possibility to quickly visit
>   the respective CLHS site for a symbol. But this doesn't work on
>   symbols not defined by ANSI.
> 
> * Pretty docstrings:
> 
>   Add support for using markup in docstrings.
> 
>   Also detach too elaborate docstrings from the actual
>   function/macro/&c definition.

I like the idea of Markdown, since it's a syntax engineered for text
readability and html-generation.  I wanted to use Gary King's
CL-markdown, but I wasn't willing to accept the chain of library
dependencies (not to criticize Gary in particular, it's just that I
don't ever use long chains of CL library dependencies).

Best,
R



More information about the editor-hints-devel mailing list