使用“代码段”插件有什么优点和/或缺点,例如snipmate,ultisnips,对于VIM,而不是简单地使用内置的“abbreviations”功能?
是否存在声明iabbr
,cabbr
等缺少片段插件提供的某些主要功能的特定用例?我找不到这两个“功能”及其各自实现之间的彻底比较是不成功的。
@ peter-rincker在评论中指出:
应该注意,缩写也可以执行代码。通常通过
<c-r>=
或通过表达式缩写(<expr>)
。将@@扩展到当前文件路径的示例::iabbrev @@ <c-r>=expand('%:p')<cr>
作为python的一个例子,让我们比较一个snipmate片段和Vim中的一个缩写,用于插入类声明的行。
# New Class
snippet cl
class ${1:ClassName}(${2:object}):
"""${3:docstring for $1}"""
def __init__(self, ${4:arg}):
${5:super($1, self).__init__()}
self.$4 = $4
${6}
au FileType python :iabbr cl class ClassName(object):<CR><Tab>"""docstring for ClassName"""<CR>def __init__(self, arg):<CR><Tab>super(ClassName, self).__init__()<CR>self.arg = arg
我错过了“片段”的一些基本功能,或者我认为它们在大多数情况下都是矫枉过正,当Vim的abbr
和:help template
模板能够完成时< / s> 大多数的东西片段吗?
我认为实现片段更容易,并且它们提供额外的美学/视觉功能。例如,如果我在Vim和其他插件中使用abbr
来运行/测试vim中的python代码 - 例如。 syntastic,pytest,ropevim,pep8等等 - 我是否错过了代码段提供的一些主要功能?
答案 0 :(得分:4)
片段更强大。
根据实现情况,代码段可以让您更改(或接受默认值)多个占位符,甚至可以在扩展代码段时执行代码。
例如使用ultisnips,您可以执行shell命令,vimscript以及Python代码。
(ultisnips)示例:
snippet hdr "General file header" b
# file: `!v expand('%:t')`
# vim:fileencoding=utf-8:ft=`!v &filetype`
# ${1}
#
# Author: ${2:J. Doe} ${3:<jdoe@gmail.com>}
# Created: `!v strftime("%F %T %z")`
# Last modified: `!v strftime("%F %T %z")`
endsnippet
这将为您提供三个占位符(它为其中两个提供默认值),并设置文件名,文件类型和当前日期和时间。
在单词&#34; snippet&#34;之后,起始行包含三个项目;
就我个人而言,我主要使用b
选项,其中片段在一行的开头展开,而w
选项则扩展片段,如果触发器字符串从单词的开头开始。< / p>
请注意,您必须键入触发字符串和,然后输入实际触发扩展的键或键组合。因此,除非您希望 ,否则不会展开代码段。
此外,片段可以通过文件类型进行专门化。假设您要定义四个级别的标题h1
.. h4
。您可以在不同的名称之间进行相同的扩展。 HTML,markdown,LaTeX或restructuredtext文件。
答案 1 :(得分:3)
片段就像内置的类固醇:abbreviate
一样,通常用:
在代码段插件中有三件事需要评估:第一,代码段引擎本身的功能,第二,作者或其他人提供的代码片段的质量和广度;第三,添加新片段是多么容易。
答案 2 :(得分:2)
Vim原生缩写的粗略超集。以下是重点:
非常适合常见的错别字和小片段。
<c-]>
:h abbreviations
):cabbrev
(通常用于创建命令别名)在命令模式下使用在大多数情况下,片段更强大,并提供其他编辑所享有的许多功能,但您可以同时使用这两种功能。缩写享受原生的好处,可用于远程环境。缩写还具有另一个明显的优点,可以在命令模式下使用。
答案 3 :(得分:2)
可以使用缩写完成可以使用片段完成的所有操作,反之亦然。您可以使用带有缩写的(镜像或不带镜头)占位符,您可以使用上下文相关的片段。
有两个重要的区别:
while
+标签。w
+标签可能就足够了。)还有一些其他差异。例如,缩写总是在任何地方触发。在评论或字符串上下文中看到for
扩展为for(placeholder) {\n}
肯定不是最终用户期望的。使用代码段,这不再是一个问题:我们可以期待最终用户在他要求扩展代码段时知道他正在做什么。不过,我们仍然可以建议context-aware snippets在评论中将throw
扩展为@throw {domain::exception} {explanation}
,或在其他地方扩展为throw domain::exception({message});
。