以python为例
展示文档的意义不是很大
从doc中提取代码应该更有意义
将代码放到一个临时的buffer 可以执行 查看结果 扩展里面的函数（将代码插入当前buffer）
最后将代码回写到doc中
可以不改变原来的代码 用个简单的sqlite也可以
每个人用到的情况不同。。
本掉包侠表示展示doc的意义对我来说很大。。尤其是能针对性的显示argument documentation的。。至于文档中的代码。。我用到的package 的doc里有代码的就没多少，能直接放进source buffer里用的就更少了。。
虽然可以随时调出dash来看文档 但是终究不够specific
之前看到过不知道是IDEA还是什么的操作视频, 选中一段代码之后, refactor菜单里可以将这段代码转换为一个函数, 同时选中部分被自动替换为函数调用. 当然跟具体代码有关.
代码的智能化编辑是一个发展方向.
主要是要基于抽象语法树来做这些基础设施, Emacs底层是正则表达式, 这种东西在复杂场景一定都不靠谱.
如果一个文件里出现次数很多, 比如500个以上, 文件名分开就不方便了, 容易迷失, 不知道当前在哪个文件. 还需要一个outline窗口
可以使用ag.el, 搜索文件, 然后生成一个类似occur的buffer, 在里面开启wgrep, 就可以同样的操作了, 一直在用.
ag.el: GitHub - Wilfred/ag.el: An Emacs frontend to The Silver Searcher wgrep: GitHub - mhayashi1120/Emacs-wgrep: Writable grep buffer and apply the changes to files
跟你说的操作方式很类似, 不过这两个有人维护.
都是可以点击或者enter跳转的，这个问题倒是不大，而且一般candidates出现500多个，这个搜索本身就不太readable，需要优化下搜索的内容了。
如果像ide这样能exclude candidates by directory/module那倒说不能还readable一点，但我觉得还是优化搜索内容吧。
确实我也在用ivy-occur，提了个issue，问问看有没有类似的formatter function，貌似现在没有。
这个图也相当于个outline，没有这个东西容易迷失，不说500个，只要把屏幕占满（50个），看上去就不太舒服了。而且没有outline的统计数据，也不好优化搜索内容
还是以python为例
python代码的company-lsp本身就已经得到了关于补全的文档
而lsp-ui-doc又会重新调用以得到文档，速度就会慢了些
应该用text-propery将文档保存，这样不仅能查看文档，还能得到参数的信息
甚至还有Example
一会儿发个图片上来
1 个赞
只是实现了第一步 ：
用text-property保存文档
接下来是第二步：
得到参数（会有点困难，因为你可能会修改参数的内容，但要求同样能得到文档）
1 个赞
感觉anaconda mode里应该有些function可以拿来parse参数
应该用markdown
今天晚了 明天就能实现了
你的文档去哪里了
算是好了吧
1 个赞
很六！求代码😂
我都是直接修改el文件
这个要配合 yasnippet 来玩, 把 lsp 返回的函数定义参数用 yasnippet 动态生成.
现在在写 demo。
1 个赞
配色有点丑陋．．．