这是vim的bug?

[xwsnet]

今天在学习零宽度问题上面的时候发现的。

以下是vim的help中的说明：

代码： 全选

\zs	匹配任何位置，并将匹配起始处置于该处: 下一个字符将是整个匹配的第一个字
	符。|/zero-width|
	例如: 
		"^\s*\zsif"
	匹配行首的 "if"，忽略前导的空白字符。
	可以使用多次，但实际使用最后一次在匹配的分支里遇到的。例如:  
		/\(.\{-}\zsFab\)\{3}
	找到第三次出现的 "Fab"。
	{Vi 无此功能} {仅当编译时加入 |+syntax| 特性才可用}
							*/\ze*
\ze	匹配任何位置，并将匹配结尾处置于该处: 前一个字符将是整个匹配的最后一个
	字符。|/zero-width|
	可以使用多次，但实际使用最后一次在匹配的分支里遇到的。
	例如: "end\ze\(if\|for\)" 匹配 "endif" 和 "endfor" 中的 "end"。
	{Vi 无此功能} {仅当编译时加入 |+syntax| 特性才可用}

因此，在以下文本中

代码： 全选

lvcreate -n User53 -L 8G vgdlpx
lvcreate -n User54 -L 8G vgdlpx
lvcreate -n User55 -L 8G vgdlpx
lvcreate -n User56 -L 8G vgdlpx
lvcreate -n User57 -L 8G vgdlpx
lvcreate -n User58 -L 8G vgdlpx
lvcreate -n User59 -L 8G vgdlpx
lvcreate -n User60 -L 8G vgdlpx
lvcreate -n User61 -L 8G vgdlpx
lvcreate -n User62 -L 8G vgdlpx
lvcreate -n User63 -L 8G vgdlpx
lvcreate -n User64 -L 8G vgdlpx
lvcreate -n User65 -L 8G vgdlpx

我使用

代码： 全选

/User\zs\d\+\ze

可以找到所有User后面的数字，但是如果去掉User
并且把\zs和\ze调换，使用下面的查找方式

代码： 全选

/\ze\d\+\zs

这样的话，vim将无结果，并且CPU使用率会涨到50%，我怀疑是进入到死循环了。(如果你试验没有相同结果的话你可以多按几次n)，
请问把\ze放在\zs之前为什么会出现这样的结果？如果真是死循环的话是什么原因导致的？

不光是我给的例子文本会出现这样的结果，只要你查找单词在文本中存在，并且你把他放在\ze和\zs之间，也会出现同样的问题。

[lilydjwg]

因为一个匹配不可能先结束然后才开始；Vim 无法给你一个负长度的字符串（虚字符串？）。至于CPU的使用问题，发到 vim_dev 邮件列表吧。

[xwsnet]

因为一个匹配不可能先结束然后才开始；Vim 无法给你一个负长度的字符串（虚字符串？）。至于CPU的使用问题，发到 vim_dev 邮件列表吧。

是啊，既然不存在这样的字符应该报找不到模式的信息，他不报找不到模式就说明他还在找，直到ctrl+c才能结束，这个问题在vim里面是不是需要改呢？

[lilydjwg]

是啊，既然不存在这样的字符应该报找不到模式的信息，他不报找不到模式就说明他还在找，直到ctrl+c才能结束，这个问题在vim里面是不是需要改呢？

当然需要改啦。发邮件列表吧。

[fanhe]

死循环了？报bug吧

[xwsnet]

邮件列表我没有哦，bug我也不知道怎么报啊，最主要我的英文很烂，看到的还是帮忙报报吧