macos 使用命令行 Vim 与 GUI Vim 的原因
声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow
原文地址: http://stackoverflow.com/questions/2149456/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Reasons for using command line Vim versus GUI Vim
提问by John Gallagher
Background
背景
I'm building an application where it detects what documents you're using from the file system. To do this it must access the AXDocument attribute of the active window. MacVim provides this. Running Vim in the Terminal wouldn't provide this.
我正在构建一个应用程序,它可以从文件系统中检测您正在使用的文档。为此,它必须访问活动窗口的 AXDocument 属性。MacVim 提供了这个。在终端中运行 Vim 不会提供这个。
I've just put out a survey to ask what editor coders who are interested in my app use. A significant number of the folk using Vim used it directly from the command line.
我刚刚发布了一项调查,询问对我的应用程序使用感兴趣的编辑器编码人员。大量使用 Vim 的人直接从命令行使用它。
Why not use a GUI Vim?
为什么不使用 GUI Vim?
Why do some people prefer to run Vim this way versus a GUI implementation like MacVim?
为什么有些人更喜欢以这种方式运行 Vim 而不是像 MacVim 这样的 GUI 实现?
What advantages does this offer? As I understand it, you can send files to MacVim from the command line just as easily as command line Vim.
这有什么好处?据我了解,您可以像命令行 Vim 一样轻松地从命令行向 MacVim 发送文件。
回答by prodigitalson
These reasons may be different for each specific developer but my guess would be:
对于每个特定的开发人员,这些原因可能不同,但我的猜测是:
- vim is pretty much vim on any platform. GUI implementations can vary.
- Familiarity - being familiar with vim does not nessecarily mean being familar with vim wrapped ina GUI - espectially given #1.
- "Elite Complex" ;-)
- No definite avantages to the users over cli vim.
- vim 几乎是任何平台上的 vim。GUI 实现可能会有所不同。
- 熟悉 - 熟悉 vim 并不一定意味着熟悉包装在 GUI 中的 vim - 特别是 #1。
- “精英情结”;-)
- 对于 cli vim 的用户没有明确的优势。
回答by doron
One might not have access to a gui (think ssh) or simply force of habit.
人们可能无法访问 gui(想想 ssh)或只是习惯的力量。
回答by Matteo Riva
Although I don't use any feature exclusive to the GUI version (never touch the mouse while editing) I find GVIM more pleasing to the eye for fonts rendering and color management. So the only reason to use the cli version is not having access to a graphic environment (like when accessing a remote machine via ssh). Using GVIM also allows reuse of the terminal it was called from without having to use screen
.
尽管我不使用 GUI 版本独有的任何功能(在编辑时从不触摸鼠标),但我发现 GVIM 在字体渲染和颜色管理方面更令人赏心悦目。因此,使用 cli 版本的唯一原因是无法访问图形环境(例如通过 ssh 访问远程机器时)。使用 GVIM 还允许重用调用它的终端,而不必使用screen
.
回答by intuited
being able to run
vim
underscreen
provides- reliability: it will stay alive if X or the terminal app crashes. not sure how applicable this is to the Mac.
- the option to multiplex sessions within terminal tabs. I actually end up rarely using terminal tabs because of this. It's possible (albeit a bit confusing) to set up heirarchical
screen
sessions and move branches of them around.screen
is super awesome. This also provides an additional layer of text buffering in which you can search by regexp — this is useful if you spawn a shell command that is pages long and you're looking for a particular word in there. - the ability to connect to an existing session from another computer or reconnect after a network outage
- and friends
in addition to making it possible to use
screen
, the consolevim
provides better shell integration. Although it's possible to run shell commands from within gvim (again, I'm not sure how this applies to the Mac, I'm a linux guy), there are limitations. I rarely use a gui vim so I'm not sure about the exact limits. For example, ANSI color codes are removed. I find this annoying because I tend to interact with SCM that way, for example running:!git diff --cached
to check the changes in the index before committing. It makes for a somewhat quicker and more satisfying (mmm, diffy!) read if it's colourized.I used to feel that
gvim
was a big improvement for viewing diffs, but I've changed the background colour of my terminal to a dark non-black shade, and set:highlight DiffAdd ctermbg=Black :highlight DiffChange ctermbg=Black :highlight DiffDelete ctermbg=Black :highlight DiffText cterm=Bold ctermbg=None
The result of this is that in diff mode, differing text shows up with a black background, and unchanged text is coloured with the terminal background colour. For side-by-side diffs, this works wonderfully, since you can tell immediately based on the other side whether a given line is a change or add; for non-side-by-side you will be able to see an unchanged part in a changed line.
This means that you can leave syntax colouring on and still be able to see diffs. Again, you do need to be able to set the background colour of the terminal to a unique, dark, non-black shade. This facility is available in the terminal emulators that I use (
yakuake
/konsole
androxterm
) and many others.^[?Mac^M"mya)^O^Op
This also assumes that you're using a colourscheme meant for use with a dark background colour; I use a modified
delek
.Although I haven't tried this, there is also the option to run console
vim
in 256-colour mode on terminals which support that mode — which I believe includes most or all modern ones. This can serve to make much of the subtlety of GUI colorschemes available to consolevim
.^["mp
I also like it that it lives in the place where it was started, and starts up quick. So if I'm navigating around in the shell, as per my wont, I can edit a file without interrupting that flow or having to farm that operation out to a different piece of conceptual real estate. Having less things to keep track of is a big plus. Being able to background it is helpful, too, for example if I need to grab the contents of an unexported shell variable via
xclip
. If I'd spawned a GUI window instead I might have some trouble remembering where that shell was, or might have already closed it.My main reason for using a gui vim at all is that it makes somewhat more sense as something spawned from a gui app, eg a browser. In practice I never do this, and I suspect that it's fairly equivalent to just have a new terminal window pop up with a new console vim in it. Though there is likely some (window manager) window management functionality that is exclusive to gui implementations. This is pretty similar to the use case you're discussing.
能够
vim
在screen
提供的情况下运行- 可靠性:如果 X 或终端应用程序崩溃,它将保持活动状态。不确定这对 Mac 有多适用。
- 在终端选项卡中多路复用会话的选项。因此,我实际上最终很少使用终端选项卡。可以(虽然有点混乱)设置分层
screen
会话并移动它们的分支。screen
超级棒。这还提供了一个额外的文本缓冲层,您可以在其中通过 regexp 进行搜索——如果您生成一个长达数页的 shell 命令并且您正在其中查找特定单词,这将非常有用。 - 从另一台计算机连接到现有会话或在网络中断后重新连接的能力
- 和朋友
除了可以使用 之外
screen
,控制台vim
还提供了更好的外壳集成。虽然可以从 gvim 中运行 shell 命令(同样,我不确定这如何适用于 Mac,我是一个 linux 人),但有一些限制。我很少使用 gui vim,所以我不确定确切的限制。例如,删除了 ANSI 颜色代码。我觉得这很烦人,因为我倾向于以这种方式与 SCM 交互,例如:!git diff --cached
在提交之前运行以检查索引中的更改。如果它是彩色的,它会使阅读速度更快,更令人满意(嗯,diffy!)。我曾经觉得这
gvim
是查看差异的一大改进,但我已将终端的背景颜色更改为深色非黑色阴影,并设置:highlight DiffAdd ctermbg=Black :highlight DiffChange ctermbg=Black :highlight DiffDelete ctermbg=Black :highlight DiffText cterm=Bold ctermbg=None
这样做的结果是,在 diff 模式下,不同的文本以黑色背景显示,而未更改的文本以终端背景颜色着色。对于并排差异,这非常有效,因为您可以根据另一侧立即判断给定的行是更改还是添加;对于非并排,您将能够在更改的行中看到未更改的部分。
这意味着您可以保持语法着色并仍然能够看到差异。同样,您确实需要能够将终端的背景颜色设置为独特的、深色的、非黑色的阴影。这个工具在我使用的终端模拟器(
yakuake
/konsole
和roxterm
)和许多其他模拟器中可用。^[?Mac^M"mya)^O^Op
这还假设您使用的是用于深色背景颜色的配色方案;我使用修改后的
delek
.尽管我还没有尝试过,但也可以选择
vim
在支持该模式的终端上以 256 色模式运行控制台——我相信这包括大多数或所有现代模式。这可以使控制台可以使用 GUI 颜色方案的许多微妙之处vim
。^["mp
我也喜欢它住在它开始的地方,而且启动很快。因此,如果我在 shell 中导航,按照我的习惯,我可以编辑文件而不会中断该流程,也不必将该操作转移到不同的概念空间。有更少的事情要跟踪是一个很大的优势。能够将其作为背景也很有帮助,例如,如果我需要通过
xclip
. 如果我生成了一个 GUI 窗口,我可能很难记住那个 shell 在哪里,或者可能已经关闭了它。我完全使用 gui vim 的主要原因是它更有意义,因为它是从 gui 应用程序(例如浏览器)产生的。在实践中,我从不这样做,我怀疑这相当于弹出一个新的终端窗口,其中包含一个新的控制台 vim。虽然可能有一些(窗口管理器)窗口管理功能是 gui 实现独有的。这与您正在讨论的用例非常相似。
回答by thomasrutter
gvim is actually just a basic terminal emulator with vim running in it, and some menus and toolbar buttons up the top.
gvim 实际上只是一个基本的终端模拟器,其中运行 vim,顶部有一些菜单和工具栏按钮。
So if you have a good, full-featured terminal emulator already, you may as well use that instead, since you'll be using the same type of terminal window that you are familiar with across all your terminal sessions.
因此,如果您已经有一个很好的、功能齐全的终端模拟器,那么您不妨改用它,因为您将在所有终端会话中使用您熟悉的相同类型的终端窗口。
Another benefit is that it makes it easy to switch to a shell inside vim and then switch out seamlessly.
另一个好处是它可以轻松切换到 vim 中的 shell,然后无缝切换。
On Windows I prefer gvim. On Linux it's vim inside gnome-terminal, which is nice and configurable thankyou.
在 Windows 上,我更喜欢 gvim。在 Linux 上,它是 gnome-terminal 中的 vim,它很好且可配置,谢谢。
回答by Alexey Yakovenko
some gvim variations can't handle some of my hotkeys
some spawn separate window when i try to compile program
sometimes they simply can't use fonts like fixed or terminus correctly (think about "terminus bold" - some gvim variations simply stretch "terminus normal" instead of rendering with the separate font)
cli generally works faster than gui, especially if running in real textmode console (not possible on a mac though)
there are almost no benefits in using GUI version, and i'd loose ability to run in screen, ssh, to suspend process with ctrl+z, and many more.
某些 gvim 变体无法处理我的某些热键
当我尝试编译程序时会产生一些单独的窗口
有时他们根本无法正确使用诸如 fixed 或 terminus 之类的字体(想想“终端粗体”——一些 gvim 变体只是拉伸“终端正常”而不是使用单独的字体渲染)
cli 通常比 gui 工作得更快,尤其是在真正的文本模式控制台中运行时(尽管在 mac 上不可能)
使用 GUI 版本几乎没有任何好处,而且我无法在屏幕、ssh 中运行、使用 ctrl+z 暂停进程等等。
回答by Aito
To avoid (or at least minimize) the use of the mouse.
避免(或至少最小化)使用鼠标。
回答by Tomislav Nakic-Alfirevic
vim is way more performant with huge files (100-500MB .csv or .xml files in my case).
vim 在处理大文件时性能更高(在我的例子中为 100-500MB .csv 或 .xml 文件)。
gvim beats vim hands-down when used to compare files (gvimdiff): setting the font (want more content on the screen?), dragging the window split line (want to see more of one file rather than the other) etc.
gvim 在用于比较文件 (gvimdiff) 时胜过 vim:设置字体(希望屏幕上显示更多内容?)、拖动窗口分割线(希望查看更多文件而不是另一个文件)等。
Other than that, I haven't seen other mayor differences and use gvim except when working with large files because I find it more handy in a graphical environment (gnome).
除此之外,我还没有看到其他市长的差异,除非在处理大文件时使用 gvim,因为我发现它在图形环境 (gnome) 中更方便。
回答by Neg_EV
The main reason I use the command line is that I spend most of my day in a terminal already, and my use of vim reflects this. I do not open up vim for a long while just editing different files then opening others without closing it; I usually open a file or two do a few edits then do some command line tasks, maybe change a directory, and open up vim somewhere else. When using the a gui there is substantial lag when opening the editor. This wouldn't bother me if I opened it once and left it open but I tend to not work that way. So the command line works better for my workflow. Furthermore since there is no real benefit feature-wise of the GUI over the command line and vise-versa, I've always just stuck with the command line since it suited me better.
我使用命令行的主要原因是我大部分时间都在终端中度过,我对 vim 的使用反映了这一点。我很长一段时间都不会打开vim,只是编辑不同的文件然后打开其他文件而不关闭它;我通常打开一两个文件做一些编辑,然后执行一些命令行任务,也许更改一个目录,然后在其他地方打开 vim。使用 gui 时,打开编辑器会有很大的延迟。如果我打开它一次然后让它保持打开状态,这不会打扰我,但我倾向于不那样工作。所以命令行更适合我的工作流程。此外,由于 GUI 在命令行和反之亦然的特性方面没有真正的好处,我总是坚持使用命令行,因为它更适合我。
回答by flyingoctopus
Pair coding via vim + gnu screen is the selling point for me. I work in screen/vim all day, it allows people to remote into my screen session and we can both edit files fluidly. It's so hot right now.
通过 vim + gnu screen 进行配对编码是我的卖点。我整天都在 screen/vim 中工作,它允许人们远程进入我的 screen 会话,我们都可以流畅地编辑文件。现在太热了。