I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of file,
position 1:
1. Down. instead of going to line 2,
On 8/27/07, Yakov Lerner [EMAIL PROTECTED] wrote:
I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87
,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of
Tony Mechelynck wrote:
Frodak Baksik wrote:
On 8/24/07, Tony Mechelynck [EMAIL PROTECTED] wrote:
Sorry if you see this twice: after more than 3 hours I'm not seeing it (nor
any reply to it) on the group.
Frodak Baksik wrote:
[...]
These types of issues have been discussed before on the
Yakov Lerner wrote:
I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of
file, position 1:
1. Down.
I have the following function and binding:
noremap silent g: Esc:set operatorfunc=SIDget_command_mode_rangeCRg@
function! s:get_command_mode_range(type)
let b = line('[)
let e = line('])
if b e
let range = '.,+' . (e - b)
elseif b == e
let range = '.'
else
let range =
I've asked Bram in the past whether he would add this to the voting
list. The best I've been able to get is I'll think about it :) Perhaps
if I throw the idea out to the mailing lists I can garner a little support.
When editing or viewing text files that contain data with fields separated
by
Yakov Lerner wrote:
I get weird up/down behaviour when cursor traverses the braces. vim 7.1.87,
no custom plugins. This is apparently somehow related to matchparen.
The testfile is x.c below.
Here is what happens if I press down starting from the beginning of file,
position 1:
1.
On 26/08/07, krischik [EMAIL PROTECTED] wrote:
My proposal (if you have not guessed already) is to merge more
separate plug ins into modes. What do you think about the idea?
While I do not maintain any vim plugins, this suggestion makes
sense to me.
Richard
.dll gurus,
Latest response from Jan Dubois of ActiveState:
On Fri, 24 Aug 2007, Suresh Govindachar wrote:
Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib
(which does have the symbols in it) in the command that creates
if_perl.o and/or in the command that builds
On 8/27/07, Bram Moolenaar [EMAIL PROTECTED] wrote:
Nikolai Weibull wrote:
So it seems that there's something strange going on in what line is
being set for the ] mark when performing a search under these
conditions, coupled with patterns that match at the very beginning of
a line.
Earlier, I asked the dll gurus,
Latest response from Jan Dubois of ActiveState:
On Fri, 24 Aug 2007, Suresh Govindachar wrote:
Sisyphus suggested linking with C:/opt/perl/lib/CORE/perl58.lib
(which does have the symbols in it) in the command that creates
if_perl.o and/or in
Solved with help from Brian Dessent on the MinGW mailing list.
Add -lperl58 at the very end (location matters) of the last command.
--Suresh
--~--~-~--~~~---~--~~
You received this message from the vim_dev maillist.
For more information, visit
cc: Sven Verdoolaege -- where are you?
Jan Dubois of ActiveState points out an issue with if_perl.xs:
Jan Dubois wrote:
On Mon, 27 Aug 2007, Suresh Govindachar wrote:
So ActiveState is exporting Perl_sv_2iv_flags and
Perl_newXS_flags in a way that is different from the
way
Suresh Govindachar wrote:
Solved with help from Brian Dessent on the MinGW mailing list.
Add -lperl58 at the very end (location matters) of the last command.
--Suresh
This is understandable by assuming that the linker processes each object file
or library once, in the order
14 matches
Mail list logo
