emacs-devel
[Top][All Lists]
Advanced

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

Re: tags for functions


From: Stefan Monnier
Subject: Re: tags for functions
Date: Thu, 29 Jan 2009 16:52:04 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux)

SM> Stefan "who still doesn't know what data we're talking about"
>>> I'm interested in "@keyword" substrings of the docstring that indicate
>>> the keywords for a particular function.  The goals are to:
>>> - list all keywords
>>> - list all keywords for a function
>>> - list all functions for a keyword

SM> Not know what that data would be used for, it's hard to give you
SM> good feedback.
> The goal is to do the three operations above as an API.

This is not "what it's used for", it's "how it's provided".

> Then Emacs will use it, for example, to show related functions in C-h f
> The package can also provide browsing by keyword, as finder.el does.

I see, thanks.  The list of related functions can be rather long, so
it's probably better to only add a "show related" button in C-h f and
only show the list when the user asks for it.

> 1) modify defun-after-hook so new defun calls will be noted, or install
> advice on defun (I'd rather do the former)

I'd rather to try to avoid both.

> 2) scan existing docstrings over mapatoms using `documentation' (it's
> slow now apparently, so it will need to be optimized for a batch scan)

If it's only done "once per session" and only when the user specifically
asks for this info, it's probably not that bad.

> I only need defun-after-hook to be approved, I can do the rest.  Do you
> agree it's useful or would you rather not provide such a hook?

I'm not convinced.  I'm not even sure this kind of info will turn out to
be useful/usable.  Currently, you'd spend all your time scanning
docstrings that don't contain any such keywords.  Adding those keywords
to docstrings would be a major undertaking.  So it's probably better to
start with data from elsewhere (e.g. from the elisp manual) anyway.

In other words, maybe a defun-after-hook ill be the right tool, but
we're pretty far from being in a position to judge, and it seems likely
that the end design will use a completely different approach anyway.


        Stefan




reply via email to

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