In a given text file, I would like to work on a "filtered view" (hiding lines with a pattern), but still to be able to edit visible lines : the filtering would only affect the visibility of some lines, and as soon as I would reset the filter, the hidden lines would appear again.
The feature I describe could be compared to the & key in the less command (except, of course, that less can't edit the file's content) :
&some_pattern <RETURN> starts a new filter,
& <RETURN> reset the filter.
Does such a feature exist in vim, natively or as a plugin?
This usually is done with folding; you can easily define a 'foldexpr' that filters lines based on a regular expression match; see Folding with Regular Expression for implementations.
However, a single fold line will remain for each condensed block. To do away with those, I can only think of the NrrwRgn plugin, which transfers selected lines into a separate scratch buffer. It's usually only for a single block, but :help NR-multi-example suggests this works on ranges, too:
For example before editing your config file, you decide to strip all comments
for making big changes but when you write your changes back, these comments
will stay in your file. You would do it like this: >
:v/^#/NRP
:NRMulti
It can be done with plain Vim, and it's named folding. Drew Neil has two screencasts about it that you might find informative.
Related
I want to be able to hide all code around the specific section of code that I am working with. Now I am wondering if this is possible in Vim somehow. I have experimented with it a bit already and have been successful at hiding lines above and below my selection by using highlight group Igore. This enables me to only see the lines that I want to focus on but the problem is when I begin to edit the code and add or remove lines. When I add a line or remove a line the already set highlight group Ignore is still maintaining the set line numbers so I either get to see some of the hidden code or some of the code that I want to see gets long and extends into the hidden line numbers. So I am wondering if there is some way to fix this or any other way to accomplish what I want in Vim?
Appreciate any suggestions!
Hiding or shading parts of the buffer is not the Vim way. Folding is the built-in feature that comes closest. With :set foldmethod=manual, you can then use zf or :fold to hide the parts above and below.
For a plugin solution, have a look at NrrwRgn - A Narrow Region Plugin. It allows you to edit parts of a buffer in a separate scratch buffer, with automatic syncing back.
To hide a range of lines (let's say from 1 to 10 and 20 to end, you can type :1,10fo|20,$fo
From there, you can create a function based on the current cursor position -10/+10
Note you have first to :set foldmethod=manual to make this works.
EDIT: a simple solution : :1,.-10fo|.+10,$fo
I am using vim to edit structured text files.
Sometimes I use search-and-replace feature, and sometimes I am better off with search, followed with a macro, in which case I have several macros at hand, and the choice of one depends upon the particular search result.
In both cases, though I have to spend some effort to arrive at an acceptable regex to satisfy my editing needs. As the regexs are often very long and sophisticated, I end up with both command-line history and search history full of my trial-and-error by-products. The correct regex is not always the last one in a series of attempts, so if I want to reuse the hard-earned regex in a similar editing situation, I have to dig through the pile again.
In search-and-replace scenario I have quickly fixed this with comments that I now put in place at the end of a would-be reusable search-and-replace command string, for example:
:%s/very_long_and_sophisticated_regex/another_long_and_sophisticated_regex/gc "comments on what this search and replace command does and how it might be reused
This way I can easily ignore the piles of stuff in my command line history and quickly find relevant re-use candidates, they are shown in different color. The commands are reusable right away, comments are ignored.
Not so with the search history, though.
Having rtfmed and searched the web, I have not found anything similar. At the moment I put quasi-comments using XXX at the end of reusable search strings, for example:
/search_string_containing_very_long_and_sophisticated_regex XXX comments on what it finds and how it might be re-used
This way I can at least find the right string for re-use, but I have to first delete 'XXX' and the comments.
I wonder if there is a more elegant way of commenting the search strings in search history, similar to command-line history.
You used the word "elegant" in your title, and that I don't have on offer. If instead you can also accept a quirky workaround that relies on Vim internals, here's one.
To restate your problem, it is possible to add comments after Ex :commands,
:AComplicatedExCommand -42 -quux " this fizzes the brobble
:HardToRememberCommand test.txt " use this to brew the framble
but the same is not possible for complicated search /queries (or ?queries).
I've just discovered that you can trick Vim by terminating your search query with a literal null byte:
/[Complicated]*regexp/^# this regexp finds all scrobbles
/another\+Rege\x*p/^# use this to search foo bars
The ^# here is a literal NUL. You can enter it by pressing CtrlV and then 000.
Vim will ignore everything after the null byte, but it'll still show the whole line in the search history, including the "comment".
You can add a regexp branch that never matches, e.g. /\%$indicator\|search string
\%$ is a special Vim atom matching the end of the file. Since that will never match when followed by the indicator text, the first branch (up to \|) will never match and therefore can represent your indicator.
I've created the TaggedSearchPattern plugin to make adding the tag and recalling it even easier.
I'm using conceal in a plugin to hide some data, but when the hidden line gets too long it makes a wrap which is still hidden and just looks weird.
how it looks:
<hidden metadata line that the user can't see......
which is wrapped and makes 2 empty looking lines when it gets long>
stuff
how it should look:
<a very long metadata line that is not wrapped>
stuff
How can I tell vim to not wrap certain lines (concealed ones)?
Wait, I figured out 1 way. Custom folding. A single line fold won't show as wrapped.
Now I just have to write a custom syntax folding part for my plugin and I'm golden.
It is not possible to do it on current version.
This is intentional. Without this cursor movements would be messed up,
as the screen line depends on how text is concealed, which requires
syntax parsing, which is slow.
For more information, see this discussion on vim_dev group.
I have started working on a huge PHP application that has thousands of lines of code in each file, with lots of huge if blocks, classes, and functions all existing in the same file. I'm not the only dev working on it, so I cannot refactor!
I have tried using the Tags List plugin but it does not really help. Is there any way to have VIM respect only a particular code block, and ignore the rest of the file? I am hoping for some or all of these features:
Enable line numbering only for the current code block, starting from 1 at the line containing the opening {, and showing no numbering for lines preceding it or after the closing }.
Searching with / would be restricted only to the block in question.
I am thinking along the lines of selecting the current block and editing it in a new buffer when enabling the mode, then replacing the existing block with the edited block when exiting the mode. However, I am having trouble actually implementing this feature. My current version is this:
map <F7> <Esc>mO<C-V>aBy:new<Return>p:set nu<Return>:set ft=php<Return>ggi<?php<Return><Esc>
map <F8> <Esc>ggdd<C-V>aBx:bp<Return>`O<C-V>aBp
However, this has several issues, such as the inability to perform incremental saves.
I would be very surprised if Vim allows the kind of line numbering you ask for.
This plugin (and 1 or 2 similar ones IIRC) allows you to visually select a region of your current file, work on it in another buffer and put everything back in its place in the original file on :w.
Even if it's not the solution you are wanting, I think the following can help you to solve your problem.
You can use phpfolding plugin, which folds by PHP syntax (functions, classes, methods, PhpDoc...)
You can then select a fold by pressing v$ over the closed fold and execute whatever you want with :whatever. For example, :s/this/self/g to substitute all this for self in the fold. When you press :, vim will automatically add '<,'> to denote following command it's only for the visually selected text.
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