This is the mail archive of the
mailing list for the Guile project.
Keisuke Nishida <email@example.com> writes:
> (foo bar)
> One may want to search for `foo' when one type C-h f and for `bar'
> when one type C-h v. So I guess we should define one function
> `scheme-describe-object' and two commands `scheme-describe-function'
> and `scheme-describe-variable'. How about that?
So the functions would default to different symbols when called
interactively, and would otherwise be identical? Hmm... I think
I'd prefer using the prefix argument to choose between them.
> Also I think it would be a good idea to generalize these help functions.
> We could define `mode-describe-function', which calls an appropriate
> describe function indirectly according to the current major-mode. If
> one type C-u M-x mode-describe-function, it asks the major-mode to search.
Oh. This seems all right. The completion list for major modes
should only show modes which have their own description
functions, so that short abbreviations (s, e) are unambiguous.
This should be extended to M-:, M-C-x and C-x C-e.
Still... currently, C-h f explains Emacs functions and C-h C-i
explains non-Emacs symbols based on the major mode. I think this
is a good separation and C-h f should not be used for e.g. C
functions. If the only Emacs languages are Lisp and Scheme, do
we need a language selection menu? It would be simpler to have
`describe-function' on C-h f and `scheme-describe' on C-h d.
Except that doesn't solve M-:.
> A major-mode can be defined as a class in terms of GOOPS. We could
> define the above functions as generic functions.
Would each buffer using the same major mode have its own instance
of the major-mode class?
I guess many buffer-local variables could be moved to slots of
major-mode objects. And overlays could force their own major
modes in buffer regions... umm... this would require storing
Scheme references in overlays, which we can't do yet.
> A method is each definition in a generic function, maybe?