I have used Emacs for a long time, say, 6 or 7 years. And it seems that I got Emacs Pinky somehow. Now I am trying to switch to vim, and it's a very good editor, just like Emacs, except that I wonder how you guys develop with it.
Using Emacs with a buffer running shell, I code, compile, debug, profile or do anything. But vim is just an editor. I still don't know how to quick edit in command mode, where everything go back to stone age. Should I use other tools, like screen, as the environment, and vim just the editor?
FYI, I mainly work on Windows.
For those Emacs users wishing to have a Vim experience in terms of keyboard shortcuts and certain functions specifically designed to duplicate Vim behavior, the original poster may wish to consider using evil-mode:
http://www.emacswiki.org/emacs/Evil
In addition, the user may wish to configure his/her own keyboard shortcuts that make more sense based upon any physical limitations (e.g., pain in certain digits, etc.).
Finally, there is no requirement that a user keep his/her hands on the home row and stretch for the control/alt/command keys with a pinky. It is possible to type 100 words per minute or faster, hit keyboard shortcuts using two hands away from home row, and return to the home row blindfolded.
Related
I have several cpp source files in tabs in vim. I would like to have another tab with command prompt in order to run make. I open net tab , run sh and now I have console. But how to move from this console to other tabs? If I press ctrl+page up I have garbage in console and no tab change. How to move to another text tab when staying in console tab?
As I said, vim 8 or neovim both have an terminal emulator in it.
Since you are using vim 7 here are some other ways:
Tmux as #wizzup mentioned is perfect for this use-case. I think it is the most used Terminal-Multiplexer and extremly mighty. It is complex in comparison but since you are using vim, a steep learning curve should not be a killer point. However there are a few cavehats but you will find thousands of articles to solve them.
GNU Screen is an alternative to tmux, I have no experience with it, but should be usable pretty good with vim too.
With them you can use something like this Plugin which allows you to use the terminal in vim itself. However I haven't tested it but it seems to be rather groomed.
The man page says vim -X disables clipboard and window title operation. Is that all we get for vim connecting to X?
I find it a bit surprising, since the default settings slow down vim's startup significantly for me, and I've never needed the clipboard/window title behavior.
This is not gvim, by the way.
My educated guess would be, that it's because most people nowadays use terminal emulators in graphical environments, so it would be useful to behave like nice citizen of such an environment, providing more of a consistency in how various applications look or work.
As a bonus it's more vim-like to use * register for interrogating clipboard.
And more foolproof. I remember graphical terminal emulators where the only way to select text was the old fashioned mouse selection. Given that vim buffer in terminal would not scroll when you selected part of the terminal (as technically selection occurred outside vim in the realm of terminal emulator, and vim was not even aware it's currently taking place) it would not be possible to copy to clipboard anything spanning more than screen could currently hold. And even then it might not work the way you'd want depending on line wrapping settings.
But that is not the problem if editor has connection to system clipboard. Just copy any text you like to * register in the vim-way, and then you have it in system clipboard.
It's still just my speculation.
This question has been asked few times here and there, but you see all of them seem to have a linux desktop, i don't want a notepad++ alternative for a linux desktop, I want a notepad++ alternative for centos server, and I want it to be like nano not like vi, I don't know vi, so i'm looking for an editor that let me open a file on vps, choose a programming language, and it should correct my coding mistakes, this way I would not waste my time uploading files from windows to the vps, it should be easy to use and small, I don't want to waste my vps resources on an editor
Does such an editor exist?
Edit
#romainl
my vps is from 2host.com, I have centos 5 64 bit VPS E-CLASS, go to there for more info, that's all the info I know.
It's my production vps true, but i asked because i have another vps from chvps.com, the cheapest plan, i have mysite.com and mysite.net, I bought mysite.net, so no one can steal it, so i redirect users from mysite.net to mysite.com, I'm creating a new script for my site so chvps host mysite.net where i do some testing for the new version, like a staging server.
moreover i play with django on alwaysdata.com so I would like to get an editor.
I have seen many people saying that they love vim/vi, i will learn to use vim if you can tell me why vim is more powerful? aren't they all just editors?
To answer your question directly, here are a few CLI editors:
ne
joe
midnight commander's editor
As far as I know they won't show syntax errors as you type or even on save, you won't get any (semi)auto-completion either. All in all these are more powerful than nano but less powerful than NP++ (which I'm not familiar with) and a fortiori vim or emacs.
Anyway, a stock vim, even built with "huge" feature-set won't check the syntax of your PHP files as you type or on save, you'll need a bunch of plugins for that.
I don't know about emacs, but vim can be used in "easy" mode like this: vim -y yourfile.php.
Vim is one of the two best editors out there, learning its basics is not that hard. You probably don't have much time to spend on it right now but, once you do, try it. It rocks.
Can you tell us a bit more about your workflow (server layout, use of a VCS…)? At a glance it looks like you are editing files directly on a production server which is not really recommended.
<EDIT>
About Vim and all the others being just editors.
Yes they all have the same set of basic features: ability to input text, cut, paste, move the cursor… but even these basic features can be implemented in many manners. You say that you want NP++ features in a CLI editor, we can assume that you have tried other editors and ultimately decided to go with it because it worked better for you than the others.
All the CLI editors are different, like their GUI counterparts they shine in one place and lack in another. Because you are a programmer you "need" some advanced features and any editor not having a full fledged search/replace system supporting regex, some sort of auto-completion, macros, ability to build and show errors and so on.
Vim and Emacs both offer these fatures and sooo much more either natively or via plugins. As far as I know they are the only CLI editors really suited for programming so, to be able to work directly on your VPS, and be productive, you don't really have much choice: it's either one or the other.
The first problems you may be facing is the abruptness of the learning path and the weirdness of their "models" but most vim/emacs users will tell you that once its internalized it's hard to come back.
Why Vim (or emacs)?
I don't have a specific selling pitch to serve you. I was an advanced TextMate user, for me it was the best editor and it fitted all my needs but I was a little bored.
Then I stumbled on a Python screencast where everything looked magical to me and I found other screencasts by Dereck Wyatt and others and I was hooked: the way they moved through their code, the way they search/replaced, the omni-completion, the crazy plugins (surround rocks), the freaking motions and text-objects…
I took advantage of a slow week to learn the basics and make/revert a lot of mistakes and now I look at TextMate the same way you'd look at Notepad (not ++).
Here are a bunch of additional vim links for you:
One of the greatest answers here on SO
Coming home to Vim
Vi for smarties
The Physics of VIM
Vim Introduction and Tutorial
Ask HN: Suggestions for mastering vim?
Use Vim Like A Pro
Power Vim Usage
Why, oh WHY, do those #?#! nutheads use vi?
How I boosted my Vim
Ho, I just remembered another CLI editor: diakonos.
</EDIT>
If you asked allready a few times maybe the application you're looking for doesn't exists yet. I have to do the same things like you (edit files on the server, config and scripts) and I do it with jEdit with the langauge specific plugins plus FTP plugin. At least you could give it a try.
This might not be strictly a vim question, but here goes.
I have a proprietary IDE I'm working in, without any vim characteristics. I do, however, have keybindings.
My "diabolical plan" is to create a keybinding in the IDE (say Windows + V) to select all in the current buffer window in the IDE, open a gVim window, and dump the file into the window (perhaps setting filetype as well, but let's not get too fancy)
So the keybinding works to get it INTO a vim buffer - but how can I set up vim (either with a plugin or 3rd party tool) to grab the buffer on a :write and update the file in the IDE I launched it from?
Doable? Fool's errand?
If it's just about the IDE editor: write a Visual Studio Addon.
If you want to make this transparently work for any application (like "It's all text!" that #xofon mentions)... World Domination!
As long as you can worry that this is a fool's errand, I already know you're not going to finish it. Geniuses go after their goals against all odds. Oh, and they reach them, of course. On-topic: I think you can manage this for selected standard controls only (and you'll run into walls especially as Windows is growing security awareness these days).
On WinNT/2000 and earlier it was as 'simple' as creating DLL injection, hooking window procs for the related controls and doing the grunt-work. Nowadays, I'm not so sure this is going to work without hitches. You'll run into process isolation issues, WOW isolation, clipboard sharing idiosyncrasies, Citrix/Terminal server sessions. So: I hope you are convinced you want to mount these kind of challenges. If so, I'm all for it. It would be great to have Vi support on windows surpassing that on any platform. <dreams/>
You might have a look at the docs for IME (Input-Method Editing). I'm afraid this won't let you achieve modal editing, really.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
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.
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.
Why not use a GUI Vim?
Why do some people prefer to run Vim this way versus a GUI implementation like MacVim?
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.
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.
One might not have access to a gui (think ssh) or simply force of habit.
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.
being able to run vim under screen 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 console vim 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 and roxterm) 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 console vim.^["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.
gvim is actually just a basic terminal emulator with vim running in it, and some menus and toolbar buttons up the top.
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.
On Windows I prefer gvim. On Linux it's vim inside gnome-terminal, which is nice and configurable thankyou.
To avoid (or at least minimize) the use of the mouse.
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.
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 is way more performant with huge files (100-500MB .csv or .xml files in my case).
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.
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).
Speed of rendering
proper shell integration with
suspend (C-z),
alternate terminal,
uniform copy/paste
nicer quickfix integration (all external programs run inside your terminal, instead of popup windows... )
network agnostic: can run over ssh
using GNU screen, can detach/attach session over internet;
To the sometimes mentioned 'downside':
mouse support is up to par with :se mouse +=a; this enables selection, window border dragging with the mouse, even over GNU screen over ssh
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.
As a big vim user myself, although I know about GUI vims, I don't use them just out of habit.
I've been using vi since 1990, switched to vim a few years ago but still call it through an alias (alias vi=vim).
For me its just habit. vim works well as it is. Perhaps the gui offers more and I should explore it, but vim works just the way I expect it to and want it to.