Hi,
I very frequently have to look for a couple of words in a huge
document to find the place where I have to resume work or do
modifications. Unfortunately, the search function stops in a new line,
so that if I look for a very interesting place which was far away
vim will not find it if there is
Pau schrieb am 15.01.2012 um 12:41 (+0100):
How can I tell vim to ignore new lines in the search function?
Given:
very interesting
very
interesting
Try:
/very[ \n]interesting
--
Michael Ludwig
--
You received this message from the vim_use maillist.
Do not top-post! Type your reply below
On 01/15/12 05:41, Pau wrote:
I very frequently have to look for a couple of words in a huge
document to find the place where I have to resume work or do
modifications. Unfortunately, the search function stops in a new line,
so that if I look for a very interesting place which was far away
vim
On 07:48 Sun 15 Jan , Tim Chase wrote:
On 01/15/12 05:41, Pau wrote:
I very frequently have to look for a couple of words in a huge
document to find the place where I have to resume work or do
modifications. Unfortunately, the search function stops in a new line,
so that if I look for
Tim Chase schrieb am 15.01.2012 um 07:48 (-0600):
On 01/15/12 05:41, Pau wrote:
How can I tell vim to ignore new lines in the search function?
I don't think there's anything as easy as a flag, but you can use
\_s to mean a whitespace that includes a newline.
That's better than my
You can use regular expressions to search.
In your case, you replace space character to match new line too. The \_.
modifier match any single character or end-of-line
So, your search will look:
/a\_.very\_.interesting\_.place\_.which\_.was\_.far\_.away
New line can be anywhere (actually, any
Idan Kamara wrote:
Calling update in an autocmd CursorMoved/I doesn't seem to trigger
BufWritePost (or FileWritePost or FileAppendPost).
$ gvim -u NONE /tmp/foo.c
:au CursorMoved *.c silent up
:au CursorMovedI *.c silent up
:au BufWritePost *.c echo 'saved'
When I make changes to
Claus Atzenbeck wrote:
Am 13.01.2012 um 15:46 schrieb Taylor Hedberg:
I'm not sure you can. According to `:help diff-diffexpr`, Vim requires
the output of the diff program to be an ed-style diff, which is
fundamentally linewise. Maybe you could come up with a wrapper script
that would
On 01/15/12 08:03, Bram Moolenaar wrote:
Claus Atzenbeck wrote:
Am 13.01.2012 um 15:46 schrieb Taylor Hedberg:
I'm not sure you can. According to `:help diff-diffexpr`, Vim requires
the output of the diff program to be an ed-style diff, which is
fundamentally linewise. Maybe you could come
On Sun, Jan 15, 2012 at 4:03 PM, Bram Moolenaar b...@moolenaar.net wrote:
Idan Kamara wrote:
Calling update in an autocmd CursorMoved/I doesn't seem to trigger
BufWritePost (or FileWritePost or FileAppendPost).
$ gvim -u NONE /tmp/foo.c
:au CursorMoved *.c silent up
:au
Am 15.01.2012 um 15:44 schrieb Tim Chase:
Fortunately at least with wdiff, there's an option to change the pre/post
markers for the text added/deleted via the --{start,end}-{delete,insert}
command-line flags, so the diff could accommodate a fairly arbitrary syntax.
When I've wanted to see
Dear all,
thanks a lot... but I forgot to mention that one main problem is that
I cannot know in advance where the new line is... isn't there a faster
way of telling vim to ingore new lines?
thanks a lot!
On 15 January 2012 15:00, György Kiss w2lk...@gmail.com wrote:
You can use regular
Hi,
I want to write a foldtext function where the folded block would not
have the standard +- header with variable nr of dashes, but the exact
text appearing before the fold marker (in casu one or more '{' possibly
followed by a digit). Here it is:
function! MyFoldText() show the text before
On 01/15/2012 10:42 AM, Guido Van Hoecke wrote:
Hi,
I want to write a foldtext function where the folded block would not
have the standard +- header with variable nr of dashes, but the exact
text appearing before the fold marker (in casu one or more '{' possibly
followed by a digit). Here it
On 2012-01-15, Pau wrote:
Dear all,
thanks a lot... but I forgot to mention that one main problem is that
I cannot know in advance where the new line is... isn't there a faster
way of telling vim to ingore new lines?
No, but with these mappings, you don't need to know where the
newline is:
On 2012-01-15, AK wrote:
It does work for me but I'm dealing with lines that have
leading spaces and I add leading spaces, here is a relevant
snip:
let l = getline(v:foldstart)
let line = substitute(l, '^[ ]*', '', '')
let prefix = repeat(' ', (strlen(l) - strlen(line)))
On 01/15/2012 01:56 PM, Gary Johnson wrote:
On 2012-01-15, AK wrote:
It does work for me but I'm dealing with lines that have
leading spaces and I add leading spaces, here is a relevant
snip:
let l = getline(v:foldstart)
let line = substitute(l, '^[ ]*', '', '')
let prefix =
On 2012-01-15, AK wrote:
On 01/15/2012 01:56 PM, Gary Johnson wrote:
On 2012-01-15, AK wrote:
It does work for me but I'm dealing with lines that have
leading spaces and I add leading spaces, here is a relevant
snip:
let l = getline(v:foldstart)
let line = substitute(l, '^[
On Sunday, January 15, 2012 10:39:42 AM Pau wrote:
Dear all,
thanks a lot... but I forgot to mention that one main problem is
that I cannot know in advance where the new line is... isn't there
a faster way of telling vim to ingore new lines?
thanks a lot!
Yes.
I don't know how to do it,
On Sun, Jan 15, 2012 at 10:39:42AM EST, Pau wrote:
thanks a lot... but I forgot to mention that one main problem is that
I cannot know in advance where the new line is... isn't there a faster
way of telling vim to ingore new lines?
thanks a lot!
[..]
Per your initial post, I understood
On 01/15/12 13:49, Steve Litt wrote:
On Sunday, January 15, 2012 10:39:42 AM Pau wrote:
thanks a lot... but I forgot to mention that one main
problem is that I cannot know in advance where the new line
is... isn't there a faster way of telling vim to ingore new
lines? thanks a lot!
Yes.
I
If you just load the other files in buffers then the normal word completion
will work exactly as you expect. The other files don't even have to be
visible.
$ vim A B C D
That will start vim with files A, B, C, and D all open in buffers. The
file visible by default will be A. You can switch
Pau wrote:
huge document to find the place where I have to resume work
or do modifications. Unfortunately, the search function stops
in a new line, so that if I look for a very interesting
place which was far away
vim will not find it if there is a new line, i.e. something like this
a very
23 matches
Mail list logo
