emacs-devel
[Top][All Lists]
Advanced

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

Re: master e6591b549f3: New symbol property 'definition-type' used by 'f


From: Eshel Yaron
Subject: Re: master e6591b549f3: New symbol property 'definition-type' used by 'find-function'.
Date: Mon, 13 Jan 2025 16:27:36 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Eshel Yaron <me@eshelyaron.com> writes:

> Hi there,
>
> Stephen Gildea <stepheng+savannah@gildea.com> writes:
>
>> branch: master
>> commit e6591b549f35af1be31f5bf3547e1170b7604a99
>> Author: Stephen Gildea <stepheng+emacs@gildea.com>
>> Commit: Stephen Gildea <stepheng+emacs@gildea.com>
>>
>>     New symbol property 'definition-type' used by 'find-function'.
>>     
>>     * lisp/emacs-lisp/find-func.el (find-function-search-for-symbol):
>>     Look for new property 'definition-type' on the symbol.
>
> [...]
>
>> +  (setq type (or (get symbol 'definition-type)
>> +                 type))
>
> Thanks for working on this!  While I understand the motivation for this
> feature, ISTM that the design/implementation is not completely coherent:
> a symbol in ELisp can name multiple things of different types, the same
> symbol can have definitions as a function, variable, face, feature, etc.
> It doesn't make sense to talk about "the definition type" of a symbol,
> because it can have multiple types.
>
> The implementation makes this issue clear:
> find-function-search-for-symbol now just ignores the TYPE argument for
> symbols with a specified definition-type property.  So if we want to
> find the definition of foo as a face, but someone happened to give foo a
> definition-type of, say, a feature, then we're out of luck: we'll get
> the wrong results from find-function-search-for-symbol, and we might not
> even know it, since it silently ignores the requested TYPE.  Right?
>
> So, unless I'm missing something, instead of a "definition-type", I'd
> suggest to give such symbols that need special handling a
> symbol-specific association between types and methods for finding
> definitions as a symbol property.  So the value of the property would
> look like find-function-regexp-alist, just specific to the given symbol,
> overriding the "default" associations of find-function-regexp-alist.

Here's the kind of modification I had in mind, concretely:

diff --git a/lisp/emacs-lisp/find-func.el b/lisp/emacs-lisp/find-func.el
index 643b6aba2a6..f34fe1cec90 100644
--- a/lisp/emacs-lisp/find-func.el
+++ b/lisp/emacs-lisp/find-func.el
@@ -413,8 +413,6 @@ find-function-search-for-symbol
   ;; that defines something else.
   (while (and (symbolp symbol) (get symbol 'definition-name))
     (setq symbol (get symbol 'definition-name)))
-  (setq type (or (get symbol 'definition-type)
-                 type))
   (if (string-match "\\`src/\\(.*\\.\\(c\\|m\\)\\)\\'" library)
       (find-function-C-source symbol (match-string 1 library) type)
     (when (string-match "\\.el\\(c\\)\\'" library)
@@ -424,7 +422,9 @@ find-function-search-for-symbol
     (when (string-match "\\.emacs\\(.el\\)\\'" library)
       (setq library (substring library 0 (match-beginning 1))))
     (let* ((filename (find-library-name library))
-          (regexp-symbol (cdr (assq type find-function-regexp-alist))))
+          (regexp-symbol
+            (alist-get type (append (get symbol 'find-definition-alist)
+                                    find-function-regexp-alist))))
       (with-current-buffer (find-file-noselect filename)
        (let ((regexp (if (functionp regexp-symbol) regexp-symbol
                         (format (symbol-value regexp-symbol)



Then a macro that defines ERT tests and wants to teach find-func how to
find them would say something like:

--8<---------------cut here---------------start------------->8---
(setf (alist-get 'ert-deftest (get 'my-test-name 'find-definition-alist))
      'my-test-finding-regexp)
--8<---------------cut here---------------end--------------->8---

That way, find-func would still find the right location of a function or
a variable with the same name.



reply via email to

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