How to set and unset relativenumber to all buffers? - vim

As regards line numbers, when doing normal file editing, I prefer to have the following setting
set number
set relativenumber
because the formers tells me where I am, the latter helps me using j and k effectively.
However, when debugging with gdb, I often want to set breakpoints; hence, I'd like to turn the latter option off, executing the set norelativenumber command on a global scope, so that all files I'm editing show the actual line numbers.
In this respect,
I kinda know how to trigger the action (when I execute the :Termdebug command, I should also execute set norelativenumber),
but, this is the question, I don't know how to apply that setting to all the buffer (well, not all the buffer, as I don't need numbers in the gdb window, nor in the program's output window, nor in the help, if I open one, and so on);
furthermore, I'm not sure how to handle the case that I quit the debugger (in that case I should set again set relativenumber globally).

Try this:
bufdo set norelativenumber
bufdo, windo, tabdo allow for operations on all buffers, windows and tabs respectively.
You may also want to look at https://vim.fandom.com/wiki/Run_a_command_in_multiple_buffers
Cheers

The answer from Csaba Dunai is useful as far as it gives a link and some feed for thoughts.
On the other hand, the proposed solution is not really the solution, for the simple reason (I had not thought about this) that number and relativenumber are not local to buffers but local to windows. Therefore, if windows are open in more tabs, the command to go is the following:
tabdo windo set norelativenumber
As regards the complete workflow that I was thinking about, I came up with a solution which seems to work pretty well for the time being. It is in code review here.

Related

How to source vimrc in All buffers

To source vimrc in all buffers in the current window I do :bufdo so~/.vimrc ,to source vimrc in the ACTIVE buffers in all windows I do :windo so~/.vimrc. How to source vimrc in all buffers in all windows?
for some reason if I do:bufdo so~/.vimrc | :windo so~/.vimrc the active buffer in the non-active window changes.
example: if I set set number in my .vimrc, I want all buffers in all windows affect the change.
the solution might be something like this:
for window in windowlist
execute 'bufdo so~/.vimrc'
I use vim 8.2 .
PLEASE NOTE: I did try all of the commands you guys suggested but it seems that things aren't clear enough. all of the commands that includes :tabdo :windo :bufdo or combination of them doesn't work properly for what I want. please note that this is the same as changing vimrc and sourcing it with chain of these commands like :tabdo bufdo so~/.vimrc. for example :windo bufdo set number does set number to all buffers(active or hidden) in the active window but on non-active windows only does set number for the active buffer(buffer that is shown in the window) or :tabdo windo set number only does set number in active buffers in every window meaning that hidden buffers won't get line numbers.
I even made a reddit post about this problem on r/vim and made a video about it but I don't know why nobody gets what I say. honestly don't think this problem will be solved by someone else but me even though its a simple one.
The :bufdo command will consume | as part of the command to execute, so in effect you're running the :windo command for each buffer that you have active!
See :help :bar, which documents this behavior.
That help section also mentions a way to work around this behavior, by using the :execute command to run the first command from a string, which allows you to delimit the first command. Like so:
:execute 'bufdo so ~/.vimrc' | windo so ~/.vimrc
Please note that sourcing your vimrc file "in all buffers" or "in all windows" doesn't make much sense... The vimrc file typically has global commands that usually need to be sourced only once, and usually if you modify your vimrc, sourcing it again only once should be enough...
This might make sense with a separate *.vim script that affects local settings and is meant to act on a single buffer. The ftplugin, indent and syntax scripts come to mind. But also with those, they're normally run per buffer, not per window... It's not completely inconceivable that you'd have scripts that you want to run on every buffer and window, but it surely seems odd...
.vimrc shall only contain global definitions. That the way it's supposed to be used. Sourcing it in several buffers makes no sense.
I wonder if you're fighting with local settings for which the best tool to use is either ftplugin (when the setting are filetype driven), or a local_vimrc plugin for project driven settings.
To apply in all buffers and all windows:
:windo bufdo set number
If you have tabs, from :tabe, :tabf, :tab and friends. Just add tabdo like this:
:tabdo windo bufdo set number
I would advise not to source your vimrc like this. If you want a quick setting, just use the set command and friends.
:help tabdo
:help windo
:help bufdo
:help source
While I agree with most answers on sourcing your vimrc. I do believe there are uses of the source command. Particularly batch fixing. I've never tried using
:windo with this, I mostly use :argdo and :cdo. As I have more fine-grained control on what files I need to apply.
Batch fixing is particularly useful on a large codebase. You do your fixes with :g, :v, :s for example, and save them in a file called fix.vim. This is so useful, you could even pair macros with those commands (:g and :v) via :norm command.
:help norm
Then update your argslist via :args *.js or similar commands (like backtick expression) and finally do the :argdo source fix.vim

vi editor not loading saved macros

Need help with vi macros on (redhat-linux 7.5)
My ~/.vimrc looks like below:
set nu
let #c='0i#^[j'
let #u='0<80>kDj'
but still when I vi files, #c or #u doesn't work.
Also, when I cat ~/.vimrc, it shows as below, which I believe is due to control chars:
set nu
let #c='0i#'
let #u='0▒kDj'
However, they do work every time when I record them. Just don't load up from vimrc and work persistently.
thanks in advance :)
If you’re already using vim (instead of pure vi), you could do
let #c = 'I#^[' " make sure to insert a literal escape
Or better yet:
" in ~/.vim/after/ftplugin/c.vim
nnoremap <buffer> gcc I#<Esc>j
The second one can be done similarly.
This should work just fine, as long as the original byte sequences are kept (so <80> is a single character and not four < 8 0 >) - your cat output seems to confirm this. The only issue I can think of is that Vim might use a wrong encoding when reading the .vimrc (but somehow detecting the right one when editing it). A scriptencoding utf-8 at the top might help then.
In any case, by using :help key-notation, these issues can be avoided. You'd need to use double quotes to have then interpreted (and then write \<Esc> instead of ^[, \<BS> instead of <80>kb, and so on). While you're at it, why not define proper mappings (with :map, or rather :nnoremap), to free up the registers again.
Speaking of registers, there's always the chance of accidentally overriding them, they're limited in number, and hard to memorize; all things that mappings don't suffer from. If you really want to continue to reserve registers for these shortcuts (and don't have the problem of overriding them), you could just rely on the viminfo-file to persist them; there actually is no need to explicitly initialize them in your ~/.vimrc.
finally I got it working.
Just tried using "vim" instead of "vi" to see if it loads up the ".vimrc" and it did.
I was assuming that vi would too load .vimrc, but it seems I was wrong.
Now, I am able to use the saved macros exactly as expected.

Which commands are needed to set at top of the .vimrc file?

My question is pretty clear in title, isn't it?
Actually I'm writing my .vimrc and I want to know which commands should be set at the top of a .vimrc file? (like :set nocp that it needs be be first in a .vimrc file (according to its help file))
Personally, I have set nocompatible, then Vundle stuff (according to its docs), then just sets in alphabetic order and other commands. (By the way, 1928 lines that accumulated in my .vimrc over years work pretty well even after resourcing without any particular effort for that. I use indentation for sections, subsections, etc. to keep the config manageable.)
There are no mandatory commands, since if something must always be done for everyone, then this is not a part of a config.
In general, just write what you need step-by-step and fix any incompatibilities when they show up.
No, set nocompatible is not necessary anywhere in your vimrc.
I've collected a number of battle-tested best practices in this repository.

Stop vim from dynamically updating folds

Is there any way to stop vim from automatically updating folds on the fly? I really love vim's folding, and I prefer having it in syntax mode so that folds are created as I type. But for instance when I code C++ and I write a bracket { it automatically closes all subsequent folds, and when I then close the bracket again with a }, vim automatically expands all subsequent folds, meaning that I have to refold everything.
Another related problem, if I have the same document open in a different buffer, say I have run ":split", then writing an open bracket { will nest all folds in the buffer under the fold in which I opened the bracket, and closing it will un-nest the folds but also close all of them. If I use either "." or "->" to access a member function/variable, it resets all folds in the buffer to be whatever the current foldlevel is, regardless of which folds I have opened/closed myself.
This is somewhat frustrating when I have the same document open in two buffers so I can read the contents of one function when writing another, as I constantly have to switch buffers and reopen my folds.
In my .vimrc I have
set foldmethod=syntax
and that is about it. For autocompletion I use clang-complete and supertab with:
let g:SuperTabDefaultCompletionType = "<c-x><c-u><c-p>"
I think that is everything which migh affect this.
Edit:
Added some pictures to help illustrate the problem
Both problems can be solved with the following two autocmds:
autocmd InsertLeave,WinEnter * setlocal foldmethod=syntax
autocmd InsertEnter,WinLeave * setlocal foldmethod=manual
This sets the buffer local 'foldmethod' to manual when insert mode is entered or its window (a buffer display) is left, and sets it to syntax when insert mode is left or its window is entered.
This works because setting 'foldmethod' to manual will keep the folds automatically created by syntax as if you set them yourself (manually), and manual folds are not updated based on the syntax of the file.
I've found two bugs with this solution:
When switching windows while in insert mode, the autocmd will set the 'foldmethod' to syntax for the new window, even though it's in insert mode and should be set to manual.
This isn't really a problem for me because I use Vim like a civilized person and operate in normal mode by default.
When
a new buffer is created (e.g. by reading a file)
and 'foldlevel' is 0
and a particular syntax is used (I'm able to duplicate the issue with a C file)
and the o or O command is used to enter insert mode for the first time in that buffer (doing i<esc>o does not duplicate the bug),
then all folds below the cursor will be opened.
I accidentally discovered this when testing the above solution, and now looking back I'm surprised I found it; it's almost not even worth mentioning. I don't intend on trying to write a test file that has the exact syntax necessary to duplicate the bug, so this may go unnoticed for another eon.
I actually discovered this question several months ago and used the solution Ben linked to for a while, before eventually being annoyed enough with the multiple window for one buffer issue (your second problem) to fix it.
So thanks to Ben for his solution, and you for asking this question!
I made a bit of a modification to user4830797's answer which helps deal with situations where the file you're editing doesn't use foldmethod=syntax (for example, a .vimrc file which might use foldmethod=marker):
autocmd InsertLeave,WinEnter * let &l:foldmethod=g:oldfoldmethod
autocmd InsertEnter,WinLeave * let g:oldfoldmethod=&l:foldmethod | setlocal foldmethod=manual
I think you need to check :h 'foldlevel. You should also perhaps use :mkview, probably in autocmd which restores manually open and closed folds.
Other then that you should perhaps set folding method differently on different file types (for instance on C you could set it to manual or marker)
If you temporarily set the foldmethod to manual, then Vim will keep all the folds currently defined by syntax, and keep them in the exact open/closed state you have them in now. This can be done automatically with an InsertEnter autocmd and restored on InsertLeave to protect your fold states in a single window. Unfortunately I have not yet spent time trying to get it working in split windows, but using window-local variables it is easy enough to even account for the user switching windows or something without leaving insert mode. See http://vim.wikia.com/wiki/Keep_folds_closed_while_inserting_text for details and discussion.

Configure tab to show list of variants instead of cycling through in VIM

When opening new buffer it VIM, I type:
new /path/to/fi
If I hit "tab" at this point it cycles through files. How to configure VIM to show list of variants instead of going for the first one?
set wildmenu
Is all you need to add to your .vimrc. Read :help wildmenu.
Set your wildmode setting to something different, for example
set wildmode=list:longest
If I misunderstood the question completely, yell ... :)
(This is not a direct answer to your question, but I think it's even better :)
You should check out the Command-T plugin, inspired by TextMate's 'Go To File'. It filters out possible combinations very intelligently, just type a few characters of each subdirectory enough to distinguish it and it 'gets' it, the characters don't have to be at the beginning and can don't have to be sequential. It also shows you a list of options left.
I realize this is a terrible explanation so check out this video to see how it works.
The downside is it requires Vim to be compiled with Ruby support.
Control-P (ctrlp.vim) is a replacement for Command-T written in VimScript, so it doesn't require Ruby.

Resources