gnu-emacs-sources
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hyperspec-addon.el 1.6 --- Add additional entries to CL HyperSpec lo


From: Yuji Minejima
Subject: Re: hyperspec-addon.el 1.6 --- Add additional entries to CL HyperSpec lookup table
Date: Wed, 08 Sep 2004 09:26:38 +0900
User-agent: Pan/0.14.2.91 (As She Crawled Across the Table (Debian GNU/Linux))

On Tue, 07 Sep 2004 17:54:38 +0200, Thomas Schilling wrote:

> Yuji Minejima wrote:
> 
>> Any ideas on other entries that can be crammed into are welcom.
> 
> Not quite on-topic, but how about a shadowing defun, defmethod, ... to put 
> the docstrings into some text format (info, tex, html) and then have these 
> symbols available for quick lookup (maybe one could hack Albert a bit, 
> maybe it's already there, dunno).
> 
> Ok, (describe ...) may be a simple solution but I think more of static 
> (ie. external to the lisp image) documentation spiced up a little with 
> who-calls, who-binds, ect ... information (like eg. Albert generates 
> them). Though, a reasonable class-browser in Slime together with nicer 
> doc-string formatting (at least for allegro CL) might be more useful.
> 
> (But I'd do it myself--one day (it has quite low priority in my 
> todo-queue).)
> 
> -ts

Thanks for sharing ideas.  I didn't know Albert, thanks for the info, I'll
take a look at it.

I think your idea of combining static information with dynamic one is
interesting.

I feel hyperspec-addon.el is a quick and dirty hack and my plan for
its future is to go with this hacky design to see how far I can go adding
entries which I think is useful.  For example, symbols of another package
can be added as "ext:cd".

My another plan relating to documentation is to write an Emacs's eldoc
clone. Currently I'm wondering if I should prepare lists of explanatory
argument names of all the standard CL operators instead of asking an
implementation for the info because argument names obtained from clisp's
describe's output is a bit too terse (and that's the main reason I came up
with the idea of writing this package in the first place).

Regards,

Yuji.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]