In vim I want to visually make transparent the space I have to write a text in markdown. I use hard wrapping with textwidth=79. I know by some calculation that I'll have 20 lines for a chapter for example. So, what I do is inserting 20 empty lines to get a visual feeling for what I can write. After writing some lines, I manually delete the number of lines already written from the empty lines, so that the visual impression still is correct.
What I want to do, is to automate this deletion process. That means I want vim to automatically remove one line below the last written line if this line is empty and after vim automatically started a new line because I reached 79 characters in the line before. How can I do this?
I know that there are autocommands in vim but I haven't found an <event> that fits to the action: after vim automatically hard wraps a line / reached new line in insert (or however you would like to describe it)
I don't think there's an event for that particular action but there's a buffer-local option called formatexpr that gq & co will use, if set. So you can write a function that inspects any placeholder whitespace, if existing. That function can call the text format command gqq to maintain original feel (+ the cursor movement to the new, empty line).
Related
I am looking at files that may have several consecutive identical lines.
Is there a easy way of jumping to the next non-identical line?
Alternatively I would like to be able to fold all the lines that are equal to the initial one showing just the number of linees that are folded.
You could define your own fold-expr:
first set fdm:
:set fdm=expr
then
:set foldexpr=getline(v:lnum)==#getline(v:lnum-1)?1:0
now you can test by typing zM, to close all fold, if you are lucky ^_^ all duplicated lines are folded.
you could type zR to open all folds.
if it works and you open those kind of file very often, you could put the above lines in your .vimrc.(au with ft) if only one time job, you can write mode line into that file.
Try this:
:nmap <F2> "1y$<CR>/^\(<C-R>1$\)\#!<CR>
It maps F2 to:
copy the current line into register 1
search for (and move to) the first line that does not match the contents of register 1
This seems to work well, unless the text of your copied line has escaped characters that will confuse the search regexp. This is because register 1 is just dropped into the search expression without escaping. This would be tricky to fix reliably, but for normal log files, it shouldn't be much of a problem.
Also: if you're not married to vim and just need to read the non-consecutively-duplicated lines of a file, the canonical UNIX way is:
uniq filename
If you want to be in vim but won't need to make changes to the file, try:
:%!uniq
(If you try the latter, be sure to exit without saving)
Objective
Yank a line and use it to overwrite some of the lines following it.
Assumption
It is preferable in this case to manually select the lines to apply the substitution to. In other words, automated find and replace is not desired.
Analogy
Think of this process as creating a “stamp” from a line of text and going through a list of items—each item being a line of text following the “stamp” line—and deciding whether that line should be overridden using the contents of the “stamp” or not (in the former case, replacing the line with the “stamp”, of course).
This last step of triggering the replacement of the line under the cursor with the contents of the stamp, should be as easy as possible; preferably, as easy as pressing . (repeat last change) or ## (execute the contents of macro register #).
Issue
The straightforward workflow is, of course, as follows.
Position the cursor on the line to be copied (using movement commands).
Enter line-wise Visual mode (via the V command).
Copy selected text (using the y command).
Manually position the cursor onto the line to be replaced (using movement commands).
Enter Visual mode again to select the text to be replaced (using the V command).
Paste over the selection (using the p command).
However, this approach does not work when the replacement has to be done multiple times. Specifically, replacing the text on step 6 overrides the (unnamed) register containing the line initially copied and intended to be used as a “stamp”.
What I have tried
I have tried using "_y to either yank or delete into the _ register, avoiding the loss of the contents of the stamp, but I am looking for something that ends up being quick and comfortable to type as I manually go through the list and apply replacements where I see fit.
What I would prefer not to use
I would rather not use macros or “remaps” for this, if I can help it.
Illustrative sample file
See the sample starting file below, followed by the desired final stage, for further clarity.
Sample file, starting condition
At this stage, I select the blueberry and make it my “stamp”.
blueberry
apple
banana
coconut
apple
banana
coconut
apple
banana
coconut
Sample file, desired final state
After having moved through the list, I have applied some replacements, “stamping” over some lines, making them the same as the “stamp” blueberry line.
blueberry
apple
banana
blueberry
apple
banana
coconut
apple
banana
blueberry
To make your workflow work as expected, you need to paste from the previous yank register "0, rather than the default register.
So use Vy (or yy, which is the same) to yank the first line as before, then position the cursor over the line you want to replace, and do
V"0p
this replaces the current line with the previously yanked text, but doesn't overwrite the yanked text. I hope I understood you correctly!
EDIT 1: repeating using a macro
I was surprised that this operation isn't repeatable using ., but this is presumably due to the use of visual mode. To repeat the operation using a macro, do this:
qqV"0pq
The macro can then be repeated by pressing #q or ##.
EDIT 2: repeating using .
Here's an attempt at making it repeatable using . by not using visual mode. After yanking the stamp line and moving the cursor, do this:
"_S<c-r>0<delete>
which uses the insert mode <c-r> command to insert the contents of register 0. Note that the <delete> is necessary because the stamp line contained a carriage return. If it did not (i.e. yanking using y$ rather than yy) the <delete> could be omitted.
I don't think you are going to reach your goal without at least a little bit of "remapping".
I've been using this one for a "long" time:
vnoremap <leader>p "_dP
p and P still work as usual and I simply hit ,p over a visual selection when I want to repeat the same paste later. You could also map a single function key to make the whole thing quicker.
Also, do you know about the c flag for substitutions?
:%s/coconut/blueberry/c
will ask for your confirmation for each match.
Many answers here outline the general keys or commands. I've turned them into my ReplaceWithRegister plugin, which also handles many corner cases, and allows quick repeat via the . command. I also use your described create stamp and replace technique often, and found my script indispensable. Should you not like it, the plugin page also has links to alternative plugins.
A really easy solution: just put this script in your .vimrc, then toggle off the "buffer-overwriting" side-effect behavior of the delete key by typing ,, (two commas) to enter "no side effects" mode.
In this mode your workflow now works exactly as you described: yank whatever you like, then select, paste, and delete freely and repeatedly -- your buffer always remains intact. Then type ,, again if you wish to restore vim's normal buffer-altering behavior.
The script is the accepted answer here:
vim toggling buffer overwrite behavior when deleting
One can resort to Ex commands to achieve the said workflow.
For a single substitution, yank the “stamp” line (with yy, Vy,
:y, or otherwise), then repeatedly use the combination of the
:put and :delete commands:
:pu|-d_
Like any other Ex command, this one can be easily repeated with the
#: shortcut (see :help #:) — unless another Ex command was issued
in the meantime (in which case that command would be repeated instead).
Of course, you can also record the above Ex command as a macro and
invoke it that way, too.
Starting with your cursor at the start of the line to be duplicated:
y$ to yank the whole line (excluding the linefeed).
j and k to advance to the next line to be replaced (repeating as needed)
Replace the line with your yanked text
C<c-r>0<esc>0 (first time)
. (subsequent times)
If there are more lines to be replaced, goto 2.
The cursor will remain in column zero after each step.
I may have a unique situation here. I want gVim (gui version, in Linux) to keep concealed characters concealed no matter what, even when the cursor is on that line or that character gets selected. (It should be as close to if the characters never existed as possible.) Currently the concealed characters show themselves when the cursor enters that line, which causes text to jump around when scrolling and when selecting text.
We are using gView (read-only gVim) to view logs, so as to take advantage of its robust syntax highlighting. Problem is, these logs contain lots of escape characters and TTY color codes, that make reading difficult. (^[33mSomeText^[0m)
I'm using this line to hide them:
syntax match Ignore /\%o33\[[0-9]\{0,5}m/ conceal
Since the files are viewed by non-vim-experts, it looks glitchy and broken when the text un-conceals itself. (And also looks glitchy and broken if the color codes are present, and also looks glitchy and broken if the color codes are blacked-out to become invisible, but still show when selected and appear after copy/paste.)
This should be fine because these files are opened read-only in gview, with an extra set nomodifiable making it even more difficult to save the file. While it's possible to edit and attempt to save the logs, doing so is considered both an invalid thing to do, and a harmless thing to do, and requires enough Vim skills that if someone manages to edit a file they know what they're doing. The problem with being able to edit a line with concealed text does not apply.
If 'conceal' can't be configured to keep hidden text hidden no matter what, an acceptable alternative would be to replace the TTY color codes with whitespace when the file gets opened. But, this has to be done in read-only mode, and we can't have gview throwing up a save dialog on closing the window because the file has been modified by its .vimrc.
Note: I am in full control of the .vim script file sourced when these are read, but cannot control the existence of the TTY color codes or the code that opens the log files in gview. (i.e. I can't pass it through sed or anything like that.) The ideal solution is anything that can transparently nuke the color codes from within a .vimrc, but I'll hear any suggestions. The 'conceal' feature is just my most promising lead.
So, any ideas how to permanently get rid of these on file view without dialogs popping up on close?
:help conceal
When the "conceal" argument is given, the item is marked as concealable.
Whether or not it is actually concealed depends on the value of the
'conceallevel' option. The 'concealcursor' option is used to decide whether
concealable items in the current line are displayed unconcealed to be able to
edit the line.
:help concealcursor
Sets the modes in which text in the cursor line can also be concealed.
When the current mode is listed then concealing happens just like in
other lines.
n Normal mode
v Visual mode
i Insert mode
c Command line editing, for 'incsearch'
'v' applies to all lines in the Visual area, not only the cursor.
A useful value is "nc". This is used in help files. So long as you
are moving around text is concealed, but when starting to insert text
or selecting a Visual area the concealed text is displayed, so that
you can see what you are doing.
Keep in mind that the cursor position is not always where it's
displayed. E.g., when moving vertically it may change column.
Also, :help conceallevel
Determine how text with the "conceal" syntax attribute |:syn-conceal|
is shown:
Value Effect ~
0 Text is shown normally
1 Each block of concealed text is replaced with one
character. If the syntax item does not have a custom
replacement character defined (see |:syn-cchar|) the
character defined in 'listchars' is used (default is a
space).
It is highlighted with the "Conceal" highlight group.
2 Concealed text is completely hidden unless it has a
custom replacement character defined (see
|:syn-cchar|).
3 Concealed text is completely hidden.
Only one command is needed: set concealcursor=n
I might have a better idea—you can pass it through sed (using %!sed) or really do a bunch of other :substitute commands—whatever edits you need to get rid of the color codes.
When you’re done, make sure to set nomodified—this forces vim to think there haven’t been any changes!
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.
I have a file where I store snippets of vim commands. When I need a snippet, I yank it and then execute it with #". The snippets are stored as a script, one line per command, like this:
:s/foo/bar/g
:echo "hello"
:s/1/2/g
Edit: I removed normal mode commands from the example, as they were not part of the problem.
Now this procedure doesn't work anymore: when executing the snippet, it just stops at the first line as if waiting for a newline.
Is there an option somewhere affecting how # is executed? I'm pretty sure it was working some time ago...
Substituting the newline with a ^M character works but makes the file more difficult to handle.
Additional information:
Here's another symptom: when I yank a snippet, if I execute it with #" it stops at the first line as I just explained. But if I execute it with :# it works. But the help file doesn't seem to imply any difference in how the two commands treat the register's content...
I don't think the problem is ^M vs. ^J. Vim macros will treat either one as a valid end-of-line character for recorded macros. I think the problem is extra newlines.
In your example, there's at least one spurious newline after 2j, and unless you're particularly careful when copying the snippet, there's probably another one after 10k as well. These extra newlines are like pressing <Enter> in Normal mode -- they move the cursor down one line.
Here's what I think you want the snippet to look like:
:s/foo/bar/g
2j:s/1/2/g
10k
(Even that's a little misleading -- you'd still have to be careful not to copy the newline after the 10k.)
Why do these extra newlines make such a big difference? Well, for one thing, they cause you to be at least one line away from where you expect to be, which throws off anything you want to do on a particular line (like execute the :s// command).
More importantly, however -- and this is what I think is happening in your example -- is that Vim stops macro playback if the macro attempts to use <Enter> on the last line of a buffer. (I'm guessing Vim considers it an error, and any error causes a macro to stop running.)
Here's an example. Suppose you've got this snippet stored in register x:
4j
:echo "Done"
(Notice the newline after 4j.)
Furthermore, suppose you have the following five lines (and only these five lines) in a buffer:
line 1
line 2
line 3
line 4
line 5
If you now press #x on line 1, the :echo "Done" never executes. Vim moves the cursor down 4 lines to line 5, then attempts to move down one more line because of the extra newline, but it can't. The macro stops executing at that point, before the :echo command gets a chance to run.
However, it works if you change the x register to this:
4j:echo "Done"
So to return to your original example, I'll bet what's happening is that the extra newline after 2j is attempting to move your cursor somewhere it can't go, and that causes the macro to stop. The bottom line of the screen contains the last command executed (:s/foo/bar/g), which makes it look like Vim is waiting for you to press Return.
Finally, I'd strongly recommend using another method to store and execute Vim command sequences. The technique you're using is tolerable for simple cases, but it's fragile and doesn't scale well. Vim has a full scripting language that includes functions and custom commands, and it can be used to do all the things you're doing now, but in a much more robust fashion. Vim scripting is a big topic, but I'd start here:
:help script
Be sure to read about the :normal command, which lets you execute Normal-mode commands (like 2j and 10k) within scripts.
Good luck!
I finally found the culprit. Somehow I had a command mapping on <C-J> in my .vimrc file. When read with the default cpoptions, this turned into a mapping on <NL>.
How I found out: I noticed that when starting vim with -u ~/.vimrc, it would indeed execute yanked snippets. I generated a session file with and without that commandline option and compared them. This way I found out that a different set of cpoptions where used to read the same .vimrc file, so that in one case the mapping was indeed on <C-J>, in the other it was converted into a mapping on <NL>!
If someone has a similar problem, I suggest to look carefully at the currently set command mappings, with :cmap.