使用 vim 的 -W 选项 [英] using the -W option of vim

查看:95
本文介绍了使用 vim 的 -W 选项的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

vim的-w-W选项理论上有如下作用:

<块引用>

-w {scriptout} 你输入的所有字符都记录在文件中"scriptout",直到你退出 Vim.如果您想创建,这很有用与vim -s"一起使用的脚本文件或:来源!".当脚本"文件已存在,新字符被附加.也可以看看|复杂重复|.{scriptout} 不能以数字开头.{Vi 无此功能}

-W {scriptout} 与 -w 类似,但不追加,覆盖现有文件.{Vi 无此功能}

但是当我这样做时,{scriptout} 文件将始终以十六进制序列开头,例如 80 fd 60(有时是 80 fd 62).

我使用的是来自portableapps.com 的gvimportable.exe 7.3.使用 -u NONE 开关,它的作用相同.

这个幻数"有什么用?在带有 gvim.exe 的 Windows 下,在删除这三个前导字节之前,我无法重播我的脚本......

似乎此功能可能非常有用,但文档很少.

感谢您的回答.

解决方案

(这个答案可能明显支离破碎,我花了一段时间玩 - 我也想找到一个解决方案,因为它吸引了我 - 不仅仅是200 :P.它或多或少显示了我的思路和实验.)

我现在可以在 Linux 上用 gvim 重现它,也就是 /usr/bin/vim.gnome -g;以 vim -g 的方式运行也一样.

<小时>

深入研究代码:(在这种情况下是徒劳的,但做起来很有趣,学习如何做)

我已经查看了源代码,现在可以稍微解释一下(但没有用!);它获取 outfile FILE (src/globals.h:1004) 集 (src/main.h:2275);然后将其写入 src/getchar.h:1501,在 gotchars(第 1215 行)使用的 updatescript 方法中,它是由 vgetorpeek 使用,由 vgetcvpeekc 使用...(不,我不知道这是怎么回事!)然后这些被用在很多地方.

无论如何,我想密钥在 src/gui.c 的某个地方,但我现在不知道在哪里!也有可能发送"了一些关键序列(物理上或虚拟上,我不知道),但鉴于跨平台的问题是相同的,它似乎比其他情况更有可能是 Vim 问题.

<小时>

有趣的情况导致可能的解释:

还有一点值得注意的是,如果自动退出,gvim -u NONE -w scriptout -c quit(加载后:quit)或gvim -u NONE -w scriptout -c quit (instant :quit, 从不显示 GUI), 文件 scriptout 为空.

另外,如果你打开 gvim 然后使用 X 按钮关闭它,不按任何键:

0000000: 80fd 6280 fd63 80fd 62 ..b..c..b

如果你打开 gvim,点击离开,点击返回并使用 :q:

0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a ..b..c..b..,...:0000010:710d q.

所以我认为是窗口事件在内部被翻译成别的东西.80 fd 62 是开序列,80 fd 63 80 fd 62 是闭序列.

我还发现了另一种触发 80fd 的方法,这让我想到某种用户可以访问窗口";默认情况下,Ubuntu 中的 GNOME,Ctrl+Alt+S 对窗口执行某些操作(不记得它叫什么;将其全部滑入标题栏,里面的应用程序失去键盘控制等).gvim ...(你知道参数!),i<Ctrl+Alt+S(收缩) Ctrl+Alt+S (展开) >Esc Z Q 产生这对我来说:

0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51 ..bi<..c..b>.ZQ

<小时>

总结:所以我们有了我认为的解决方案;gVim 以某种形式捕捉窗口消息——不管它应该或不应该——把它们放在它的 scriptout 中.如果你认为它不应该(或者想知道他们为什么被留下,或者他们是否应该被留下,或者你是否应该关心),我想,在 Vim 列表中询问.

the -w and -W options of vim have theoretically the following effect:

-w {scriptout} All the characters that you type are recorded in the file "scriptout", until you exit Vim. This is useful if you want to create a script file to be used with "vim -s" or ":source!". When the "scriptout" file already exists, new characters are appended. See also |complex-repeat|. {scriptout} cannot start with a digit. {not in Vi}

-W {scriptout} Like -w, but do not append, overwrite an existing file. {not in Vi}

But when I do this, the {scriptout} file will always begin with a hexadecimal sequence like 80 fd 60 (sometimes it is 80 fd 62).

I am using gvimportable.exe 7.3 from portableapps.com. With the -u NONE switch, it does the same.

What is this "magic number" for? Under Windows with gvim.exe I cannot replay my scriptout until I have removed those three leading bytes…

It seems that this feature, which could be very useful, is poorly documented.

Thank you for your answers.

解决方案

(This answer is probably fragmented significantly, it took me a while playing around - I wanted to find a solution too because it intrigued me - not just the bounty of 200 :P. It more or less shows my train of thought and experimentation.)

I can now reproduce it with gvim on Linux, which is /usr/bin/vim.gnome -g; running as vim -g does just the same.


Delving into the code: (futile in this case, but fun to do and to learn how to do)

I've looked through the source code and I can now explain it somewhat (but not usefully!); it gets the outfile FILE (src/globals.h:1004) set (src/main.h:2275); this is then written to in src/getchar.h:1501, in the updatescript method which is used by gotchars (line 1215) which is used by vgetorpeek, which is used by vgetc and vpeekc... (no, I don't know where this is going!) then these are used in a number of places.

Anyway, I suppose the key is somewhere in src/gui.c, but I don't know where at the moment! It's also possible that some key sequence is being "sent" (physically or virtually, I don't know), but seeing as the issue is the same across platforms it would seem more likely to be a Vim issue than otherwise.


Interesting situations leading to a probable explanation:

It's also worth while noting that if you automatically quit, gvim -u NONE -w scriptout -c quit (:quit after loading) or gvim -u NONE -w scriptout -c quit (instant :quit, never shows GUI), the file scriptout is left empty.

Additionally, if you open gvim and then close it using the X button, pressing no keys:

0000000: 80fd 6280 fd63 80fd 62                   ..b..c..b

If you open gvim, click away, click back and use :q:

0000000: 80fd 6280 fd63 80fd 6280 fd2c 80fd 2e3a  ..b..c..b..,...:
0000010: 710d                                     q.

So I think it's the window events are internally translated into something else. 80 fd 62 is the open sequence and 80 fd 63 80 fd 62 is the close sequence.

I've found another way of triggering 80fd as well, which leads me to thing it's some sort of "user has access to the window"; by default with GNOME in Ubuntu, Ctrl+Alt+S does something with the window (can't remember what it's called; slides it all up into the title bar, app inside loses keyboard control etc.). gvim ... (you know the arguments!), i<Ctrl+Alt+S (contracted) Ctrl+Alt+S (expanded) >Esc Z Q produces this for me:

0000000: 80fd 6269 3c80 fd63 80fd 623e 1b5a 51    ..bi<..c..b>.ZQ


Summary: so there we have what I believe is the solution; gVim catches the window messages in some form and - whether it should or shouldn't - puts them in its scriptout. If you think it shouldn't (or would like to know why they're left in or if they're even meant to be or whether you should care at all), ask on the Vim list, I think.

这篇关于使用 vim 的 -W 选项的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆