Deeson
21
比如在包 doom-modeline 中，函数 doom-modeline-segment--matches 是通过下面这个宏定义的：
(doom-modeline-def-segment matches
"Docstring"
(let ((meta (concat (doom-modeline--macro-recording)
(doom-modeline--anzu)
(doom-modeline--phi-search)
(doom-modeline--evil-substitute)
(doom-modeline--iedit)
(doom-modeline--symbol-overlay)
(doom-modeline--multiple-cursors))))
(or (and (not (string-empty-p meta)) meta)
(doom-modeline--buffer-size))))
我的 patch 代码没有什么特别，比如，就使用：
(psearch-patch doom-modeline-segment--matches
(psearch-replace '`meta
'`meta_))
但最终的结果是：并没有重新定义 doom-modeline-segment--matches 这个函数，而是定义了一个新的函数 doom-modeline-segment--doom-modeline-segment--matches，而这，就是问题所在。
我明白了。
问题虽然已经明了，但是解决起来有点麻烦。
普通函数和 doom-modeline-def-segment 生成的函数是不一样的：
(psearch-patch--find-function 'doom-modeline-segment--foobar)
;; => (doom-modeline-def-segment foobar "Docstring" body...)
;; | | | |
;; | | | `--- [3]函数体
;; | | `------------ [2]文档
;; | `---------------------- [1]函数名
;; `------------------------------------ [0]声明符
(psearch-patch--find-function 'foobar)
;; => (defun foobar nil "Docstring" body...)
;; | | | | |
;; | | | | `--- [4]函数体
;; | | | `------------ [3]文档
;; | | `-------------------- [2]参数表
;; | `-------------------------- [1]函数名
;; `-------------------------------- [0]声明符
从以上对比可以看出，doom-modeline-def-segment 定义函数是没有参数列表的，所以它的 Docstring 位置和 defun 定义的函数不一样：
而且这个不一样还是 doom-modeline-def-segment 独有的， 换个其它 xxx-def-yyy 有可能就不一样了。有的可能需要参数列表，有的可能不需要 Docstring。这就导致其生成的结构无法预料。
需要有一种方法，可以让用户指定如何解析 def 生成的结构，这无疑会给用户增加负担。还要考虑到不改变 psearch-patch 的声明格式，不影响旧的 patch 代码，或许可以在外层套个 let:
(let ((psearch-patch-symbol-definition-pospec
'((symbol-name . 1)
(docstring . 2))))
(psearch-patch doom-modeline-segment--matches
(psearch-replace '`meta
'`meta_)))
让我再想一想，有可能指定一个 (let ((psarch-patch-docpos 2)) ...) 就够了。
1 个赞
Deeson
23
真是很漂亮、精确和简洁的解释！没有认真读过前辈的代码，但是通过这个回答，学到了不少！
再次感谢这个很实用的工具！
同时，我有两个不太相关的小问题：
- 这部分的注释，是怎么排版成这种“图形化”的纯字符呢？有什么小工具吗？
- 我之所以会尝试使用如下“看似没用”的代码：
是因为，我 patch 了 doom-modeline--multiple-cursors 这个函数（它是用 defsubst 定义的），并且被 doom-modeline-segment--matches 调用。
但是仅仅做这个 patch 没有效果（是因为内联？还是 Doom Emacs 的黑魔法？），并且我发现，只要我重新求值一下 doom-modeline-segment--matches 的定义，就有效果了。（并且先 patch 和先重新求值皆可）
这才有了我上面这个“看似没用”的代码。但最终我是通过这个代码来强制重新求值的：
(eval (psearch-patch--find-function 'doom-modeline-segment--matches))
所以，前辈有遇到类似的情况吗？有相关原因和更漂亮的解决方案吗？
手打，没工具。
内联。
最新版本 Add support for macro-generated function · twlz0ne/psearch.el@b027a9d · GitHub 应该可以支持 doom-modeline-segment 函数了，用法：
(let ((psearch-patch-function-definition-docpos 2))
(psearch-patch doom-modeline-segment--matches
(psearch-replace '`MATCH-PATTERN
'`REPLACEMENT)))
1 个赞
Deeson
26
我尝试这个版本发现，可以 patch defun 定义的函数，但是无法 patch defsubst 定义的函数呢（该提交之前，patch 功能是正常的）。
所以是不是把 defsubst 考虑进去比较好：
@@ -797,7 +797,7 @@
`(let ((func-def (psearch-patch--find-function ',orig-func-spec)))
(with-temp-buffer
;; Modifiy function name
- (when (and (eq 'defun (nth 0 func-def)) (not (eq ',name (nth 1 func-def))))
+ (when (and (memq (nth 0 func-def) '(defun defsubst)) (not (eq ',name (nth 1 func-def))))
(setcdr func-def (cons ',name (nthcdr 2 func-def))))
(print func-def (current-buffer))
;; Modify docstring.
@@ -805,7 +805,7 @@
(down-list)
(forward-sexp
(+ ,docpos (if (equal 'lambda (sexp-at-point)) 0
- (if (memq (sexp-at-point) '(defun cl-defgeneric cl-defmethod)) 1
+ (if (memq (sexp-at-point) '(defun defsubst cl-defgeneric cl-defmethod)) 1
0))))
(let ((str "[PATCHED]"))
(goto-char (car (bounds-of-thing-at-point 'sexp)))
LdBeth
27
defubst 本身就算改了定义也没法反映到已经编译的函数里，没啥做的意义
Deeson
28
是这样的，但是有时候确实需要改动一些内联函数，所以我会把某些受影响的函数重新求值一下（假设 FUN 调用了某个被 patch 的内联函数）：
(eval (psearch-patch--find-function 'FUN))
能否提一个pr？同时记得修改一下头注释把你的名字加上去：
;; Last-Updated: <当下的时间戳>
;; By: <你的名字>
Deeson
32
我发现使用 psearch-patch 之后，就无法再用 elisp-def 定位到函数之前的位置了。
所以我对 psearch-patch-define 做了一些修改：在重新评估 patch 之后的函数体前，先设置好之前的路径。这样 patch 之后，也能找到函数的位置。
（带来的另外一个好处是，可以一边修改 psearch-replace 的内容，一边反复执行 psearch-patch，这在之前直不行的，因为运行一次 psearch-patch，就找不到函数的位置了，也就拿不到原来的定义了）
@@ -817,7 +817,8 @@ See `psearch-patch' for explanation on arguments ORIG-FUNC-SPEC and PATCH-FORM."
;; Apply patch
(goto-char (point-min))
(if (progn ,@patch-form)
- (eval-region (point-min) (point-max))
+ (let ((buffer-file-name (file-name-sans-extension (cdr (find-function-library ',name 'lisp-only t)))))
+ (eval-region (point-min) (point-max)))
(signal 'psearch-patch-failed
(list ',orig-func-spec "PATCH-FORM not applied")))))))
请前辈看看有没有什么问题和建议？
Deeson
34
嗯嗯好的！我确实没有经过广泛的测试，目前我的几个使用场景倒是没出啥问题。
Deeson
35
我自己尝试测试了一下 psearch-test 里面的代码，发现即使不引入我的修改，似乎也有测试不通过的例子？（在 psearch-test-cl-function-patch-1 aborted），是我打开方式不对吗？ 
- 用 run-test.sh 脚本测试。
- 我做了一些改动，把错误消除了，你可以用它提一个 pr，记得改一下
Last-Updated: 时间并签上你的名字：
diff --git a/psearch.el b/psearch.el
index b77f659..6bbc683 100644
--- a/psearch.el
+++ b/psearch.el
@@ -817,7 +817,11 @@ See `psearch-patch' for explanation on arguments ORIG-FUNC-SPEC and PATCH-FORM."
;; Apply patch
(goto-char (point-min))
(if (progn ,@patch-form)
- (eval-region (point-min) (point-max))
+ (let* ((lib (cdr (condition-case nil
+ (find-function-library ',name 'lisp-only t)
+ (void-function nil))))
+ (buffer-file-name (if lib (file-name-sans-extension lib))))
+ (eval-region (point-min) (point-max)))
(signal 'psearch-patch-failed
(list ',orig-func-spec "PATCH-FORM not applied")))))))
好的，我刚刚创建了一个 PR，请前辈看看，有问题只管修改就行。
有时候，patch 的函数在源文件中，并不是顶格的 
：
比如 Doom Emacs 中就有很多的 hack 是这种形式：
这个 doom-use-helpful-a 就不是顶格的。
如果我想通过 psearch-patch 对上面的函数进行 hack，就会报错：
原因是因为：psearch-patch--xref-function-def 这个函数只能定位到「函数定义位置的行首」（上图光标所在位置），这个时候 (bounds-of-thing-at-point 'sexp) 就会返回 nil，从而报错。
因此，建议：
diff --git a/psearch.el b/psearch.el
index 316c8b7..118d74c 100644
--- a/psearch.el
+++ b/psearch.el
@@ -683,6 +683,7 @@ Examples:
(`(,buf . ,pos) (find-function-search-for-symbol fun type file)))
(with-current-buffer buf
(goto-char pos)
+ (skip-chars-forward " \t")
(let ((bounds (bounds-of-thing-at-point 'sexp)))
(read (buffer-substring-no-properties (car bounds) (cdr bounds)))))))
这样就可以跳过行首的空白字符。
请前辈看看，有问题没？
