☰

重新映射/别名较少到 vim 有副作用吗？

tag-icon • tag-icon vim alias vi less more
重新映射/别名较少到 vim 有副作用吗？

我添加了以下内容以.bashrc重新映射less到vim

alias vsi='vim -R -c ":map Q :q!<enter>" -' # Vim Standard Input [readonly]
alias less='vsi'

原因是我不想用我的键绑定首选项维护两个配置文件，并且我发现 vim 更有用且可预测（通常我找不到查找的文本，因为它没有突出显示或不在视图中）

它似乎是在和less之后开发的，因为他们无法打开“巨大”文件，那么当时被认为“巨大”并且无法处理的是什么？今天这不是问题吗？vimorevimore

这个别名会破坏依赖的脚本或程序less吗？

答案1

查看不完整的输入是一个问题：

seq 10000 | pv -qL 10 | less

答案2

它不会破坏依赖的脚本或命令，less因为 shell 别名不会为脚本或其他命令扩展。

Shell 别名只是为了方便交互式 shell 会话而存在。它们不会转移到从该 shell 会话启动的 shell 脚本和命令中，因为别名不是子进程继承的环境的一部分。

唯一的问题是，如果您自己忘记了自己有这个别名，然后继续在交互式 shell 会话中将其与额外选项一起使用。然后将这些选项提供给vim。

您也可以考虑使用view而不是vim -R.

关于“巨大文件”，这些文件的大小大于您的 RAM，或者至少与可用 RAM 的相当大的块大小相同。传统上，编辑器会在您打开文件时将整个文件加载到内存中，有些编辑器仍然这样做。因此，打开大文件会

  1. 慢点
  2. 编辑器可能会遇到资源限制（内存不足）

我相信 Vim 编辑器正在使用它的“交换文件”（您可能已经看到带有.swp文件名后缀的文件）来解决这个问题。请参阅:help swap-fileVim 中的内容。

less默认情况下，寻呼机将保留全部从管道读取数据时读取内存中的数据。如果读取的数据多于可用 RAM 的容量，就会遇到问题。幸运的是，有一个-B(或--auto-buffers) 选项强制less仅将读取数据的最后部分保留在内存中。然而，这显然使得不可能跳回之前查看的输入行。

寻呼机more有时是less经过伪装的（只是到二进制文件的硬链接less）。在系统上哪里more是实际的 more，当查看从管道读取的数据时，分页器不允许向后滚动。

既不less需要more完全读取文件就能够查看它的内容。两者都会在文件中查找到适当的位置。

答案3

它可能会导致意外的行为，例如，如果使用开关发出 less 命令。我喜欢使用“-N”开关来减少行号的运行，如下所示less -N filename：当我将 less 别名设置为 vim 时，我没有得到预期的行号（对于 vim，“-N”开关用于“不兼容模式”，这使得 vim“表现更好，但 Vi 兼容性较差”）手册页）。你能确信你的用例永远不会突出 less 和 vim 的不同行为吗？

相关内容