When working with positional data files, it is often very useful to highlight a specific column. In such files it is quite common to have huge "areas" filled with spaces (or NULL values) and only very sparse data points. In such cases it becomes difficult to read the file.
Here's an example excerpt:
462
63082
01089
75518 735301
53473 017146
37217
07
940376
762 2842
88331
40680 8928
645718
0131
03522
47210 27431
93837
8825072 49479415
52084 8940
0591705 205635
525429
65339 300
0397
1983
0
2605768
121991 648
3892
1260
I found it helpful to simply highlight a specific column. At first I tried to use a regular :match, but this turned out to be way to slow on huge data files. I posted this as another question. The answer is simple. cursorcolumn (available since vim 7.3) can be set to a range and is a lot faster as it does not need to match the characters.
Implementing the proposed solution I saw it working. But it's cumbersome, and - knowing vim - there should be an easier way to specify this.
Question:
Is it possible to set the cursorcolumn range to the columns of the currently selected (visual) block?
It turns out it's very simple. The function getpos can retrieve the position of any marker. We'll use this to extend the solution to the earlier problem:
:let &l:cc = join(range(getpos("'<")[2], getpos("'>")[2]),',')
Now, we can map this easily:
:vnoremap <F5> <ESC>:let &l:cc = join(range(getpos("'<")[2], getpos("'>")[2]),',')<CR>
So, now when editing a positional data file, we'll simply have to enter visual mode, select the portion of the file we need highlighted and press F5
Related
I have added the set nu to my vimrc file, and I like it, but I would like to have vim start with line number 0 (it's to match the samples from a book I am using to learn C++).
I saw a suggestion to change set nu to set rnu, and at first it looked good, until I moved downward, and the 0 moved with my cursor. I understand what's going on here - it's displaying a 0 for my current position, and the lines above and below are renumbered relative to where 0 is. While cool, this is not what I want.
Thanks in advance!
Shane
This is not possible without patching the source.
Note that, in Vim, line numbers can be used in many more ways than in "regular" editors so changing how the line numbers are displayed will have a non-negligible impact in other areas. This doesn't seem like a very good idea.
I am using
set relativenumber
set number
which let's me move easily around. However, it is often hard to know the exact the line number of the object where I would like to jump to because I first need to look to the left. I feel it would be easier if I could see the line numbers also on the right hand side right because my eyes have less space to follow (maybe?). I think the ideal setting would be to show the relative/absolute line number where the $ appears when whitespace characters are shown and to the left/right of the buffer. I.e.
1 Random text.$1 1
159 This is the line where the cursor is.$159 159
1 Some random text.$1 1
2 More random text. Another sentence. Maybe a third one? And so on.$2 2
3 Another line which might be quite long and my eyes focus somewhere here.$3 3
4 More random text containing more text and more words and stuff.$4 4
(In this example, I would like to do 3k but I may type 2k or 4k because I did not follow the correct line to the left.)
Is it possible to achieve this somehow?
Any suggestion on how to change my workflow are welcome, too.
Note: Using cursorline does not help as I do not seek the number of the current line.
No, there is no built-in support to your requirement. also I don't think this is easy to be done by plugin.
Maybe you could consider to change your habit/workflow. E.g. enable the cursorline option, to highlight your "current" line, it may let you easier to identify which line are you on right now.
To move cursor, if you don't want to count lines, you may want to try the EasyMotion plugin. It is very handy plugin. However it won't replace the hjkl ... motions.
No, that's not possible, unless you modify Vim's source code in a non-trivial way, or work around with kludges like a vertically split small scratch buffer at the side that is updated via autocmds.
Do you have :set cursorline? That helps (me) a lot to follow the current line, even with large window widths. Reducing those might help, too, though you have to deal with wrapping / scrolling of long lines then.
Is there a way to assign an individual character, as identified by a height and depth index, to a highlight group? Every match feature I have come across uses a regex pattern as input.
The reason I ask is because I am making a syntax coloring plugin that will make text an increasingly lighter shade of gray with increasing parenthesis depth. If vim has no such feature and another algorithm makes character-by-character highlighting unnecessary, please point me to it!
Vim has a whole set of special regular expression atoms that can specify buffer positions.
For lines, \%23l matches only in line 23. You can also use \%>23l for all lines starting from 23, and concatenate two of those with < and > to specify ranges.
For columns, there are the corresponding \%23c and \%23v. The former uses byte indices (what Vim somewhat confusingly calls "columns"), as returned by functions like col() and getpos(), the latter screen widths (from virtcol()).
By combining those atoms, you can select arbitrary blocks of text, and highlight them, e.g. with :call matchadd(...). See :help /\%l for details on the atoms.
For your plugin implementation, you may be able to get some ideas from the vim js context coloring plugin, which highlights JavaScript code according to its scope.
How can I can specific word wrapping for specific tags. For example, in LaTex I want word wrapping for my paragraphs but not for my figure commands (they are always very long and run off the screen).
Or with Javascript, I want the right margin for code to be at, for example 50 columns, but for the comments to be at only 40 columns
This is not builtin
You could probably script something yourself using a devious combination of `formatexpr` and synID(). I suggest you look at the help of the latter first, because it contains inspirational samples:
for id in synstack(line("."), col("."))
echo synIDattr(id, "name")
endfor
taken from :he synstack
The formatexpr is usually set to something like
:set formatexpr=mylang#Format()
thus delegating to a filetype plugin. You could implement the function to use different margins for different syntax contexts.
Bear in mind
the default formatexpr (if absent, formatprg) are probably no good for a source file (in my experience it has the tendency to string together lines as if they were text paragraphs). But then again, you can implement it any which way you want
that syntax highlighting may become out of sync. I'm not sure what happens when the cursor is at, say, 70% of a large document and you issue ggVGgq. It might not update the syntax highlighting all the way (meaning that your formatexpr function would get the 'wrong' synID() values. You get around this by saying something like
:syntax sync fromstart
this again might impact the highlighting performance depending on the size/complexity of the source and highlighting scripts
I work a lot with files which contain data on fixed positions. Non-delimited "CSV" files if you will... Often, I'd like to highlight a specific column.
I tried
:match ErrorMsg /\%>30v.\+\%<40v/
but this runs extremely slow and only matches the first line. I suppose the file may be too large for this. Mind you, the files are very wide (around 40000 characters) but not very long (around 2000 lines). The data originates from old tools over which I have no control.
Example file:
63082
01089
75518 735301
53473 017146
37217
07
940376
762 2842
88331
40680 8928
645718
0131
03522
47210 27431
93837
8825072 49479415
52084 8940
0591705 205635
525429
65339 300
0397
1983
0
2605768
121991 648
3892
1260
Any ideas?
Are you using Vim 7.3?
Apparently they just recently added a colorcolumn option.
Try:
:set colorcolumn=31,32,33,34,35,36,37,38,39
Note that :help 'colorcolumn' says "Will make screen redrawing slower". I somewhat replicated your scenario, though, by using pure blocks of 1234567890 with the exact repetition count you specified.
The command you mentioned is very slow. colorcolumn isn't.
but this runs extremely slow and only matches the first line
By "first line" do you mean the first displayed line, when word wrapping is enabled? Unfortunately colorcolumn will exhibit the same behavior...
This is off the original topic, but Google leads people here. When trying to fix a horribly indented YAML or any other swiftwidth=2 file, I really struggle to visually recognize what is and isn't in a valid column. A comment by #ib to the accepted answer lead me to this gem.
:let &l:colorcolumn = join(range(3,15,2),',')
It basically says set colorcolumn to the comma delimited string value of 3 through 15 counted by 2. (In other words: :set colorcolumn=3,5,7,9,11,13,15) The result looks like this:
You can do a simple :set colorcolumn to see what value results.
To get rid of it do :set colorcolumn=