Hi,
I think that symbol started out as `semantic-defoverload', which
eventually becamse define-overload. It was matching define-lex and
other features.
One of the reasons I liked `define-overload' over `defoverload' is
that it made it clear by the name that is was not a blessed Emacs
API like defun. I do agree with the problem you proclaim,
however. It is a pain.
One reason I never worried about it is because even if it could
find a `defSOMETHING', it would always go back to the original
definition, when what you are probably interested in is the
implementation. This would require some clever advice for the
find-function routing. Fortunately, the default implementation is
usually specified next to the overload function itself.
Perhaps senator should offer a `find-function' that works across
all languages, and Emacs Lisp could override some implementation do
do the right thing when defining an override. Oh my.
One thing I would like to see is an augmentation of help mode to
list out all functions that may overload a given semantic function.
(eieio adds a temp-buffer-show-hook for doing this with methods.)
Ok, enough sillyness. If everyone agrees, I don't mind
`defoverload'. I'd be a little more concerned about changing
`define-mode-overload-implementation' though. Removing -s would
make that hard to read. ;)
Eric
>>> ryk@... seems to think that:
>Hi Eric and David,
>
>I'm trying to spend time on semantic over the holidays.
>
>May I suggest using the term 'defoverload' rather than
>'define-overload'? The problem with 'define-overload' is that it has
>a '-' character which breaks emacs' built-in tools such as
>find-function-noselect. Let me illustrate what I mean by an example.
>
>Type `C-h f semantic-lex RET'.
>This shows the *Help* buffer.
>Now click on the "semantic-lex" link in the *Help* buffer.
>You get
>
> "Cannot find definition of `semantic-lex' in library `semantic-lex'
>
>error message which gets in the way of one trying to hack semantic
>code. If we used 'defoverload' instead of 'define-overload', then
>clicking on the same link takes one to the correct line within
>semantic-lex.el file.
>
>'find-function-noselect' is a built-in emacs function.
>Other elisp code has difficulty with 'define-overload'.
>For example Noah Friedman's fff-elisp.el package provides
>find-function-noselect like features. In that package, I find
>
>(defvar fff-emacs-lisp-def-regexp
> "^\\s-*(\\bdef\\w+\\s-+'?\\(%s\\)\\(\\s-\\|$\\)"
> "The regexp used to find symbol definitions in an emacs lisp source file.
>This regexp must contain a `%s' where the symbol name is to be inserted in
>the template.
>If \\\(\\\) registers are included in the regular expression so that \\1
>matches, point will be positioned at that match instead of \\0.")
>
>It seems like built-ins, functions, and macros that define other
>functions have historically had names such as defXXX where XXX seems
>to match certain regexp's that do not seem to include '-' stuck in the
>middle. You know most of them, e.g,. defun, defalias, defsubst,
>defmacro, defvar, defcustom, etc.
>
>I can't remember whether this time-honored naming tradition is
>actually documented somewhere. Clearly this naming tradition has
>affected existing elisp code. The fact that a simple renmaing of one
>macro removes a hurdle seems to be reason enough to abide by this
>naming tradition.
[ ... ]
--
Eric Ludlam: zappo@..., eric@...
Home: http://www.ludlam.net Siege: http://www.siege-engine.com
Emacs: http://cedet.sourceforge.net GNU: http://www.gnu.org
|