These three lines of Vim script "highlights" all instances of TODO in my source code by placing [[[ and ]]] around it.
:set t_Co=1
:highlight Braces start=[[[ stop=]]]
:call matchadd("Braces", "TODO")
Unfortunately, this only works in "normal terminals". This is why I have to set t_Co to 1.
Can something similar be achieved in a color terminal or in gui? (Or in NeoVim?). This could be an extremely useful way of augmenting your code with meta information.
Please keep in mind that Vim is a text editor; these display the file contents mostly as-is. In order to augment your code with meta information, Vim offers:
(syntax) highlighting: colors and text attributes like bold or italic
concealment: hide or condense matches to nothing / a single character
signs (shown in a column left of the window)
Your approach is a hack that misuses the definition of raw terminal codes; these are meant to be invisible control sequences interpreted by the terminal, but you send visible text.
As you've found out at :help highlight-args:
There are three types of terminals for highlighting:
term a normal terminal (vt100, xterm)
cterm a color terminal (MS-DOS console, color-xterm, these have the "Co"
termcap entry)
gui the GUI
The start= and end= arguments (that your hack relies on) are only supported for "normal terminals", not for cterm and gui. That's why you have to :set t_Co=1 (i.e. force a non-color terminal) for this to work.
Because of these downsides (and more: redrawing problems, vertical navigation that's off), I would recommend to drop this, and use one of the "approved" methods listed above. There are so many Vim users, and they seem to be fine with them as well.
Related
I am running vim 7.3 on several machines. By default MatchParen is enabled on all of my instances. Using gvim on my windows machine, it is doing exactly what I want - when my cursor is on a bracket, paren, etc. it visually highlights the match. It does not affect cursor navigation. However, on my Ubuntu boxes, when I move the cursor onto the character, it actually jumps to the match.
I'm sure that the behavior is caused by MatchParens because if I do a :NoMatchParen, it stops. Unfortunately, I also don't get the highlighting at that point. I can't figure out where my settings differ, though.
I'll like you even more if you can point me towards a plugin that will always highlight the closest enclosing pair of characters around my current position (like a code oriented version of MatchTagsAlways)
When showmatch is set, the cursor is actually jumping, and the following line fixes the problem:
set matchtime=0
More details:
http://vimdoc.sourceforge.net/htmldoc/options.html#'matchtime'
Just like FDinoff said in the accepted answer, this is probably only a problem of colors.
So if the color of the matching "paren" disorients you, tweaking colors of background and foreground is likely the solution.
But HOW do you do this?? ^^
I've had quite a journey through the vimdoc (it was not easy).
I've tested a whole bunch of variables and found that the relevant tweak is the [hi]ghlight command and specifically the MatchParen group.
The solution
Adding this in my .vimrc did the trick:
hi MatchParen ctermfg=208 ctermbg=bg
Note that vim config files are read from top to bottom, and some types of "words" are matched by several options. For example, a boolean could also be a keyword. Thus you have to pay attention to the order of these options.
How does this work?
My problem was that the background had the flashy color while the foreground had the color of the background of my terminal, which made it really confusing. Thus switching colors was the solution for me. But maybe you will have to tweak it differently.
First, you can check the current value for highlight MatchParen by entering the following command (while inside vim, in normal mode):
:hi MatchParen
You'll see hi MatchParen followed by XXX in the current style, followed by a list of argument=value separated by spaces.
The important arguments are ctermfg and ctermbg for the "terminal" vim, guifg and guibg for the "gui" vim. (Where fg means foreground and bg means background)
You can change a value and see the result in real time. Just put your cursor over a match character and enter the following command:
:hi MatchParen SomeArgument=SomeValue
This will not be saved, so don't worry. When you find a proper combination of values, you can add them in your .vimrc as shown above.
Personally, I set ctermfg to 208 (orange color) and ctermbg to bg (a keyword for the current background color, if known by vim).
If you use vim in a gui, take a look here for the available choice of colors.
The cursor isn't jumping. The color scheme probably has defined bad colors for the MatchParen highlight group which makes it look like the cursor is jumping.
Running default gVim (v7.4.461) without any configuration (i.e. no .vim files) in openSUSE 13.2 Legacy 32 Bit, :set showmatch? reveals that showmatch is on at start, which is not Vim's stated default behaviour. We can account for this by adding :set noshowmatch in our .vimrc.
Is there a way in _vimrc to set a different colorscheme to be used when printing files?
I like a dark background light text scheme on screen, but obviously that doesn't translate well to paper.
Edit: I can change the scheme manually before printing, then change it back after and it works fine. Just curious if there's a way to tell Vim to always use a specific scheme while printing.
This is what :hardcopy outputs:
How about something like
:command Hardcopy let colors_save = g:colors_name <Bar> colorscheme default <Bar> hardcopy <Bar> execute 'colorscheme' colors_save
Maybe throw in the 'bg' option. If you care about local variables, make it a function:
command Hardcopy call Hardcopy()
function! Hardcopy()
let colors_save = g:colors_name
colorscheme default
hardcopy
execute 'colorscheme' colors_save
endfun
The Vim plugin "Printer Dialog" allows to configure printing parameters, one of them is the colorscheme to be used for printing.
After installing and configuring "Printer Dialog" press \pd in the Vim window you want to print. The following "dialog" will open:
Beneath other things the syntax-highlighting for printing can be selected. See :help printer-dialog for further details.
The variable g:prd_syntaxList defines the syntax-highlightings that can be selected. Default is
g:prd_syntaxList = "no,current,default,print_bw,zellner"
See :help prd_syntaxList for details on how to setup this feature.
:hardcopy will always print with a white background. From :help hardcopy:
The current highlighting colors are used in the printout, with the following
considerations:
1) The normal background is always rendered as white (i.e. blank paper).
2) White text or the default foreground is rendered as black, so that it shows
up!
3) If 'background' is "dark", then the colours are darkened to compensate for
the fact that otherwise they would be too bright to show up clearly on
white paper.
However, I'm not sure how exactly "[...] the colours are darkened to compensate [...]" works, so you may still want to go with #benjifisher's solution.
Alternatively, you could use :TOhtml to get an identical representation (definitely with a different colorscheme in this case), and then print that out in some other way. See :help TOhtml for relevant options, e.g. g:html_number_lines.
Using :TOhtml works quite well. It creates a html file with the same colour scheme being used.
I like the onehalf (link to github download instructions for vim) colour schemes because it it has a simple light and dark scheme. The syntax highlighting is the same between both schemes, besides white and black text which is switched.
So you can have a dark scheme on your computer, and then still print your code out and retain the general syntax highlighting which I find really useful.
this is what I do:
open the code I want to print
change to light scheme if not already in it by :colorscheme :onehalflight
run :TOhmtl which also opens the html file in vim
go to new html file, and save it to desired location
example, to save as text.html to downloads: :w ~/Downloads/text.html
open saved html file with your favourite browser, and print or do whatever you
want, this is nice because it allows you to see how many pages you are going to
print before you break your printer!
In C++ files that I edit with Gvim I have noticed that code lines which are in inside blocks
(curly braces {})
although are being shown on the screen with the correct amount of tabs in Gvim
(i.e. plus one tab from the code which is outside of this code block)
when I open the same files with an another editor
like sublime text
that extra tab that must exist in every line inside the code block does not exist.
So after opening these files with a hex editor I noticed that Gvim does not write those extra tabs in the code blocks?
Why does this happen?
Is it because of cindent?
Also how can I fix this rather than auto-reformat every time?
I am pretty sure that vim will faithfully save all the characters that are in the buffer. Various options affect how tabs are displayed, and whether actual tab characters or spaces are used for indenting. You can check their values, and see where they were set (default, in your vimrc file, or by some plugin) with
:verbose set ts? sts? et? sw? sta? ci? pi?
(These and more related options are grouped together if you open an options window with :options and look at Section 15.) If you want to visually check where you have tab characters rather than spaces, you can :set hls and then search for tab characters (or :match Search '\t') or you can :set list.
If you try all that and you still think that vim is not saving what is in the buffer, then there are odd things to check, like whether you have any BufWrite or related autocommands.
I wish I could format pieces of text in standard text files.
I would like to select a phrase or a word, invoke a simple command, and format it with these formatting:
bold
italic
underline
red font color
yellow background color
Is that possible?
(something like syntax highlighting in vim files but in my case with selected text)
I know there is a Txtfmt plugin in vim, I tried it 2 times the last years but uninstalled it every time.
This is why:
There is no way to visual select text and format it, you have to insert a begin code in the command-line write the text and insert an end code in the command-line.
You cannot copy the text because Txtfmt plugin inserts hidden formatting codes in the text
It is too complicate to insert a begin code and end code in the command line (after invoking a general command) and the codes are too complicated
There needs to be a kind of markup inserted into your text. Vim operates on plain text, it has no separate meta data layer like a word processor. With syntax highlighting and the new conceal feature, you can partially make Vim appear to be WYSIWYG, but actually you're still operating on the raw text.
If you're fine with that limitation and want to stick with Vim for your editing tasks, I'd suggest to use an existing markup solution instead of inventing a new one from scratch. By now, there are several syntaxes to choose from, with Markdown probably a favorite. (It's used here on Stack Overflow, too!) With an existing syntax, you can leverage all the existing plugins / mappings / commands, and even some external tools (e.g. for converting to HTML).
Here is probably the simplest possible implementation of what I believe you want. It allows custom strings to be highlighted in the current buffer using the colour/style you describe. The custom strings you choose to be highlighted cannot be saved between Vim sessions.
Firstly, define the highlight group SpecialTxt for your bespoke highlighting:
au ColorScheme * hi SpecialTxt guibg=yellow guifg=red gui=bold,underline,italic
(note that this has to be done via an autocmd so that loading a new colourscheme doesn't overwrite it).
Now you can select any regular expression to inherit this colour using:
call matchadd( 'SpecialTxt', [YOUR_REGEX], 1 )
Or you could write a simple command to set the match:
command! -nargs=1 Special :call matchadd('SpecialTxt',"<args>",1)
Or create a map so that double clicking on a word sets it to this colouring:
nnoremap <silent> <2-LeftMouse> :call matchadd('SpecialTxt',expand('<cword>'),1)<CR>
Hope that helps. Apologies if it is not quite what you are after.
Is it possible to not display a ~ for blank lines in Vim?
This confuses Mac Vim's scrollbar, and I quite don't like these tildes.
:hi NonText guifg=bg
That command should set the color of non text characters to be the same as the background color.
Vim 8.x:
You can now change the color just for the end of the buffer ~:
highlight EndOfBuffer ctermfg=black ctermbg=black
See changelog for Vim 8.x.
As jamessan said, you can’t disable them. The scrolling behavior isn’t specific to MacVim, either — it works the same way in the terminal and in gvim:
Instead of seeing this as a problem, what you should do is learn to see this as part of Vim’s flexibility. For example, you can use the zt command to scroll the current line to the top of the screen, regardless of where in the file it is. This can make it easier to write macros that do some work and then scroll back to where you were. The commands <C-E> and <C-Y> are made simpler because of this, as is the 'scrolloffset' option.
If you must, retrain your brain to think of Vim’s scrollbar as mapping to which line is on top, instead of which screenful is visible.
For NeoVim, you can set the fillchars value for eob to a space character and that will effectively hide it. (This might not work for plain Vim).
In Lua (Nvim 0.5+):
vim.wo.fillchars='eob: '
In VimScript:
set fillchars=eob:\
Note: Calling the above will override your fillchars value for other items as well (if set), so use this as a reference to set multiple values together:
set fillchars=eob:\ ,fold:\ ,vert:\│
Or use set fillchars+=... to append it your existing values.
You can't disable them, but you can change your colorscheme such that the NonText highlight group is colored the same as the Normal highlight group. However, this affects more than just the end of document tildes.
I doubt that it's actually "confusing" MacVim's scrollbar and if it is, then that's a bug in the patching that MacVim does.
The tilde ~ characters are meant to remind the user that those lines are not part of buffer content.
The above highlight trick will hide the ~ character, but it is still there. For some terminals, this may not even work. If you happen to be a Neovim user, you can use fillchars option to change the end of buffer symbol like this:
set fillchars=fold:\ ,vert:\│,eob:\ ,msgsep:‾
This will use space instead of ~ for end of buffer, effectively hiding the annoying ~.
You may also be interested in discussions here.