背景
我正在寻找为 vim 构建生产力分析器,它可以为用户执行的特定重复任务默默地显示更有效的解决方案。提示可能会以咆哮、状态栏等方式显示。
别笑,这个想法来自 Clippy: http://en.wikipedia.org/wiki/Office_Assistant
当然,我不想构建另一个像 vigor 这样有趣的东西,我关心的是认真的效率分析,这对于 vim 新手来说特别有用。
问题
它有意义吗?是否有任何理论涵盖这种分析?
Background
I'm looking to build productivity analyzer for vim which could silently display more efficient solution for particular, repetitive task the user doing. The tip might be displayed in growl, status line, etc.
Don't laught, but the idea come from Clippy: http://en.wikipedia.org/wiki/Office_Assistant
Of course I don't want to build another funny stuff like vigor I'm about serious efficiency analizement which could be especially useful for vim newbies.
The question
Does it makes sense and is there any theory covering such analysis?
发布评论
评论(3)
我突然想到:
这需要大量的人工智能/模糊分类。很难分析用户“试图做什么”(通常用户不清楚并且会偏离主题:哦,当我在这里时修复该拼写错误;对齐该评论...好吧,现在开始另一个任务)
讽刺的是,我认为当以“Vim Pro”方式做事时,这会变得更容易(但是这样发现它就没有用了,因为它已经是最佳的了!)
此外,TIMTOWTDI;你不能只是说“这是最好的方法”。这取决于品味、手部位置、键盘布局、插件可用性等等。
我认为到目前为止,真正学习此类内容的最佳方法是
留下了怀疑,我可以看到一个插件的良好市场类似提示的功能:
我会想到“永远在线”的提示,就像你在俗气的国际象棋引擎中看到的那样(显示可到达的字段、被攻击的字段、风险、串、叉子以及可视化的交换组合的结果):
<、
> 等)。现在执行此操作的插件是 ShowMarks:在屏幕截图,请注意a
和b
的标记,还有(漂亮!){ 和 ( 和类似的文本动作(我刚刚看到了>
、.
等)1。:setrelativenumber
已经有助于让用户想到 < code>13j 而不是jjjjjjjjjjjjj
- 但请在此处查看我的偏好 通过快速搜索在字符之间移动点我可以看到语法突出显示插件发生在其中,封闭的文本对象(单词、单词、句子、段落或标识符、parenblock、braceblock)将以背景颜色的逐渐增加的阴影突出显示。如果我们想出一种方法来覆盖有用的提示(哪个键用于文本对象运动),您会得到非常好的提示,IMO。
我可以看到按“o”将光标移动到视觉选择的另一端的提示
标准 matchit 在提示匹配括号方面已经非常有用(尽管它并没有在实际的 Clippy 风格中暗示您可能使用
%
到达那里)的其他鼓舞人心的用途+signs
功能是: errormarker.vim (其中用途除了放置图形标志外,还提供气球提示);我可以看到它得到了很好的利用(如果只是为了指向某些文档主题)关于文本对象荧光笔,我怀疑它可能已经存在。我现在要看看
1 我认为要获得更多分数,我需要做 (?)
我还建议将更新时间设置为快速(例如,500 毫秒) )
Off the top of my head:
This would require a fair amount of AI/fuzzy classification. It is hard to analyze what the user is 'trying to do' (often the user is not clear and will get sidetracked: Oh, fix that typo while I'm here; align that comment... ok, now on with the other task)
Ironically, I think that when doing things the 'Vim Pro' way, this would get easier (but then it wouldn't useful to spot it because it is already optimal!)
Also, TIMTOWTDI; you can't just go and say 'here's the best way'. It depends on taste, handposition, keyboard layout, plugin availability whatnot.
I think by far the best way to actually learn things like this is by
Skepticism left behind, I can see a good market for a plugin with hint-like features:
I'd be thinking 'always-on' hints, much like you see in cheesy chess engines (showing reachable fields, attacked fields, risks, skewers, forks and a visualization of the outcome of an exchange combination):
<,
> and such). A plugin that does this now is ShowMarks: in the screenshot, note the marks fora
andb
, but also (nifty!) the locations for the { and ( and similar text motions (I've seen>
,.
and others just now). 1:set relativenumber
is already helpful in making users think of13j
instead ofjjjjjjjjjjjjj
- but see my preference here Moving the point between in charactors by quick searchI could see syntax highlighting plugin happen where enclosing textobjects (word, WORD, sentence, paragraph or identifier, parenblock, braceblock) would be highlighted in increasing shades of the background color. If we think of a way of overlaying a helpful hint (which key to use for the text object motion), you'd get very good hinting, IMO.
I could see a hint for pressing 'o' to move the cursor to the other end of a visual selection
the standard matchit is already quite instrumental in hinting about matching brackets (although it doesn't hint in actual clippy style that you might use
%
to get there)other inspiring uses of the
+signs
feature are: errormarker.vim (which uses balloon tips in addition to placing a graphical sign); I can see this being put to good use (if only to point at certain documentation topics)Regarding the text object highlighter, I suspect it might already exist. I'm going to have a look now
1 I think to get more marks, I needed to do (?)
I also recommend setting updatime to something quick (say, 500ms)
我觉得你的想法很有趣。如果语气正确,这样的功能可能会有所帮助,而不仅仅是对新手。
但我看到了很多困难:
Vjjjd
来删除 4 行,您建议使用V3jd
或4dd
或者可能dip 如果合适或其他解决方案?
不管怎样,这是个好主意。
I find your idea very interesting. With the right tone, such a feature would probably be helpful and not only for newbies.
But I see a bunch of difficulties:
Vjjjd
to delete 4 lines, do you proposeV3jd
or4dd
or maybedip
if suitable or whatever other solution?Whatever, this is a neat idea.
我个人的观点是,类似 Clippy 的工具很难操作。正如上面提到的,我认为最困难的部分是在编写文本时理解用户的意图。如果你把它放在一边,并有一个明确的方法来为你的意图添加语义,你的生活可能会变得容易得多!
因此,我想作为第一步,输入-输出-序列工作流程可以更容易测试并从中获取结果,而不是实时建议。
我正在考虑编写一个通用的 vi 前端,将其应用于各种编辑器/文本框(即:pidgin)。
这个思考过程的结果之一是,输入语言应该有点规则(或最多与上下文无关)。因此 vi 实例的输入可以由状态机表示。这还没有完全证实,只是一个模糊的猜测!显然,必须投入更多精力来研究重复命令(例如:13j)是否可能无法使语言进入上下文无关语法。
如果 vi 输入语言是常规的,您可能有机会使用有界模型检查来计算该状态图中的状态转换序列,从而产生所需的输出。我认为目前进行有界模型检查的最有效方法是通过反例并将问题简化为 sat 实例(只需谷歌即可找到)。
我想听听您对此的看法,因此请发表评论,如果还有其他涉及的内容,我们可以尝试讨论一下。
编辑
我认为你可以尝试做编译器所做的标准优化器工作。
然而,特别是宏
q[az]
@[az]
可能很难找到和替换。我假设,这是 NP 完全的。My personal opinion on this is, that a clippy like tool is very difficult to handle. As people mentioned above I think the most difficult part about it is to understand the users intentions when writing text. If you put that away and have a clear way of adding semantics to your intentions your life could become a lot easier!
So instead of live suggestions I guess as a first step an input-output-sequence workflow could be easier to test and get results from.
I was thinking about programming a generalized vi front end to apply it to all kinds of editors/text boxes (i.e.: pidgin).
One of the results of this thought process is, that the input language should be somewhat regular (or context free at most). hence the input of a vi instance can be represented by a state machine. This is not fully proven, but rather a vague guess! Clearly more effort has to be put into whether the repetition commands (e.g.: 13j) might not get the language into context free grammars.
If the vi input language is regular you might get a chance to use bounded model-checking to compute a sequence of state transitions in that state graph that result in your required output. I think currently the most potent ways to do bounded model checking is via counterexamples and reducing the problem to a sat instance (just google for it).
I would like to hear your opinion on this, so please comment and if there is anything more involved we can try to chat about this.
edit
i think you can try to do standard optimizer work that compilers do.
however not that especially macros
q[a-z]
@[a-z]
might be hard to find and replace. I would assume, that this is NP complete.