I released the previous version of this package as version 3.11.
At that time I was mangling with the cvs directory of my elisp
libraries. Now I've settled with a new versioning scheme, and the new
version is 1.6. Sorry for the confusion that might be incurred.
;;; Change Log:
;; Version 1.6 (7 Sep 2004)
;; * Add CLHS glossary entries, e.g. "{lisp image}".
;;; Commentary:
;; You can look up symbols specified in CLHS (Common Lisp HyperSpec)
;; with hyperspec.el from within Emacs. hyperspec-addon.el adds extra
;; entries to hyperspec.el.
;; The added entries are chapter names (e.g. "[object]"), format
;; control characters (e.g. "~C: Character"), reader macro characters
;; (e.g. "#+"), loop keywords (e.g. "loop:collect"), MOP symbols
;; (e.g. "class-direct-slots"), CLHS glossary entries
;; (e.g. "{lisp image}") and so on.
You can find the latest hyperspec-addon.el at
http://homepage1.nifty.com/bmonkey/emacs/elisp/hyperspec-addon.el
Yuji.
s/hyperspe-addon/hyperspec-addon/
Sorry.
Any ideas on other entries that can be crammed into are welcom.
From: Thomas Schilling
Subject: Re: hyperspec-addon.el 1.6 --- Add additional entries to CL HyperSpec lookup table
Date:
Message-ID: <opsdyrtceatrs3c0@news.CIS.DFN.DE>
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
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.
From: Roland Kaufmann
Subject: Re: hyperspec-addon.el 1.6 --- Add additional entries to CL HyperSpec lookup table
Date:
Message-ID: <tl2u0u2uv43.fsf@space.at>
Hello Yuji,
you might want to take a look at
Christopher Fry
Programming on an Already Full Brain
Communications of the ACN, April 1997, Vol. 40, No. 4, pp. 55-64
where the author describes enhancements to an Emacs-like editor to
support Common Lisp.
best regards
Roland
Hi, thanks for the cursor.
On Mon, 13 Sep 2004 16:00:28 +0200, Roland Kaufmann wrote:
>
> Hello Yuji,
> you might want to take a look at
> Christopher Fry
> Programming on an Already Full Brain
> Communications of the ACN, April 1997, Vol. 40, No. 4, pp. 55-64
> where the author describes enhancements to an Emacs-like editor to
> support Common Lisp.
>
> best regards
> Roland
I've dug out the following link with google.
http://web.media.mit.edu/~lieber/Lieberary/Softviz/CACM-Debugging/Already-Full/Already-Full.html
I haven't read it through yet, but it looks interesting.
An interesting thing is that I've already written a screen-based
interface for the Emacs menu system called tmenu.el
http://homepage1.nifty.com/bmonkey/emacs/elisp/tmenu.el
I might be able to reuse this package for symbol lookup system for
Common Lisp.
Yuji.
"Programming on an Already Full Brain" was a thought provoking read. I
wonder whether the current MCL carries this `Emacs Menu' with it.
I added a few entries to my to-do list.
* A database of various information on Common Lisp standard operators and
variables (e.g. explanatory parameter names, types of parameters, variables,
and functions, etc.)
Whether this should be written in Common Lisp or Emacs Lisp is arguable.
I'll probablly write it in Common Lisp to avoid getting tied up with
Emacs too much. Type declarations might be also used for compilers. I
think designing a good solid interface for queries is the most important
task.
* Customize dabbrev-expand (M-/) for Common Lisp.
+ (loop for a in list col<M-/>
should first expand into collect or collecting. This may need a loop
parser.
+ (make-hash-table :te<M-/> should expand into :test.
you can already do this with complete-lisp (ESC TAB) now but <M-/>
should do this, too. Adding a piece of advice to dabbrev-expand might
do the job.
Any comments are welcome.
Yuji.