I've noticed on occasion that that using * to search for the word under the cursor occasionally will have slightly different behavior (usually when I'm switching between various computers). The issue is when I perform a search for a word that has a * in front of it (like a c++ pointer). For example:
MyPointer *foo;
...
foo = new MyPointer();
When I move the cursor over the first occurrence of "foo", it usually does a search for that exact word (e.g. /\<foo\>), but sometimes it will include the * character in its search (e.g. /\<*foo\>) which causes it to fail to find any other occurrences of that variable since it's including the * character.
Does anyone know what causes this behavior and/or how to control it?
The behavior is affected by the isk(iskeyword) option.
It may different when you switch to a different buffer.
You can type :help 'isk' to read more.
Related
for the need of a script I'm currently writing, I'm trying to get in the fastest way possible the line number of the start/end of the current paragraph.
At first I was using line("'{") and line("'}"), but this actually is not working in this use case:
1. this is a
2. paragraph
3.
4.
5. this is another paragraph
6. that is below the first one
Indeed, when cursor is on line 4, line("'{") returns 1, and line("'}") returns 6, when I'd want it to be something like either 1/2 or 5/6
I am reluctant to make the cursor move in order to get the wanted results, as those operations will be executed every time the user changes paragraph and moving cursor around is a bit slow.
If anyone knows a way to consistently get the lines numbers of the current paragraph start and end, I'd be glad to hear it!
Hope my question was clear enough!
The definition of paragraphs is mostly based on empty lines, though :help paragraph also mentions some (rather obscure and inherited from vi) nroff macros that can define paragraphs.
If you don't care about the obscure parts, and just base your definition on empty lines, you can use a :while loop together with empty(getline(lnum)) to check for empty lines and thereby detect paragraphs yourself. This explicit iteration completely avoids cursor moves, but could be slow if there are very large paragraphs (spanning hundreds of lines).
Your current approach only breaks down if the cursor currently is between paragraphs. You could explicitly check for that (again ignoring the obscure parts), and only then perform a jump, e.g. via normal! {.
The easiest (and only one that's fully correct also for the obscure parts) implementation always jumps around. Inside a :function, screen updates only happen on demand (via :redraw). You need to save and restore the current view, so that the user doesn't notice:
let l:save_view = winsaveview()
" Code that jumps around here.
call winrestview(l:save_view)
If you prefix your motions with :noautocmd (or temporarily set :help 'eventignore'), you can avoid that plugin actions (which can be far more costly than Vim's internal cursor moves) are triggered (on the CursorMoved event).
Summary
There are several options; which one is right for you, depends on your typical data and use cases.
In vim (in Insert mode, after running exuberant ctags), I am using ctrl-x followed by ctrl-] to bring up a dropdown of various possible words/tokens. It's a great feature.
The problem is that by default, this list starts with a bunch of numeric options and automatically inserts the first numeric option, and if I backspace to get rid of the numbers and start typing a part of a word fresh -- with the idea of searching from the middle of the word -- the autocompletion behavior exits entirely.
I know I could type the first letter of the word that I want, then go from there. But that assumes that I know the first letter of the word, which is not necessarily a given.
For example, if I'm working on a pair-programming project with a friend during a long weekend, I might not remember at any given moment whether he called his method promoteRecordStatus(), updateRecordStatus() or boostRecordStatus(). In this example, I would like to type RecordStatus and get the relevant result, which does not seem to be possible at a glance with the current behavior.
So with that scenario in mind: Is there a simple, vim-native way to tell the editor to start its autocompletion without any assumptions, then search all available tokens for my typed string in all parts of each token?
I will of course consider plugin suggestions helpful, but I would prefer a short, vim-native answer that doesn't require any plugins if possible. Ideally, the configuration could be set using just a line or two.
The built-in completions all require a match at the starting position. In some cases, you could drop separator characters from the 'iskeyword' option (e.g. in Vimscript, drop # to be able to complete individual components from foo#bar#BazFunction()), but this won't work for camelCaseWords at all.
Custom :help complete-functions can implement any completion search, though. To be based on the tags database, it would have to use taglist() as a source, and filter according to the completion base entered before triggering the completion. If you do not anchor this pattern match at the beginning, you have your desired completion.
Imagine you need to change a few last letters in a word.
From
.. visualizing a graph?_
(_ denotes where the cursor is, mode:normal)
you need to arrive at
.. visualize| a graph?
(| denotes the cursor, mode:insert)
How would you do this?
(please suggest how would you really do this, not the "super-doper" way nobody uses)
I am asking, because I do this insanely inefficiently:
type b until reach _visualizing a graph?,
followed by e (visualizinG a graph?),
followed by x to remove g under cursor,
followed by few Shift+x to remove what is before the cursor,
and, finally, i switch into the insert mode and type e.
With given example, I would do:
Tzcwe
If there are just a few words between the cursor and where I want to go, I will use CTRL+left as many times as needed plus CTRL+right once and <bs> 3 times. I may also use the mouse. It's not that different from what you use, except I don't leave the insert mode for simple moves. Note this is exactly what I use when I type messages in my browser (I've never been conquered by vimperator & co).
I'm aware of <esc>gegege...3<left>cwe<esc>. But that's definitively not my first choice.
I may use T and F on symbols with few occurrences, but I seldom use them on letters as I'll spend more time detecting the best character to use than using CTRL+cursor as many times as needed. Beside, when I'm correcting what I've typed, it's likely that my mind is in "reread+correct/refactor sentences" mode, speed typing is not my priority.
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.
In the gVim Search window ("q/"), my screen can fit 100 characters before wrapping the line. (This is apart from the text-wrapping setting in the main editing window.) In building a complex search query (that I would later plug into a command statement) it locks up gVim when I try to run it - which only occurs if the query line wraps within this window. There appears to be nothing in the line I wrote that was out of the ordinary. My first sign that something might be wrong was when I saw gVim's automatically placed pre "/" (before the search query sentence within the Search Window) was added to the wrapped portion of the query line - but, obviously, I am not sure that's the issue.
Has anyone else experienced difficulty in developing long search queries in gVim? I'm running 7.3 (w/patches 1-35) on a Ubuntu Natty system.
I realize I can break this line apart into smaller functions, but I was almost done doing it this way and would be interested in discovering a solution - if there is one.
As a workaround, you can use a regular vim script/buffer to assign search patterns
One 'simple' approach:
open a (new) buffer
type the search pattern as you would in the search window, on a single long line
do the following command to set the searchpattern as into the search register:
:let #/=getline('.')
This has the same effect as pressing enter inside the Search Window, except for the fact that
the cursor won't jump to the first match
the pattern won't be recorded in the search history (effectively avoiding your crash)
There are a number of variation on this basic theme. The essence of which is: assign your search pattern directly into #/