In Gvim I have the following File menu:
Next to Save it says :w.
Recently I've been informed that :w is not save but is write.
Why is the menu set out like this and what are the differences between write / Save / :w ?
"Save" is the standard term for "write everything to disk", and that's what plain :w does.
However, :w also has a number of additional arguments which can make it do other things, such as append part of the current file to some other file (see :h :w). Hence, it is more accurate to call :w a write command, rather than just a save command - but plain :w is equivalent to a simple save command.
The :w[rite] command is very versatile, it can do a lot of things. But in its plain, short :w form without arguments, it persists the current buffer contents to disk, i.e. does what is usually associated with File > Save.
Note that there's also the :update variant, which only performs the write when the buffer has been modified. Many users bind this command to the Ctrl + S shortcut, to allow quick and frequent saving.
It's basically writing the buffer to the current file (using vim myfile.txt).
And you can also save this buffer as a new file using (:sav mynewfile.txt)
GVim is an attempt to make Vim more accessible to users unfamiliar with the command line and those menus are there to ease the pain you may feel when faced with an editor without traditional menus.
Those menu labels, "Save", "Open", "Exit"… use a familiar naming scheme for your convenience but Vim, like its ancestor Vi, doesn't really adhere to the WIMP convention: Vim's commands have different names and may work differently from the norm. The commands on the right of each menu item are there as hints: the idea is that you learn them and, progressively, stop using those menus and use the command line exclusively as it's far more efficient.
Also, Vim has an extensive built-in documentation. Use :help :command if you want to know what :command does, :h :w for example.
Related
I want to:
Automaticaly close Lexpore after opening a file for better experience but I don't know vim script.
It shouldn't be hard, I suppose.
I will appreciate any comment!
I'm now learning vim script and trying to do it.
here is where I've got by now:
:autocmd <Lexplore> * :<Lexplore-exit>
or
if <command-mode> == "Lexplore *.*"
excute \\close last buffer. (because now I am in new buffer)
I just need to know how to say "RUN" / "RUNED" in script
then i use regex for anyfile and i need to say "CLOSE".
The truth is
I'm actually Hopeless! :)))))))))))))
There are other avenues to try before going full-on with VimScript. In this case, a simple mapping would probably be enough.
Basically, the right-hand side of a mapping is just a macro, a sequence of commands that you would type yourself, which makes mappings a very good and approchable way to discover Vim automation.
Assuming a simple layout, with only one window, how do you do what you describe manually?
You do :Lexplore and browse around.
In the Netrw window, you press <CR> to open the file.
Then you go back to the previous window (the Netrw window) with <C-w>p.
You close the window with <C-w>q.
Steps 2-4 above are easy to turn into a mapping (<key> is a placeholder, use what you want):
nmap <key> <CR><C-w>p<C-w>q
But that mapping will be available everywhere, which may not be a good idea. Enters the notion of filetype plugins:
Create these directories if they don't already exist:
~/.vim/after/ftplugin/ (Unix-like systems)
%userprofile%\vimfiles\after\ftplugin\ (Windows)
Create a netrw.vim file in the directory above:
~/.vim/after/ftplugin/netrw.vim (Unix-like systems)
%userprofile%\vimfiles\after\ftplugin\netrw.vim (Windows)
Put the mapping above in that file:
nmap <buffer> <key> <CR><C-w>p<C-w>q
The <buffer> tells Vim to only define that mapping in Netrw.
This is the simplest approach, which may or may not work for you.
A few notes regarding your comments…
Buffer numbers are implementation detail. They don't matter at all in your day-to-day work so you shouldn't think too much about them. Buffer names are far more useful and much easier to think about.
The "sidebar file explorer" UX pattern is a familiar one that newcomers like to transfer from their previous editor but it necessitates a lot of fighting against Vim itself to "work". Netrw's take on the pattern is different, yes, and it might take time to adjust to, but it fits much better within the overall experience. Hint: give up on :Lexplore. :Explore, :Sexplore, :Vexplore, and :Texplore are much more useful.
As you learn more, you will soon discover that file explorers, whatever UX pattern they follow, are not that useful to begin with.
Netrw already has a mapping for opening a file in a new tab page: :help netrw-t.
in Vim, I type :Explore to open the vim browser.
When I press on a directory, I enter the directory as desired.
When I press on a file, I start editing that file. I would like to do something else.
So basically I would like to map to 'enter directory' for directories, and something custom for files.
The netrw plugin allows opening of file in the current window, (vertical) splits, and a remote Vim instance. The closest built-in functionality to what you want is customized browsing with a special handler, which is triggered with the plugin's x mapping; cp. :help netrw-x.
You can customize via an external command, or a Vimscript function that you define (:help netrw_filehandler). In this, you can do "something else", with all the power of Vim to implement it.
As for the distinction between directories and files, this mostly falls flat due to the different keys used. If you need to distinguish in your custom function, the isdirectory() function is there to help.
alternative
The NERD tree plugin offers an alternative to netrw, and also offers a similar extension, either via custom mappings, or a menu. As it's mostly a drop-in replacement for netrw (but with additional functionality), it might be worth to check it out before investing too much in customizing netrw.
I often use the command :Explore to switch to another file. I also use a lot the command :buffer to switch between previously opened files, but it is not always convenient when a lot of files are opened.
Is there a way to display a list of all opened files (buffers) in the current window, in a "explore" way, without using plugin?
:help :ls is the closest you can get with basic built-in tools.
I would recommend creating a normal map like this in your ~/vimrc file.
" list buffers and jump to a chosen one
nnoremap <Leader>b :ls<CR>:b<Space>
It triggers your <Leader> plus b to execute two commands at once, first it shows all open buffers, then it allows you to type the buffer number to open it. It wort reading :h leader.
I was watching an online tutorial by tutsplus , during one of the lessons, the teacher started to move between buffers using :bn :bn :b#, but he forget to mention how to load files into the buffer before talking about navigating between the buffers, I searched and find that using:e filename or :o filename would load a file into the buffer.
So, what is the difference , I can't understand the document explanation provide within vim.
The difference is that you shouldn't use :o, which is a useless artefact of vi compatibility, and use :e (or one of its alternative) instead.
From :help :o:
Vim does not support open mode, since it's not really useful. For those
situations where ":open" would start open mode Vim will leave Ex mode, which
allows executing the same commands, but updates the whole screen instead of
only one line.
Just… forget that command even exists.
FWIW, even the vi specification is pretty vague about what open mode is and does.
I've used vi for decades, and am now practicing using vim, expecting
eventually to switch to it entirely.
I have a number of questions, but I'll start with the one that
troubles me most. Something I have long done in vi is to type
a bottom-line command into the file I am editing, yank it to a named buffer
(e.g., using the keystrokes "ayy) and execute that buffer (using
:#a^M). This allows me to edit complicated commands till they
work right, and to keep commands that I will use many times as I
work in a file. (I have
in my .exrc file a mapping that reduces this yank-and-execute to a
single keystroke; but that isn't relevant to my question.)
I find that in vim, I need a lot more ^Vs than in vi. This
means, on the one hand, that when I have some command-line in a file
that I expect to use this way, I now need to keep it in two
versions, one for vi and one for vim. Also, the requirement of the
extra ^Vs seems inelegant: evidently various special characters
that are interpreted once when the named buffer is executed in vi
are interpreted twice when its is executed in vim -- but why?
As an example, a command of the form
map =f :w^V|e foo^M
(mapping the keystroke-sequence =f to write the current file
and go to the file foo) works this way in vi, but has to have the form
map =f :w^V^V|e foo^V^M
in vim. (Here in both commands, ^V is gotten by typing ^V^V,
and ^M is gotten by typing ^V^M; so typing the first version
involves typing three ^Vs, and the second, seven.) To be
exact: the first version does work in vim if one actually
types it into the bottom line (with the indicated extra ^Vs);
but the latter is required in an executed named buffer.
Any explanation? Anything I can set to fix this? ("compatible"
doesn't seem to do it.) Any hope that it will be fixed in a future
release? (The system I am on uses version 7.0.)
(I should confess that I'm not a programmer; just a user who has
become proficient in vi.)
Personally, I'd stop using ^V completely. In Vim (I've no idea about Vi), there are various key notations that get round the problems you're having. For your specific example, I'd recommend:
map =f :w<bar>e foo<CR>
where <bar> means 'insert the vertical bar here' and <CR> means 'insert a carriage return here'. See:
:help key-notation
for more information. I find the <CR> much easier to understand than ^V^M.
That's an interesting way of using :#, which I hadn't thought of before. I generally just use the command line history when I need to edit complicated commands, and I tend to save common or complicated commands as mappings or commands in my .vimrc (of course, I have a mapping that will pop open my .vimrc in a new tab). But there are certainly benefits to using vim's normal mode rather than command line mode for editing a complicated command.
As I understand it, you not only want to avoid so many <C-V> characters, you would also like to be able to use the same commands in vim and vi. Unfortunately, that would preclude you from using the (preferred in vim) key-notation. I think that you should be able to use the cmdline mode's Ctrl-R Ctrl-R register to help you out (:help c_<C-R>_<C-R>). E.g.
map <Leader>e mm^"ay$`m:<C-R><C-R>a<CR>
mm - mark cursor location so we can return later
^"ay$ - yank current line into register a (ignoring whitespace at beginning and newline at end)
``m` - return cursor to start position
: - enter command line mode
<C-R><C-R>a - place the literal contents of register a onto the command line, which seems to be where your problem with vim versus vi was coming to into play. I think that <C-R>a would give you the same behaviour you are seeing now with :#a.
- execute the whole thing
Using that mapping, I then typed your example of map =f :w^V|e foo^M into a file, placed my cursor on that line, ran my <Leader>e mapping, verified that your =f mapping had loaded correctly, and then ran it. Obviously you'll want to customize it to fit your needs, but I think that playing around with <C-R><C-R> will basically get you what you want.
All of that said, if you can, I'd strongly recommend taking the plunge and forgetting about compatibility with vi. Then you can use the much simpler key-notation and a host of other vim features. :-)