Monday, March 31, 2014

Re: "local hlsearch"



On Monday, March 31, 2014, <meino.cramer@gmx.de> wrote:
Hi,

I often use a search'n'replace on an area, which is
limited by a previously selected visual block.
Additional hlsearch is on by default.
After the searech'n'replace has ended, the found
places are marked all over the whole text.
This is often irritating to me.
Is there a way to limit the highlights set by hlsearch
to those place of the visual block area?

Thank you very much fo rnay help in advance!
Best regards,
mcc

This doesn't answer your question exactly, but that bothers me too so I've set a very simple map to quickly disable the hlsearch setting.  The map is as follows:
 
 map <leader>h set nohlsearch
 
 So, after a search and replace or after searching to find a bit of code I can quickly disable the highlighting that is no longer useful. 
 
Hopefully someone else in the list will be better able to answer your question specifically, but I hope my 'solution' is helpful until then.  
 
 Cheers,
 
Ethan Alan  
 

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
Ethan Alan

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

"local hlsearch"

Hi,

I often use a search'n'replace on an area, which is
limited by a previously selected visual block.
Additional hlsearch is on by default.
After the searech'n'replace has ended, the found
places are marked all over the whole text.
This is often irritating to me.
Is there a way to limit the highlights set by hlsearch
to those place of the visual block area?

Thank you very much fo rnay help in advance!
Best regards,
mcc



--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

command line not visible when using "-p" or first tabnew with -geom

OK, I've googled my fingers off trying to find this. When I start gvim with -p, or do :tabnew in a gvim with only a single buffer, the "command line" (or whatever its called - the place where searches and commands show up) isn't visible unless I resize the window. This only happens if I use the -geom option.

This happens on multiple machines (linux and cygwin), and multiple vim versions, up to and including 7.4.

How do I fix this? My wrapper script calculates an appropriate geometry for that display and file type and uses -geom to set it. So I'd hate to give up -geom.

Thanks,
Paul Zimmer

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

Likewise, thanks!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Sunday, March 30, 2014

Re: Vim Spreadsheets

On 30.03.14,15:10, glphvgacs wrote:
> On Sun, Mar 30, 2014 at 08:43:51PM +0200, Jostein Berntsen wrote:
> > On 30.03.14,17:24, piemas25 wrote:
> > > I don't manage to install msharov's version of sc, maybe because my OS is
> > > 64bits.
> > >
> > > But I'm not sure that this version does Undo of actions. The u command in
> > > msharov's version is like in the original sc: it does Undo when you are in
> > > Input mode. It can undo changes on some text that you are writting, but I
> > > don't think it can undo spreadsheet actions, like deleting a column.
> > >
> > > Unfortunately I couldn't find a sc mailing list. The community seems pretty
> > > small.
> > >
> >
> > I have the same problem installing this version of sc. Gets this output:
> >
> > o/vmtbl.o: In function `growtbl':
> > vmtbl.c:(.text.growtbl+0x24): undefined reference to `LINES'
> > vmtbl.c:(.text.growtbl+0x56): undefined reference to `COLS'
> > vmtbl.c:(.text.growtbl+0x2bf): undefined reference to `stdscr'
> > vmtbl.c:(.text.growtbl+0x2cd): undefined reference to `wmove'
> > vmtbl.c:(.text.growtbl+0x2d4): undefined reference to `stdscr'
> > vmtbl.c:(.text.growtbl+0x2d9): undefined reference to `wclrtoeol'
> > vmtbl.c:(.text.growtbl+0x2e5): undefined reference to `printw'
> > collect2: error: ld returned 1 exit status
> > make: *** [sc] Error 1
> >
> >
> > Jostein
>
> well you should file a bug on github, this is really off-topic here.
>

I am on Slackware 64bbit. Will post on github.


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

On Sun, Mar 30, 2014 at 10:27 AM, Bram Moolenaar <Bram@moolenaar.net> wrote:
>
> Justin Keyes wrote:
>
>> On Fri, Mar 28, 2014 at 4:53 PM, Josef Fortier <josef.fortier@gmail.com> wrote:
>> > I've only really actively used diff mode recently (as opposed to using it as a visual diff tool). The default folding update on a change has led me astray more then once.
>> >
>> > I've learned the workaround only today, zo and zc, but the auto-folding behavior seems to me to be a real UI issue. I believe that diff mode should:
>> >
>> > * leave the initial folding alone (it's quite useful)
>> > * leave the change markers in place (this is less important)
>> > * but **not** refold.
>> >
>> > In almost all diff resolution workflows I can imagine, we want to **review** the changes. Auto-folding assumes that we are omniscient and do not need to review.
>>
>> I agree. The initial folding is welcome, but auto-folding after 'do'
>> or 'dp' is jarring. You are talking about do/dp, right?
>
> So then do:
> :set foldmethod=manual
>
> It will keep the current folds.

Thanks Bram! Setting that on both of the diff windows achieves the
desired effect. To do this automatically when entering Vim in
diff-mode, I added this to vimrc:

autocmd VimEnter * if &diff | exe 'windo set foldmethod=manual' | endif

Then, diff-mode initializes with folded text, but 'do' and 'dp' will
not auto-fold.

The Vim wiki[1] implies that &diff is set before vimrc is sourced, but
that isn't the case for me on Mac OS terminal Vim, nor Windows
terminal Vim (invoked via "vim -d a.txt b.txt").

[1] http://vim.wikia.com/wiki/Ignore_white_space_in_vimdiff

Justin M. Keyes

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

On Sun, Mar 30, 2014 at 08:43:51PM +0200, Jostein Berntsen wrote:
> On 30.03.14,17:24, piemas25 wrote:
> > I don't manage to install msharov's version of sc, maybe because my OS is
> > 64bits.
> >
> > But I'm not sure that this version does Undo of actions. The u command in
> > msharov's version is like in the original sc: it does Undo when you are in
> > Input mode. It can undo changes on some text that you are writting, but I
> > don't think it can undo spreadsheet actions, like deleting a column.
> >
> > Unfortunately I couldn't find a sc mailing list. The community seems pretty
> > small.
> >
>
> I have the same problem installing this version of sc. Gets this output:
>
> o/vmtbl.o: In function `growtbl':
> vmtbl.c:(.text.growtbl+0x24): undefined reference to `LINES'
> vmtbl.c:(.text.growtbl+0x56): undefined reference to `COLS'
> vmtbl.c:(.text.growtbl+0x2bf): undefined reference to `stdscr'
> vmtbl.c:(.text.growtbl+0x2cd): undefined reference to `wmove'
> vmtbl.c:(.text.growtbl+0x2d4): undefined reference to `stdscr'
> vmtbl.c:(.text.growtbl+0x2d9): undefined reference to `wclrtoeol'
> vmtbl.c:(.text.growtbl+0x2e5): undefined reference to `printw'
> collect2: error: ld returned 1 exit status
> make: *** [sc] Error 1
>
>
> Jostein

well you should file a bug on github, this is really off-topic here.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

On Sun, Mar 30, 2014 at 08:43:51PM +0200, Jostein Berntsen wrote:
> On 30.03.14,17:24, piemas25 wrote:
> > I don't manage to install msharov's version of sc, maybe because my OS is
> > 64bits.
> >
> > But I'm not sure that this version does Undo of actions. The u command in
> > msharov's version is like in the original sc: it does Undo when you are in
> > Input mode. It can undo changes on some text that you are writting, but I
> > don't think it can undo spreadsheet actions, like deleting a column.
> >
> > Unfortunately I couldn't find a sc mailing list. The community seems pretty
> > small.
> >
>
> I have the same problem installing this version of sc. Gets this output:
>
> o/vmtbl.o: In function `growtbl':
> vmtbl.c:(.text.growtbl+0x24): undefined reference to `LINES'
> vmtbl.c:(.text.growtbl+0x56): undefined reference to `COLS'
> vmtbl.c:(.text.growtbl+0x2bf): undefined reference to `stdscr'
> vmtbl.c:(.text.growtbl+0x2cd): undefined reference to `wmove'
> vmtbl.c:(.text.growtbl+0x2d4): undefined reference to `stdscr'
> vmtbl.c:(.text.growtbl+0x2d9): undefined reference to `wclrtoeol'
> vmtbl.c:(.text.growtbl+0x2e5): undefined reference to `printw'
> collect2: error: ld returned 1 exit status
> make: *** [sc] Error 1
>
>
> Jostein

what's your system?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

On 30.03.14,17:24, piemas25 wrote:
> I don't manage to install msharov's version of sc, maybe because my OS is
> 64bits.
>
> But I'm not sure that this version does Undo of actions. The u command in
> msharov's version is like in the original sc: it does Undo when you are in
> Input mode. It can undo changes on some text that you are writting, but I
> don't think it can undo spreadsheet actions, like deleting a column.
>
> Unfortunately I couldn't find a sc mailing list. The community seems pretty
> small.
>

I have the same problem installing this version of sc. Gets this output:

o/vmtbl.o: In function `growtbl':
vmtbl.c:(.text.growtbl+0x24): undefined reference to `LINES'
vmtbl.c:(.text.growtbl+0x56): undefined reference to `COLS'
vmtbl.c:(.text.growtbl+0x2bf): undefined reference to `stdscr'
vmtbl.c:(.text.growtbl+0x2cd): undefined reference to `wmove'
vmtbl.c:(.text.growtbl+0x2d4): undefined reference to `stdscr'
vmtbl.c:(.text.growtbl+0x2d9): undefined reference to `wclrtoeol'
vmtbl.c:(.text.growtbl+0x2e5): undefined reference to `printw'
collect2: error: ld returned 1 exit status
make: *** [sc] Error 1


Jostein


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

I don't manage to install msharov's version of sc, maybe because my OS is 64bits.

But I'm not sure that this version does Undo of actions. The u command in msharov's version is like in the original sc: it does Undo when you are in Input mode. It can undo changes on some text that you are writting, but I don't think it can undo spreadsheet actions, like deleting a column.

Unfortunately I couldn't find a sc mailing list. The community seems pretty small.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

On Sun, Mar 30, 2014 at 02:59:06PM +0100, piemas25 wrote:
> Hi all, I think I've realized something important.
>
> But first, two questions:
> - is there no way to "Undo" my last actions in sc?

msharov's does, don't know about the original one.
https://github.com/msharov/sc/blob/master/help.c#L141

> - is there a way to perform actions in "visual mode", like in Vim?

not at this moment, see these bugs for feature request:

https://github.com/msharov/sc/issues/2
https://github.com/msharov/sc/issues/3

> 3. A spreadsheet tells a story.
> It stores data, lets you act on it, and it displays it all on one screen in
> order to tell a story. It could be the story of your finances, or it could
> be statistics that help you make a decision. But it's main strength is to
> display the information in a readable format, and let you change parameters
> and see how that changes the story.

i would say have a look at R and gnuplot if you want to abstract out
details and get the big picture if you like. (there might be better
plotting tools for R out there, i just don't know them well).

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

Justin Keyes wrote:

> On Fri, Mar 28, 2014 at 4:53 PM, Josef Fortier <josef.fortier@gmail.com> wrote:
> > I've only really actively used diff mode recently (as opposed to using it as a visual diff tool). The default folding update on a change has led me astray more then once.
> >
> > I've learned the workaround only today, zo and zc, but the auto-folding behavior seems to me to be a real UI issue. I believe that diff mode should:
> >
> > * leave the initial folding alone (it's quite useful)
> > * leave the change markers in place (this is less important)
> > * but **not** refold.
> >
> > In almost all diff resolution workflows I can imagine, we want to **review** the changes. Auto-folding assumes that we are omniscient and do not need to review.
>
> I agree. The initial folding is welcome, but auto-folding after 'do'
> or 'dp' is jarring. You are talking about do/dp, right?

So then do:
:set foldmethod=manual

It will keep the current folds.


--
Never enter the boss's office unless it's absolutely necessary. Every boss
saves one corner of the desk for useless assignments that are doled out like
Halloween candy to each visitor.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Vim Spreadsheets

Hi all, I think I've realized something important.

But first, two questions: 
 - is there no way to "Undo" my last actions in sc?
 - is there a way to perform actions in "visual mode", like in Vim?
I have read the whole manual and done two tutorial. I have printed the man page but it is very long, so i haven't read it all yet. sc deserves a more thorough tutorial.


This week I tried CSV.vim and sc, and I replaced one of my most complex spreadsheets by an app. Here is what i learned, and I think it's important.

1. A Database is meant to store data, and describe the relationship between data. A CSV file is a database in a human-readable format, so you can easily navigate it, and even do some changes. That is exactly what CSV.vim helps you do:
    - sort the data according to any given column
    - search for a value in one given column
    - filter the data (eg: "only show rows that contain "haha" in column 5, and "houhou" in column 7")
    - analyse the data (probability distribution on one column)
    - do substitutions in one column
    - etc
Very handy stuff but it doesn't replace a spreadsheet, it's very different. 

2. An App lets you perform actions on the data (which is stored in a database). It describes possible interactions between different piece of data, and lets you extract, process and display some information. It's the most flexible kind of tool, it can do pretty much anything.

3. A spreadsheet tells a story.
It stores data, lets you act on it, and it displays it all on one screen in order to tell a story. It could be the story of your finances, or it could be statistics that help you make a decision. But it's main strength is to display the information in a readable format, and let you change parameters and see how that changes the story.

sc really gives you that. You can: 
    - format cells or columns: you can color them, choose specific formats for numbers, put the text on the left/center/right, etc.
    - use formulas in cells to tell the story of the relashionship between data
    - name a cell or a range, so you can easily refer to it in another cell (that is proper story telling, that is!)
    - lock some cells in order for someone less experienced to change the parameters of the story without damaging it => you can share your story with anyone and let them play with it !

A spreadsheet can do less things than an app though, it is less good for expressing complex relashionships between complex sets of data, and it doesn't have access to the same external services (webservices, programming libraries, etc). 
But sc is smart! It enables you to easily plug some cells with external commands, so it can use any app out there. Awesome! The app does all the hard work, and in the end the spreadsheet tells the story in a readable format, and lets people play with it by tweaking some parameters.

Until now I has used spreadsheets for all of the above. Recently i've realised that some of my spreadsheets should better become apps with a database and a command line interface. And now I also know that I could use a spreadsheet to manipulate some of my apps, and display the results in an easy to manipulate manner. I don't  always need a full fledged HTML+Javascript frontend, sometimes an sc frontend is good enough.

How does this sound?

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Saturday, March 29, 2014

Re: how can I configure word highlighting in VIM ?

On Sun, Mar 30, 2014 at 11:56:50AM +0530, Arup Rakshit wrote:
> I found this feature, long back in Notepad++. In that editor, if you select
> any word, it will highlight all occurrence of that word. It sometime helps
> to verify if at the line# 100 any variable I am using, it will confirm, if
> that was defined previously or not.

you did not respond to John's question: you know about "*"?, and your
re-query implies you don't

if you navigate to the word you want highlighted, press * , that word
will be searched for, and by virtue of its now being in the @/ register,
all occurrences of that word will now by default be highlighted, and you
can re-search with n and N

--
_|_ _ __|_|_ ._ o|
|_(_)(_)|_| ||_)||<
|

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: how can I configure word highlighting in VIM ?

I found this feature, long back in Notepad++. In that editor, if you select any word, it will highlight all occurrence of that word. It sometime helps to verify if at the line# 100 any variable I am using, it will confirm, if that was defined previously or not.


On Sun, Mar 30, 2014 at 8:12 AM, John Beckett <johnb.beckett@gmail.com> wrote:
Arup Rakshit wrote:
> Subject: how can I configure word highlighting in VIM ?

If you mean by searching, I suggest starting here:

http://vim.wikia.com/wiki/Searching

See what it says (you know about "*"?), and scan down to the
"Highlighting search matches" link near the bottom. There are
also some search-without-moving ideas there somewhere.

To just highlight, see:

http://vim.wikia.com/wiki/Highlight_multiple_words

John


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/hXcGlddeUbM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
*---------------------------------------------------------------*
*Warm Regards,*

*Arup Rakshit*
*Software Engineer*



--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

RE: how can I configure word highlighting in VIM ?

Arup Rakshit wrote:
> Subject: how can I configure word highlighting in VIM ?

If you mean by searching, I suggest starting here:

http://vim.wikia.com/wiki/Searching

See what it says (you know about "*"?), and scan down to the
"Highlighting search matches" link near the bottom. There are
also some search-without-moving ideas there somewhere.

To just highlight, see:

http://vim.wikia.com/wiki/Highlight_multiple_words

John


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

@Justin: You are talking about do/dp, right?

Yep!

I'm motivated by using fugitive for partial commits. I've been burned a few times, so I really want to be careful. The auto-folding makes it harder to confirm. zo and zc are better then what I was doing (pretty much what was suggested, but using zi instead to open all the folds).

I've thought a bit about this, and I've come up with a partial workaround for my secondary request, keeping the markings around. Basically I've built a small compiler script to:

* makeprg runs git diff -U1 (or the equivalent diff command)
* errorformat parses out the file and line number.

The line number is "wrong" in that it's the prior line, but it's pretty close. I can do a quickfix list prior to resolution and use the QF list afterwards to verify the changes.

FWIW, I've become totally fascinated by QF in the last few week. For many years I've seen as something only for C programmers, but it's really **far** more useful, a generalized marking service, a little like ctags, but for almost anything. I've written a TAP compiler script, and found a compiler script to save and load arbitrary QF and LL lists. Other ideas, using QF to find and mark TODO's, or Documentation blocks. It seems much more generally useful and powerful then I'd understood.

To that end, I wish the errorformat parsing wasn't so arcane. My biggest current concern is that %s auto anchors. If it was more generalized, then the integration possibilities are much greater (example, grammar checkers). I realize that the suggested fix is "use an external sed/awk script" but that seems a fragile kludge.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

how can I configure word highlighting in VIM ?

Hi,

I use vim to write my Ruby code. Say, I wrote a code as below :

foo = 2
def meth(arg)
puts arg
end

meth(foo)

Now suppose, I defined **foo** in the line#4. Now I am calling the method with **foo** as an argument, from line #20. Now suppose I am selecting the word, **foo** using command **viw**. Now I want all `foo` to be highlighted. If this can be done, it would help me in lots of scenarios.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

On Fri, Mar 28, 2014 at 4:53 PM, Josef Fortier <josef.fortier@gmail.com> wrote:
> I've only really actively used diff mode recently (as opposed to using it as a visual diff tool). The default folding update on a change has led me astray more then once.
>
> I've learned the workaround only today, zo and zc, but the auto-folding behavior seems to me to be a real UI issue. I believe that diff mode should:
>
> * leave the initial folding alone (it's quite useful)
> * leave the change markers in place (this is less important)
> * but **not** refold.
>
> In almost all diff resolution workflows I can imagine, we want to **review** the changes. Auto-folding assumes that we are omniscient and do not need to review.

I agree. The initial folding is welcome, but auto-folding after 'do'
or 'dp' is jarring. You are talking about do/dp, right?

Justin M. Keyes

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

On 22:38 Fri 28 Mar , Chris Jones wrote:
> On Fri, Mar 28, 2014 at 08:51:48PM EDT, Marcin Szamotulski wrote:
>
> > You can easily open all folds with zr.
>
> Or zR..if you have several levels of folding.. ?
>
> CJ

In the diff mode you don't :)

Regards,
Marcin

Friday, March 28, 2014

Re: Suggestion for vim -diff behavior change

On Fri, Mar 28, 2014 at 08:51:48PM EDT, Marcin Szamotulski wrote:

> You can easily open all folds with zr.

Or zR..if you have several levels of folding.. ?

CJ

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Suggestion for vim -diff behavior change

On 13:53 Fri 28 Mar , Josef Fortier wrote:
> I've only really actively used diff mode recently (as opposed to using it as a visual diff tool). The default folding update on a change has led me astray more then once.
>
> I've learned the workaround only today, zo and zc, but the auto-folding behavior seems to me to be a real UI issue. I believe that diff mode should:
>
> * leave the initial folding alone (it's quite useful)
> * leave the change markers in place (this is less important)
> * but **not** refold.
>
> In almost all diff resolution workflows I can imagine, we want to **review** the changes. Auto-folding assumes that we are omniscient and do not need to review.
>
> With the change marker keys, ]c , [c , folding is less important. I can navigate to a change set, so an ocean of text on the screen is less important. I suppose if there is a **massive** diffset (in which case vim-diff may not be the best choice) then the auto-folding behavior might be the correct behavior. But for almost all the scenarios I've been using diff-mode, the initial folding is as noise free as it needs to be.
>
> Keeping the change markers around also seems nice, as it facilitates review. Cycle through the changes with ]c and verify.
>
> Is there a way to change this behavior? Does it seem doable in vimscript?
>
> Anyways, it seems worth discussing. I'd like to hear any alternate views/approaches.
>

Hi,

You can easily open all folds with zr. If you want to have a wider
context you can:
set diffopt+=context:1000

and you should not see folding, though it is not the solution you ask
for since it removes the existing folding.

Best regards,
Marcin

Re: On the new netrw v151 update

Nice!
I know you regularly work on bugfixes, but it's also nice to see new features being developed!

On Friday, March 28, 2014 8:07:22 PM UTC+1, Charles Campbell wrote:
> Hello!
>
>
>
> Netrw v151 has been made available via Mercurial and from my website:
>
> http://www.drchip.org/astronaut/vim/index.html#NETRW. It has several
>
> new features and extensions, as well as bugfixes:
>
>
>
> :Rexplore was originally intended to allow one to pick a file via netrw,
>
> edit it, and then return to the netrw buffer.
>
> Extension: it now supports returning from the netrw buffer to
>
> the file one was previously editing in that window.
>
> Think of it as "return from" or "return to", as appropriate.
>
>
>
> Windows shares: David Kotchan provided some script which allows netrw to
>
> work properly with windows shares
>
>
>
> :Lexplore [path] opens a netrw browser to the far left; a 2nd :Lexplore
>
> command will make the netrw browser go away. (ie. its something of a toggle)
>
> Variables that you may want to use with it:
>
> g:netrw_liststyle (=0 is default thin listing, =1 is long
>
> listing, =2 is wide listing, and =3 is tree style)
>
> g:netrw_winsize (=-# means # columns, =# means #% of window)
>
>
>
> [shift-<cr>] + treemode + gvim : may be used to "squeeze" (ie. close)
>
> the directory currently containing the cursor in tree mode
>
>
>
> :MF expr : will mark-file files matching the glob-style pattern
>
> specified in the expr (ex. :MF *.c) in the current open netrw browser
>
>
>
> :Ntree [dirname] : specify a new tree top for tree listing style
>
>
>
> Regards,
>
> Chip Campbell

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Suggestion for vim -diff behavior change

I've only really actively used diff mode recently (as opposed to using it as a visual diff tool). The default folding update on a change has led me astray more then once.

I've learned the workaround only today, zo and zc, but the auto-folding behavior seems to me to be a real UI issue. I believe that diff mode should:

* leave the initial folding alone (it's quite useful)
* leave the change markers in place (this is less important)
* but **not** refold.

In almost all diff resolution workflows I can imagine, we want to **review** the changes. Auto-folding assumes that we are omniscient and do not need to review.

With the change marker keys, ]c , [c , folding is less important. I can navigate to a change set, so an ocean of text on the screen is less important. I suppose if there is a **massive** diffset (in which case vim-diff may not be the best choice) then the auto-folding behavior might be the correct behavior. But for almost all the scenarios I've been using diff-mode, the initial folding is as noise free as it needs to be.

Keeping the change markers around also seems nice, as it facilitates review. Cycle through the changes with ]c and verify.

Is there a way to change this behavior? Does it seem doable in vimscript?

Anyways, it seems worth discussing. I'd like to hear any alternate views/approaches.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

what to install to compile MacVim with +X11 support?

on linux I would install packages like gtk2-dev and stuff, but I'm not sure what I gotta install on Mac 10.9.2 to get the headers or whatever it needs for +X11

anyone know?!

thanks!

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

On the new netrw v151 update

Hello!

Netrw v151 has been made available via Mercurial and from my website:
http://www.drchip.org/astronaut/vim/index.html#NETRW. It has several
new features and extensions, as well as bugfixes:

:Rexplore was originally intended to allow one to pick a file via netrw,
edit it, and then return to the netrw buffer.
Extension: it now supports returning from the netrw buffer to
the file one was previously editing in that window.
Think of it as "return from" or "return to", as appropriate.

Windows shares: David Kotchan provided some script which allows netrw to
work properly with windows shares

:Lexplore [path] opens a netrw browser to the far left; a 2nd :Lexplore
command will make the netrw browser go away. (ie. its something of a toggle)
Variables that you may want to use with it:
g:netrw_liststyle (=0 is default thin listing, =1 is long
listing, =2 is wide listing, and =3 is tree style)
g:netrw_winsize (=-# means # columns, =# means #% of window)

[shift-<cr>] + treemode + gvim : may be used to "squeeze" (ie. close)
the directory currently containing the cursor in tree mode

:MF expr : will mark-file files matching the glob-style pattern
specified in the expr (ex. :MF *.c) in the current open netrw browser

:Ntree [dirname] : specify a new tree top for tree listing style

Regards,
Chip Campbell

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: expand tab when copying into x

On 2014-03-28 07:29, shawn wilson wrote:
> Generally when I copy something with hard tabs (a makefile right
> now) into X ("+y) I actually want soft tabs even if I don't have
> expandtab set for the file. But, if I paste into a console (IRC for
> instance) it tries to do an autocomplete. Is there a way to expand
> tabs for just this type of copy? Ie, I wouldn't want this
> functionality for yanks into other buffers.

You could write a mapping that expands tabs on the clipboard buffer,
something like

:nnoremap <f4> :let @+=substitute(@+,'\t',repeat(' ', &ts),'g')<cr>

So you'd copy your tabified text to the clipboard, then hit <f4> and
it would be re-copied to the clipboard with the tabs expanded.

-tim




--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

expand tab when copying into x

Generally when I copy something with hard tabs (a makefile right now)
into X ("+y) I actually want soft tabs even if I don't have expandtab
set for the file. But, if I paste into a console (IRC for instance) it
tries to do an autocomplete. Is there a way to expand tabs for just
this type of copy? Ie, I wouldn't want this functionality for yanks
into other buffers.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Thursday, March 27, 2014

Re: Extremely slow when using relativenumber & syntax highlighting


On Mar 27, 2014 7:56 PM, "Christian Brabandt" <cblists@256bit.org> wrote:
>
> [copying Zyx, as he is the maintainer of the syntax script]
>
> Am 2014-03-27 00:05, schrieb Dominique Pellé:
>>
>> I can reproduce the slowness using the yaml file copied
>> from http://yaml.org
>
> [...]
>
>>
>> If I use ":syntime on" and ":syntime report", I see this:
>>
>> With relativenumber:
>>
>>   TOTAL      COUNT  MATCH   SLOWEST     AVERAGE   NAME               PATTERN
>>   3.706423   7752   7395    0.002521    0.000478  yamlPlainScalar
>> \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
>> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
>>   1.105733   4029   2040    0.000742    0.000274  yamlFloat
>> \%([\[\]{},
>> \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
>>   0.711836   1224   0       0.001174    0.000582  yamlBlockMappingKey
>> \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
>> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
>>
>>   0.481088   2703   153     0.000815    0.000178  yamlInteger
>> \%([\[\]{},
>> \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
>>   0.044233   2601   0       0.000042    0.000017  yamlTimestamp
>> \%([\[\]{},
>> \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
>>   0.038902   2652   408     0.000056    0.000015  yamlBlockMappingKey
>> \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
>> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
>
>
> Those patterns are crazy. Here is a patch, that deviates the performance issue slightly
> (mainly by making sure, the old 're' engine is used in place of those high performance syntax
> items and by limiting the look-around assertion). This fixes the performance penalties
> even more but might make syntax highlighting more inaccurate (although I used a conservative
> limit of 100 bytes).

If I understand these limits correctly it can be limited to an exact amount of bytes: AFAIR I was using only fixed-width lookarounds (making these limits be possible to be deduced by re engine). At least this patch touches only fixed-width lookarounds. Though I may understand these limits not correctly.

>
> Also, I noticed, the syntax script is missing some :syn sync rules. I am not sure, what the default
> is, but some clever syn rules could also improve syntax performance slightly.
>
> Best,
> Christian

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extremely slow when using relativenumber & syntax highlighting

diff --git a/runtime/syntax/yaml.vim b/runtime/syntax/yaml.vim
--- a/runtime/syntax/yaml.vim
+++ b/runtime/syntax/yaml.vim
@@ -11,11 +11,11 @@ endif
let s:cpo_save = &cpo
set cpo&vim

-let s:ns_char = '\%(\%([\n\r\uFEFF \t]\)\@!\p\)'
+let s:ns_char = '\%(\%([\n\r\uFEFF \t]\)\@100!\p\)'
let s:ns_word_char = '\%(\w\|-\)'
let s:ns_uri_char = '\%(%\x\x\|'.s:ns_word_char.'\|[#/;?:@&=+$,.!~*''()\[\]]\)'
let s:ns_tag_char = '\%(%\x\x\|'.s:ns_word_char.'\|[#/;?:@&=+$.~*''()]\)'
-let s:c_ns_anchor_char = '\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)'
+let s:c_ns_anchor_char = '\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@100!\p\)'
let s:c_indicator = '[\-?:,\[\]{}#&*!|>''"%@`]'
let s:c_flow_indicator = '[,\[\]{}]'

@@ -44,16 +44,18 @@ let s:ns_tag_prefix = s:ns_local_tag_pre
\ '\|'.s:ns_global_tag_prefix

let s:ns_plain_safe_out = s:ns_char
-let s:ns_plain_safe_in = '\%('.s:c_flow_indicator.'\@!'.s:ns_char.'\)'
+let s:ns_plain_safe_in = '\%('.s:c_flow_indicator.'\@100!'.s:ns_char.'\)'

-let s:ns_plain_first_in = '\%('.s:c_indicator.'\@!'.s:ns_char.'\|[?:\-]\%('.s:ns_plain_safe_in.'\)\@=\)'
-let s:ns_plain_first_out = '\%('.s:c_indicator.'\@!'.s:ns_char.'\|[?:\-]\%('.s:ns_plain_safe_out.'\)\@=\)'
+let s:ns_plain_first_in = '\%('.s:c_indicator.'\@100!'.s:ns_char.'\|[?:\-]\%('.s:ns_plain_safe_in.'\)\@100=\)'
+let s:ns_plain_first_out = '\%('.s:c_indicator.'\@100!'.s:ns_char.'\|[?:\-]\%('.s:ns_plain_safe_out.'\)\@100=\)'

-let s:ns_plain_char_in = '\%('.s:ns_char.'#\|:'.s:ns_plain_safe_in.'\|[:#]\@!'.s:ns_plain_safe_in.'\)'
-let s:ns_plain_char_out = '\%('.s:ns_char.'#\|:'.s:ns_plain_safe_out.'\|[:#]\@!'.s:ns_plain_safe_out.'\)'
+let s:ns_plain_char_in = '\%('.s:ns_char.'#\|:'.s:ns_plain_safe_in.'\|[:#]\@100!'.s:ns_plain_safe_in.'\)'
+let s:ns_plain_char_out = '\%('.s:ns_char.'#\|:'.s:ns_plain_safe_out.'\|[:#]\@100!'.s:ns_plain_safe_out.'\)'

-let s:ns_plain_out = s:ns_plain_first_out . s:ns_plain_char_out.'*'
-let s:ns_plain_in = s:ns_plain_first_in . s:ns_plain_char_in.'*'
+" Use old RE engine, to speed up syntax highlighting some, the new engine has
+" problems with look-around assertions
+let s:ns_plain_out = '\%#=1'. s:ns_plain_first_out . s:ns_plain_char_out.'*'
+let s:ns_plain_in = '\%#=1'. s:ns_plain_first_in . s:ns_plain_char_in.'*'


syn keyword yamlTodo contained TODO FIXME XXX NOTE
@@ -76,7 +78,7 @@ syn match yamlYAMLDirective '%YAML\s\+'
syn match yamlYAMLVersion '\d\+\.\d\+' contained nextgroup=yamlComment

execute 'syn match yamlReservedDirective contained nextgroup=yamlComment '.
- \string('%\%(\%(TAG\|YAML\)\s\)\@!'.s:ns_directive_name)
+ \string('%\%(\%(TAG\|YAML\)\s\)\@100!'.s:ns_directive_name)

syn region yamlFlowString matchgroup=yamlFlowStringDelimiter start='"' skip='\\"' end='"'
\ contains=yamlEscape
@@ -123,10 +125,10 @@ syn keyword yamlConstant true True TRUE
syn keyword yamlConstant null Null NULL
syn match yamlConstant '\<\~\>'

-syn match yamlTimestamp /\%([\[\]{}, \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(\d*\)\)\=\%(\s*\%(Z\|[+-]\d\d\=\%(:\d\d\)\=\)\)\=\)\=\)\%([\[\]{}, \t]\@!\p\)\@!/
+syn match yamlTimestamp /\%#=1\%([\[\]{}, \t]\@100!\p\)\@100<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(\d*\)\)\=\%(\s*\%(Z\|[+-]\d\d\=\%(:\d\d\)\=\)\)\=\)\=\)\%([\[\]{}, \t]\@100!\p\)\@100!/

-syn match yamlInteger /\%([\[\]{}, \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-5]\=\d\)\+\)\)\|[1-9][0-9_]*\)\%([\[\]{}, \t]\@!\p\)\@!/
-syn match yamlFloat /\%([\[\]{}, \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-9]\+\)\=\|\d[0-9_]*\%(:[0-5]\=\d\)\+\.[0-9_]*\|\.\%(inf\|Inf\|INF\)\)\|\%(\.\%(nan\|NaN\|NAN\)\)\)\%([\[\]{}, \t]\@!\p\)\@!/
+syn match yamlInteger /\%#=1\%([\[\]{}, \t]\@100!\p\)\@100<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-5]\=\d\)\+\)\)\|[1-9][0-9_]*\)\%([\[\]{}, \t]\@100!\p\)\@100!/
+syn match yamlFloat /\%#=1\%([\[\]{}, \t]\@100!\p\)\@100<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-9]\+\)\=\|\d[0-9_]*\%(:[0-5]\=\d\)\+\.[0-9_]*\|\.\%(inf\|Inf\|INF\)\)\|\%(\.\%(nan\|NaN\|NAN\)\)\)\%([\[\]{}, \t]\@100!\p\)\@100!/

execute 'syn match yamlNodeTag '.string(s:c_ns_tag_property)
execute 'syn match yamlAnchor '.string(s:c_ns_anchor_property)
[copying Zyx, as he is the maintainer of the syntax script]
Am 2014-03-27 00:05, schrieb Dominique Pellé:
> I can reproduce the slowness using the yaml file copied
> from http://yaml.org
[...]
>
> If I use ":syntime on" and ":syntime report", I see this:
>
> With relativenumber:
>
> TOTAL COUNT MATCH SLOWEST AVERAGE NAME
> PATTERN
> 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar
> \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
> 1.105733 4029 2040 0.000742 0.000274 yamlFloat
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
> 0.711836 1224 0 0.001174 0.000582 yamlBlockMappingKey
> \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
>
> 0.481088 2703 153 0.000815 0.000178 yamlInteger
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
> 0.044233 2601 0 0.000042 0.000017 yamlTimestamp
> \%([\[\]{},
> \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
> 0.038902 2652 408 0.000056 0.000015 yamlBlockMappingKey
> \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)

Those patterns are crazy. Here is a patch, that deviates the performance
issue slightly
(mainly by making sure, the old 're' engine is used in place of those
high performance syntax
items and by limiting the look-around assertion). This fixes the
performance penalties
even more but might make syntax highlighting more inaccurate (although I
used a conservative
limit of 100 bytes).

Also, I noticed, the syntax script is missing some :syn sync rules. I am
not sure, what the default
is, but some clever syn rules could also improve syntax performance
slightly.

Best,
Christian

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Poll: What's good about plugin managers?


On Mar 27, 2014 7:31 PM, "Marc Weber" <marco-oweber@gmx.de> wrote:
>
> Excerpts from Nikolay Pavlov's message of Tue Mar 25 20:32:13 +0000 2014:
> > With VAM you can ask to update specific plugin only. Action "update all
> > plugins for which there is a newer version available" is exactly what VAM
> > does if you disallow using VCS sources (otherwise it may switch source
> > types without notice (or with, I do not actually remember)) (updating VCS
> > sources which were installed manually still works fine).
> To be honest I don't know either. We haven't defined behaviour.
> VAM should
> - run git pull if a plugin directory happens to be a git repository
> - hg update if its contains a .hg directory
> and so on.
>
> Thus if you turn a .git into a .hg repository :VamUpdate plugin-name
> should do what you want.

I meant changing non-VCS to VCS, not between VCS. I know that VCS types won't be switched.

>
> But you're right that one final goal could be a to support fixed
> versions & update sources. The perfect "user experience" would be
> "choose yourself" which is why the last update I made was that
> important: It allows passing dictionaries instead of plugin names.
>
> Thus Activate(['plugin-name']) can be replaced by
> Activate([{'name': 'plugin-name', 'force-change-branch-on-update': 1 'force-hash': 'xxx345'}])
>
> The force-* keys are not supported yet, but are trivial to add and document.
> Thus user would have full control.
>
> I think its more important to collaborate on the declaration than on the
> implementation. And I even failed on a "InstallPlugin" proposal.
>
> Thus somebody has to step up and just "win the race" - which doesn't
> make sense now that neobundle exists unless waiting how that turns out
> to be ... (my view).
>
> Marc Weber
>
> --
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups "vim_use" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Poll: What's good about plugin managers?

Excerpts from Nikolay Pavlov's message of Tue Mar 25 20:32:13 +0000 2014:
> With VAM you can ask to update specific plugin only. Action "update all
> plugins for which there is a newer version available" is exactly what VAM
> does if you disallow using VCS sources (otherwise it may switch source
> types without notice (or with, I do not actually remember)) (updating VCS
> sources which were installed manually still works fine).
To be honest I don't know either. We haven't defined behaviour.
VAM should
- run git pull if a plugin directory happens to be a git repository
- hg update if its contains a .hg directory
and so on.

Thus if you turn a .git into a .hg repository :VamUpdate plugin-name
should do what you want.

But you're right that one final goal could be a to support fixed
versions & update sources. The perfect "user experience" would be
"choose yourself" which is why the last update I made was that
important: It allows passing dictionaries instead of plugin names.

Thus Activate(['plugin-name']) can be replaced by
Activate([{'name': 'plugin-name', 'force-change-branch-on-update': 1 'force-hash': 'xxx345'}])

The force-* keys are not supported yet, but are trivial to add and document.
Thus user would have full control.

I think its more important to collaborate on the declaration than on the
implementation. And I even failed on a "InstallPlugin" proposal.

Thus somebody has to step up and just "win the race" - which doesn't
make sense now that neobundle exists unless waiting how that turns out
to be ... (my view).

Marc Weber

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Poll: What's good about plugin managers?

Excerpts from Steve Litt's message of Tue Mar 25 21:40:51 +0000 2014:
> The VimOutliner project is basing their next installer on Pathogen, so
> as a VimOutliner user, I'd love to see greater Vim support for Pathogen.
Why can't we collect those "requirements" and allow plugin managers to
implement them?

Can you ellaborate which feature is being used by VimOutliner ?

Marc Weber

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extremely slow when using relativenumber & syntax highlighting

On Thursday, March 27, 2014 7:13:06 AM UTC-4, Bram Moolenaar wrote:
> Dominique Pelle wrote:
>
>
>
> > patrick hemmer wrote:
>
> >
>
> > > Whenever I have relative line number on (relativenumber), and
>
> > > syntax highlighting enabled (syntax on), moving the cursor is
>
> > > painfully slow. Not only moving between lines, but just moving
>
> > > the cursor left/right on the same line.
>
> > >
>
> > > I've tried removing my local .vim & .vimrc files as well as the
>
> > > ones in /etc to have a completely default config. As soon as
>
> > > I `syntax on` and `set rnu`, it starts exhibiting the issue.
>
> > >
>
> > > It doesn't seem to do this on all files though, just most. As a
>
> > > reliable way to duplicate the issue, I can copy the http://yaml.org
>
> > > web page content into a .yaml file, and edit that.
>
> > > But I get it in multiple languages, perl, yaml, ruby, & other.
>
> > >
>
> > > Version 7.4 with patches 1-193 (though I've had this behavior for
>
> > > years with older versions).
>
> >
>
> > I can reproduce the slowness using the yaml file copied
>
> > from http://yaml.org
>
> >
>
> > Here are some timings with and without relativenumber
>
> > when moving 50 times horizontally with l and h:
>
> >
>
> > $ time vim -u NONE foo.yaml \
>
> > -c 'set relativenumber' \
>
> > -c 'syntax on' +10 \
>
> > -c 'call feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
>
> > real 0m4.677s
>
> > user 0m1.447s
>
> > sys 0m3.226s
>
> > --> slow!
>
> >
>
> > $ time vim -u NONE foo.yaml \
>
> > -c 'set norelativenumber' \
>
> > -c 'syntax on' +10 \
>
> > -c 'call feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
>
> > real 0m0.166s
>
> > user 0m0.086s
>
> > sys 0m0.077s
>
> > --> fast
>
> >
>
> > If I use ":syntime on" and ":syntime report", I see this:
>
> >
>
> > With relativenumber:
>
> >
>
> > TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
>
> > 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar
>
>
>
> [...]
>
>
>
> >
>
> > Without relative number:
>
> >
>
> > TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
>
> > 0.071678 152 145 0.001796 0.000472 yamlPlainScalar
>
>
>
> [...]
>
>
>
> > So somehow regexp are being checked far more often
>
> > when relativenumber is on, which does not seem right
>
> > considering that the command mostly moves horizontally.
>
> >
>
> > Using callgrind, I see that:
>
> > * with 'norelativenumber', update_screen() was called only once
>
> > * with 'relativenumber', update_screen() was called 51 times
>
> >
>
> > Notice that the command I used was moving:
>
> > - 50 times horizontally with h and l
>
> > - 1 time vertically using +10
>
> >
>
> > This means that with relativenumber, update_screen() gets
>
> > called each time we move horizontally with h or l which does
>
> > not seem needed at first sight.
>
> >
>
> > The code that seems responsible for the spurious redraw is:
>
> > move.c:1190 (commenting that line as a experiment makes it fast)
>
> > so the logic to decide whether to redraw is wrong but I can't see
>
> > how to fix it:
>
> >
>
> > 1175 /* Redraw when w_row changes and 'relativenumber' is set */
>
> > 1176 if (((curwin->w_valid & VALID_WROW) == 0 && (curwin->w_p_rnu
>
> > 1177 #ifdef FEAT_SYN_HL
>
> > 1178 /* or when w_row changes and 'cursorline' is set. */
>
> > 1179 || curwin->w_p_cul
>
> > 1180

Re: Extremely slow when using relativenumber & syntax highlighting

Dominique Pelle wrote:

> patrick hemmer wrote:
>
> > Whenever I have relative line number on (relativenumber), and
> > syntax highlighting enabled (syntax on), moving the cursor is
> > painfully slow. Not only moving between lines, but just moving
> > the cursor left/right on the same line.
> >
> > I've tried removing my local .vim & .vimrc files as well as the
> > ones in /etc to have a completely default config. As soon as
> > I `syntax on` and `set rnu`, it starts exhibiting the issue.
> >
> > It doesn't seem to do this on all files though, just most. As a
> > reliable way to duplicate the issue, I can copy the http://yaml.org
> > web page content into a .yaml file, and edit that.
> > But I get it in multiple languages, perl, yaml, ruby, & other.
> >
> > Version 7.4 with patches 1-193 (though I've had this behavior for
> > years with older versions).
>
> I can reproduce the slowness using the yaml file copied
> from http://yaml.org
>
> Here are some timings with and without relativenumber
> when moving 50 times horizontally with l and h:
>
> $ time vim -u NONE foo.yaml \
> -c 'set relativenumber' \
> -c 'syntax on' +10 \
> -c 'call feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
> real 0m4.677s
> user 0m1.447s
> sys 0m3.226s
> --> slow!
>
> $ time vim -u NONE foo.yaml \
> -c 'set norelativenumber' \
> -c 'syntax on' +10 \
> -c 'call feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
> real 0m0.166s
> user 0m0.086s
> sys 0m0.077s
> --> fast
>
> If I use ":syntime on" and ":syntime report", I see this:
>
> With relativenumber:
>
> TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
> 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar

[...]

>
> Without relative number:
>
> TOTAL COUNT MATCH SLOWEST AVERAGE NAME PATTERN
> 0.071678 152 145 0.001796 0.000472 yamlPlainScalar

[...]

> So somehow regexp are being checked far more often
> when relativenumber is on, which does not seem right
> considering that the command mostly moves horizontally.
>
> Using callgrind, I see that:
> * with 'norelativenumber', update_screen() was called only once
> * with 'relativenumber', update_screen() was called 51 times
>
> Notice that the command I used was moving:
> - 50 times horizontally with h and l
> - 1 time vertically using +10
>
> This means that with relativenumber, update_screen() gets
> called each time we move horizontally with h or l which does
> not seem needed at first sight.
>
> The code that seems responsible for the spurious redraw is:
> move.c:1190 (commenting that line as a experiment makes it fast)
> so the logic to decide whether to redraw is wrong but I can't see
> how to fix it:
>
> 1175 /* Redraw when w_row changes and 'relativenumber' is set */
> 1176 if (((curwin->w_valid & VALID_WROW) == 0 && (curwin->w_p_rnu
> 1177 #ifdef FEAT_SYN_HL
> 1178 /* or when w_row changes and 'cursorline' is set. */
> 1179 || curwin->w_p_cul
> 1180

Re: Extremely slow when using relativenumber & syntax highlighting

Christian Brabandt wrote:

> You might have found a bug here. I think the original idea is, that
> whenever 'relativenumber'
> is set, one needs to update more often, since the relativenumbers change
> whenever you move
> the cursor up and down. This does obviously not happen here and I think
> this is caused
> by curwin->w_valid incorrectly being made invalid.
>
> I don't see why VALID_WROW should be made invalid, just because the
> column changed. So I remove it in the following
> patch and after testing with your commandline given above Vim indeed
> seems to be much faster (but please
> everybody test to confirm).
>
> diff --git a/src/move.c b/src/move.c
> --- a/src/move.c
> +++ b/src/move.c
> @@ -467,7 +467,7 @@ check_cursor_moved(wp)
>

Re: Extremely slow when using relativenumber & syntax highlighting

Il giorno mercoledì 26 marzo 2014 22:52:59 UTC+1, patrick...@gmail.com ha scritto:

>
> I can't see how the terminal emulator would have an effect. It's just changing a few characters on the screen, shouldn't be hard. Plus it doesn't always do it, only on some files. I'm not using an anti-aliased font either. And as mentioned, it occurs in gvim as well.

I just tried to be helpful. I regularly use vim under tmux on a fairly large screen, so I played a bit with various terminals / fonts / config just to try to squeeze as much speed as possibile, and indeed I noticed some differencies. I have to say they were all but huge, but in any case I've never seen vim so slow to be "painful" (except maybe in the first releases of vim 7.4 when the new re engine was a bit buggy).

anyway, just to talk, IIRC "just chainging a few character on the screen" may not be so easy for some terminals. different terminals have different capabilities. I think under some term if you want to scroll you have to redraw everything... but anyway, I never really studied this argument so I may be very wrong :)

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to copy to vim runtime directories ?

Hi Christian,

Yes, you are correct. I will raise it there or create a pull request for the same.


On Thu, Mar 27, 2014 at 1:11 PM, Christian Brabandt <cblists@256bit.org> wrote:
Please, as the signature that is appended at each message, states trim quotes and answer
below to what you are refering to. This is general list consensus here, since top
quoting style is hard to read and usually bad style.

Am 2014-03-26 22:57, schrieb Arup Rakshit:


Will it be a valid issue post then ? If so then I will do definitely.. I am very new in this area..

You should open an issue, if from the project description it is unclear how to "activate" that
plugin. It's not like this is an issue that would be hard to fix for the author and clear
documentation is essential for any project.

Best,
Christian


--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- You received this message because you are subscribed to a topic in the Google Groups "vim_use" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/vim_use/FRNWmhT02-g/unsubscribe.
To unsubscribe from this group and all its topics, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.



--
*---------------------------------------------------------------*
*Warm Regards,*

*Arup Rakshit*
*Software Engineer*



--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: How to copy to vim runtime directories ?

Please, as the signature that is appended at each message, states trim
quotes and answer
below to what you are refering to. This is general list consensus here,
since top
quoting style is hard to read and usually bad style.

Am 2014-03-26 22:57, schrieb Arup Rakshit:

> Will it be a valid issue post then ? If so then I will do definitely..
> I am very new in this area..

You should open an issue, if from the project description it is unclear
how to "activate" that
plugin. It's not like this is an issue that would be hard to fix for the
author and clear
documentation is essential for any project.

Best,
Christian

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extremely slow when using relativenumber & syntax highlighting

[fullquote, since copying vim-dev]
Am 2014-03-27 00:05, schrieb Dominique Pellé:
> patrick hemmer wrote:
>
>> Whenever I have relative line number on (relativenumber), and
>> syntax highlighting enabled (syntax on), moving the cursor is
>> painfully slow. Not only moving between lines, but just moving
>> the cursor left/right on the same line.
>>
>> I've tried removing my local .vim & .vimrc files as well as the
>> ones in /etc to have a completely default config. As soon as
>> I `syntax on` and `set rnu`, it starts exhibiting the issue.
>>
>> It doesn't seem to do this on all files though, just most. As a
>> reliable way to duplicate the issue, I can copy the http://yaml.org
>> web page content into a .yaml file, and edit that.
>> But I get it in multiple languages, perl, yaml, ruby, & other.
>>
>> Version 7.4 with patches 1-193 (though I've had this behavior for
>> years with older versions).
>
>
> I can reproduce the slowness using the yaml file copied
> from http://yaml.org
>
> Here are some timings with and without relativenumber
> when moving 50 times horizontally with l and h:
>
> $ time vim -u NONE foo.yaml \
> -c 'set relativenumber' \
> -c 'syntax on' +10 \
> -c 'call
> feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
> real 0m4.677s
> user 0m1.447s
> sys 0m3.226s
> --> slow!
>
> $ time vim -u NONE foo.yaml \
> -c 'set norelativenumber' \
> -c 'syntax on' +10 \
> -c 'call
> feedkeys("llllllllllhhhhhhhhhhllllllllllhhhhhhhhhhllllllllll:q\<CR>")'
> real 0m0.166s
> user 0m0.086s
> sys 0m0.077s
> --> fast
>
> If I use ":syntime on" and ":syntime report", I see this:
>
> With relativenumber:
>
> TOTAL COUNT MATCH SLOWEST AVERAGE NAME
> PATTERN
> 3.706423 7752 7395 0.002521 0.000478 yamlPlainScalar
> \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
> 1.105733 4029 2040 0.000742 0.000274 yamlFloat
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
> 0.711836 1224 0 0.001174 0.000582 yamlBlockMappingKey
> \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
>
> 0.481088 2703 153 0.000815 0.000178 yamlInteger
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
> 0.044233 2601 0 0.000042 0.000017 yamlTimestamp
> \%([\[\]{},
> \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
> 0.038902 2652 408 0.000056 0.000015 yamlBlockMappingKey
> \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
>
> 0.023793 3825 2448 0.000029 0.000006 yamlComment
> \%\(^\|\s\)#
> 0.007552 3825 1224 0.000009 0.000002
> yamlBlockCollectionItemStart ^\s*\zs-\%(\s\+-\)*\s
> 0.006340 2601 0 0.000009 0.000002
> yamlBlockMappingMerge ^\s*\zs<<\ze:\%(\s\|$\)
> 0.004530 1224 1224 0.000008 0.000004 yamlComment $
> 0.003572 2601 0 0.000008 0.000001 yamlDocumentEnd
> ^\.\.\.\ze\%(\s\|$\)
> 0.002253 2601 0 0.000003 0.000001 yamlFlowCollection \[
> 0.002248 2601 51 0.000031 0.000001 yamlDirective
> ^\ze%\%(\%([\n\r\uFEFF \t]\)\@!\p\)\+\s\+
> 0.002189 2601 51 0.000004 0.000001 yamlDocumentStart
> ^---\ze\%(\s\|$\)
> 0.001827 2601 0 0.000025 0.000001 yamlConstant
> \<\~\>
> 0.001594 2601 0 0.000019 0.000001 yamlMappingKeyStart
> ?\ze\s
> 0.001468 2703 255 0.000002 0.000001 yamlFlowString "
> 0.001446 2652 51 0.000002 0.000001 yamlFlowString '
> 0.001407 2601 0 0.000013 0.000001 yamlAlias
> \*\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
> 0.001404 2601 0 0.000002 0.000001 yamlFlowMapping {
> 0.001372 2601 0 0.000002 0.000001 yamlAnchor
> &\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
> 0.001313 2601 0 0.000002 0.000001 yamlNodeTag
> !<\%(%\x\x\|\%(\w\|-\)\|[#/;?:@&=+$,.!~*''()\[\]]\)\+>\|\%(!\%(\w\|-\)\+!\|!!\|!\)\%(%\x\x\|\%(\w\|-\)\|[#
> 0.000839 1224 0 0.000002 0.000001
> yamlBlockMappingMerge <<\ze\s*:\%(\s\|$\)
> 0.000823 408 408 0.000005 0.000002 yamlKeyValueDelimiter
> \s*:
> 0.000506 408 408 0.000003 0.000001 yamlKeyValueDelimiter
> \s*:
> 0.000503 51 0 0.000011 0.000010
> yamlReservedDirective %\%(\%(TAG\|YAML\)\s\)\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\+
> 0.000147 51 51 0.000004 0.000003 yamlYAMLVersion
> \d\+\.\d\+
> 0.000128 51 51 0.000003 0.000003 yamlYAMLDirective
> %YAML\s\+
> 0.000121 51 51 0.000003 0.000002 yamlDirective $
> 0.000078 51 0 0.000002 0.000002 yamlTAGDirective
> %TAG\s\+
> 0.000062 102 102 0.000001 0.000001 yamlFlowString "
> 0.000052 102 0 0.000001 0.000001 yamlFlowString
> \\"
> 0.000028 51 0 0.000001 0.000001 yamlEscape
> \\\%([\\"abefnrtv\^0_ NLP\n]\|x\x\x\|u\x\{4}\|U\x\{8}\)
>
> 6.155810 66351
>
>
> Without relative number:
>
> TOTAL COUNT MATCH SLOWEST AVERAGE NAME
> PATTERN
> 0.071678 152 145 0.001796 0.000472 yamlPlainScalar
> \%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\@!\p\)\)\@=
> 0.021474 79 40 0.000679 0.000272 yamlFloat
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(\%(\d[0-9_]*\)\.[0-9_]*\%([eE][+-]\d\+\)\=\|\.[0-9_]\+\%([eE][-+][0-
> 0.013851 24 0 0.001121 0.000577 yamlBlockMappingKey
> \%#=1\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)\
>
> 0.009354 53 3 0.000627 0.000176 yamlInteger
> \%([\[\]{},
> \t]\@!\p\)\@<!\%([+-]\=\%(0\%(b[0-1_]\+\|[0-7_]\+\|x[0-9a-fA-F_]\+\)\=\|\%([1-9][0-9_]*\%(:[0-
> 0.000884 51 0 0.000029 0.000017 yamlTimestamp
> \%([\[\]{},
> \t]\@!\p\)\@<!\%(\d\{4}-\d\d\=-\d\d\=\%(\%([Tt]\|\s\+\)\%(\d\d\=\):\%(\d\d\):\%(\d\d\)\%(\.\%(
> 0.000778 52 8 0.000055 0.000015 yamlBlockMappingKey
> \%#=1^\s*\zs\%([\-?:,\[\]{}#&*!|>'"%@`]\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\|[?:\-]\%(\%(\%([\n\r\uFEFF \t]\)
>
> 0.000469 75 48 0.000024 0.000006 yamlComment
> \%\(^\|\s\)#
> 0.000150 75 24 0.000014 0.000002
> yamlBlockCollectionItemStart ^\s*\zs-\%(\s\+-\)*\s
> 0.000115 51 0 0.000004 0.000002
> yamlBlockMappingMerge ^\s*\zs<<\ze:\%(\s\|$\)
> 0.000088 24 24 0.000005 0.000004 yamlComment $
> 0.000074 51 0 0.000004 0.000001 yamlDocumentEnd
> ^\.\.\.\ze\%(\s\|$\)
> 0.000046 51 1 0.000021 0.000001 yamlDirective
> ^\ze%\%(\%([\n\r\uFEFF \t]\)\@!\p\)\+\s\+
> 0.000044 51 0 0.000001 0.000001 yamlFlowCollection \[
> 0.000043 51 1 0.000004 0.000001 yamlDocumentStart
> ^---\ze\%(\s\|$\)
> 0.000036 51 0 0.000001 0.000001 yamlConstant
> \<\~\>
> 0.000032 52 1 0.000001 0.000001 yamlFlowString '
> 0.000032 51 0 0.000001 0.000001 yamlFlowMapping {
> 0.000032 51 0 0.000002 0.000001 yamlMappingKeyStart
> ?\ze\s
> 0.000032 51 0 0.000001 0.000001 yamlAnchor
> &\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
> 0.000032 51 0 0.000001 0.000001 yamlAlias
> \*\%(\%([\n\r\uFEFF \t,\[\]{}]\)\@!\p\)\+
> 0.000026 53 5 0.000001 0.000000 yamlFlowString "
> 0.000018 51 0 0.000001 0.000000 yamlNodeTag
> !<\%(%\x\x\|\%(\w\|-\)\|[#/;?:@&=+$,.!~*''()\[\]]\)\+>\|\%(!\%(\w\|-\)\+!\|!!\|!\)\%(%\x\x\|\%(\w\|-\)\|[#
> 0.000017 24 0 0.000001 0.000001
> yamlBlockMappingMerge <<\ze\s*:\%(\s\|$\)
> 0.000017 8 8 0.000003 0.000002 yamlKeyValueDelimiter
> \s*:
> 0.000011 1 0 0.000011 0.000011
> yamlReservedDirective %\%(\%(TAG\|YAML\)\s\)\@!\%(\%([\n\r\uFEFF
> \t]\)\@!\p\)\+
> 0.000009 8 8 0.000002 0.000001 yamlKeyValueDelimiter
> \s*:
> 0.000003 1 1 0.000003 0.000003 yamlDirective $
> 0.000003 1 1 0.000003 0.000003 yamlYAMLVersion
> \d\+\.\d\+
> 0.000002 1 1 0.000002 0.000002 yamlYAMLDirective
> %YAML\s\+
> 0.000002 2 0 0.000001 0.000001 yamlFlowString
> \\"
> 0.000001 1 0 0.000001 0.000001 yamlTAGDirective
> %TAG\s\+
> 0.000000 2 2 0.000000 0.000000 yamlFlowString "
> 0.000000 1 0 0.000000 0.000000 yamlEscape
> \\\%([\\"abefnrtv\^0_ NLP\n]\|x\x\x\|u\x\{4}\|U\x\{8}\)
>
> 0.119353 1301
>
> So somehow regexp are being checked far more often
> when relativenumber is on, which does not seem right
> considering that the command mostly moves horizontally.
>
> Using callgrind, I see that:
> * with 'norelativenumber', update_screen() was called only once
> * with 'relativenumber', update_screen() was called 51 times
>
> Notice that the command I used was moving:
> - 50 times horizontally with h and l
> - 1 time vertically using +10
>
> This means that with relativenumber, update_screen() gets
> called each time we move horizontally with h or l which does
> not seem needed at first sight.
>
> The code that seems responsible for the spurious redraw is:
> move.c:1190 (commenting that line as a experiment makes it fast)
> so the logic to decide whether to redraw is wrong but I can't see
> how to fix it:
>
> 1175 /* Redraw when w_row changes and 'relativenumber' is set */
> 1176 if (((curwin->w_valid & VALID_WROW) == 0 && (curwin->w_p_rnu
> 1177 #ifdef FEAT_SYN_HL
> 1178 /* or when w_row changes and 'cursorline' is set. */
> 1179 || curwin->w_p_cul
> 1180