Re: if/else/end broken in netrw.vim
mattn wrote: Typing o in netrw occur error. https://gist.github.com/4583859 Thank you for your patch. The error was still in netrw, although the key is now O rather than o. Please try the copy of netrw available from my website: http://www.drchip.org/astronaut/vim/index.html#NETRW . Regards, C Campbell -- You received this message from the "vim_dev" 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
Re: redraw on insert/visual mode leave
On Jan 21, 2013, at 7:24 AM, Christian Brabandt wrote: > On Thu, January 17, 2013 21:09, Josh wrote: >> Sorry for bumping an old thread, but with the help of some clever folk, >> I've found out how to reproduce the issue: >> >> 1) Use terminal vim, NOT macvim >> 2) Run vim with `vim --noplugin -u NONE` >> 3) Everything works as desired, yay! >> 3) Run `:set notimeout nottimeout` >> 4) Select some text and hit >> 5) Now you need to hit another key for a redraw >> >> I've found that setting `timeoutlen=1` is a good workaround, but this is >> still a bug, right? Thanks for taking a look again! > > Well don't do it then ;) > > After setting timeout to off and hitting ESC Vim is still waiting for > you to press another key (and hasn't left visual mode yet, so there > is no reason to trigger a redraw yet). > > Setting timout to off, means Vim needs to wait after hitting > to see, which other key is pressed to know whether you really have hit > the key or just another key like the Cursor key (which > internally is just a mapped sequence). > > regards, > Christian > > -- > You received this message from the "vim_dev" 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 Ahh, thanks for the explanation. I think I get it now. I just need to figure out what I'm losing now if I get rid of the timeout with `ttimeoutlen=0` or something :). Docs'll help me w/that; Thanks again! Josh -- You received this message from the "vim_dev" 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
Re: [PATCH] Make pyeval() print stack traces (unless :silence’d)
ZyX wrote: > Wondering what’s the status of this patch? I don’t see it in > most recent todo.txt. > > It would be very fine to include as debugging code that uses > `pyeval()' is hard without it (did not create before because for my > projects using `vim.bindeval' seems to be easier). It's in the todo list, at line 102 currently. -- You got to work at a mill? Lucky! I got sent back to work in the acid-mines for my daily crust of stale bread... which not even the birds would eat. /// Bram Moolenaar -- b...@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_dev" 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
Re: [patch] improved equivalent classes in regular expressions
Christian Brabandt wrote:
> Hi Dominique!
>
> On Mi, 16 Jan 2013, Dominique Pellé wrote:
>
>> When using equivalent class [[=x=]], I realized that what I
>> generally want, is to use it on the full strings rather than on
>> a single characters. Searching for "foobar" with...
>>
>> /[[=f=]][[=o=]][[=o=]][[=b=]][[=a=]][[=r=]]
>>
>> ... works but is rather unpleasant. I wish there was a flag
>> such as \q switch on equivalent class, which would
>> work like \c for case insensitivity. So instead of the above
>> regexp, I could search for:
>>
>> /\qfoobar
>>
>> As far as I know \q is unused in Vim regexp, so
>> that should not break compatibility.
>>
>> Maybe there could also be a function normalize({expr}}
>> (any better name?) that given a string with diacritics
>> "fňóbâr" returns "foobar" in similar way to tolower({expr}})
>> which returns a lowercase version of the string.
>>
>> Before I spend time trying to do that, would it be useful
>> and accepted?
>
> Indeed, that looks like a useful addition.
I have no time now for that unfortunately, but maybe in a few weeks.
> I have another idea with regards to equivalence classes:
> When searching for /[[=ß=]] this should translate into /sz. But that is
> more complicated, since a search for /[s][z] wouldn't match ß (eszet)
> anymore.
You obviously speak better German than me, but isn't the German
ess-zett equivalent to ss rather than sz? I'm curious why /sz.
>> Regarding the few characters that are no longer equivalent,
>> I find it odd from a user point of view. For example U+01e4
>> (LATIN CAPITAL LETTER G WITH STROKE) was equivalent
>> to uppercase G but it is no longer equivalent to G.
>> Yet some other letters with stroke are still equivalent.
>> For example, U+0141 (LATIN CAPITAL LETTER L WITH STROKE)
>> is still equivalent to L. It seems inconsistent, even if that's
>> what the ISO standard says. Previous behavior made more
>> sense to me for U+1e4 at least.
>
> Fixed with the latest patch.
Yes, I saw that. Thanks!
--
You received this message from the "vim_dev" 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
Re: [patch] improved equivalent classes in regular expressions
Hi Dominique!
On Mi, 16 Jan 2013, Dominique Pellé wrote:
> When using equivalent class [[=x=]], I realized that what I
> generally want, is to use it on the full strings rather than on
> a single characters. Searching for "foobar" with...
>
> /[[=f=]][[=o=]][[=o=]][[=b=]][[=a=]][[=r=]]
>
> ... works but is rather unpleasant. I wish there was a flag
> such as \q switch on equivalent class, which would
> work like \c for case insensitivity. So instead of the above
> regexp, I could search for:
>
> /\qfoobar
>
> As far as I know \q is unused in Vim regexp, so
> that should not break compatibility.
>
> Maybe there could also be a function normalize({expr}}
> (any better name?) that given a string with diacritics
> "fňóbâr" returns "foobar" in similar way to tolower({expr}})
> which returns a lowercase version of the string.
>
> Before I spend time trying to do that, would it be useful
> and accepted?
Indeed, that looks like a useful addition.
I have another idea with regards to equivalence classes:
When searching for /[[=ß=]] this should translate into /sz. But that is
more complicated, since a search for /[s][z] wouldn't match ß (eszet)
anymore.
> Regarding the few characters that are no longer equivalent,
> I find it odd from a user point of view. For example U+01e4
> (LATIN CAPITAL LETTER G WITH STROKE) was equivalent
> to uppercase G but it is no longer equivalent to G.
> Yet some other letters with stroke are still equivalent.
> For example, U+0141 (LATIN CAPITAL LETTER L WITH STROKE)
> is still equivalent to L. It seems inconsistent, even if that's
> what the ISO standard says. Previous behavior made more
> sense to me for U+1e4 at least.
Fixed with the latest patch.
Mit freundlichen Grüßen
Christian
--
Alkoholismus: Gift und Gegengift sind identisch.
-- Gerhard Uhlenbruck
--
You received this message from the "vim_dev" 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
[PATCH] exploring 10,000 files with netrw
Hi small patch for exploring 10,000 files with netrw. I confirmed it works correctly on ubuntu 12.04 and win XP. [benchmark] OS:ubuntu 12.04, CPU: Core(TM)2 Duo CPU E6850. This directory has 10,000 files. I do the benchmark with next command in vim. :profile start before_patch.txt ^@ profile func * ^@ Explore ^@ quit Befor patch: 78.18 ( s ) After patch: 3.67 ( s ) In winXP, my patch works correctly. But unfortunately I felt elapsed time not much different. Best regards Hideo Doi -- You received this message from the "vim_dev" 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 netrw_10kfiles.patch Description: Binary data
Re: redraw on insert/visual mode leave
On Thu, January 17, 2013 21:09, Josh wrote: > Sorry for bumping an old thread, but with the help of some clever folk, > I've found out how to reproduce the issue: > > 1) Use terminal vim, NOT macvim > 2) Run vim with `vim --noplugin -u NONE` > 3) Everything works as desired, yay! > 3) Run `:set notimeout nottimeout` > 4) Select some text and hit > 5) Now you need to hit another key for a redraw > > I've found that setting `timeoutlen=1` is a good workaround, but this is > still a bug, right? Thanks for taking a look again! Well don't do it then ;) After setting timeout to off and hitting ESC Vim is still waiting for you to press another key (and hasn't left visual mode yet, so there is no reason to trigger a redraw yet). Setting timout to off, means Vim needs to wait after hitting to see, which other key is pressed to know whether you really have hit the key or just another key like the Cursor key (which internally is just a mapped sequence). regards, Christian -- You received this message from the "vim_dev" 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
