Re: Fold-related bug and pointer to fix

2016-12-19 Thread Efraim Yawitz
On Fri, Dec 16, 2016 at 12:58 PM, Christian Brabandt 
wrote:

> Bram,
> attached is a patch, that changes slightly how addresses are being
> calculated when on a folded line and using an relative offset.
>
>
I couldn't manage to run the patch. patch -p0 gave me errors.  What am I
doing 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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-12-16 Thread Bram Moolenaar

Christian Brabandt wrote:

> Bram,
> attached is a patch, that changes slightly how addresses are being 
> calculated when on a folded line and using an relative offset.

Thanks!  I'm afraid the list of patches to include is getting longer,
and I don't have much time, thus it might take a while.

-- 
The difference between theory and practice, is that in theory, there
is no difference between theory and practice.

 /// 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_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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-12-16 Thread Christian Brabandt
Bram,
attached is a patch, that changes slightly how addresses are being 
calculated when on a folded line and using an relative offset.

Best,
Christian
-- 
Mißtrauen ist eine schlechte Rüstung, die mehr hindern als schirmen
kann.
-- George Gordon

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
From efda08039b1b6d4f9941d9888ebd82e2a10b460d Mon Sep 17 00:00:00 2001
From: Christian Brabandt 
Date: Thu, 15 Dec 2016 19:10:47 +0100
Subject: [PATCH] Correct ex range  for folded lines

This will make :.,+3y work as expected for lines that are folded away
e.g. it will adjust the second adress to included the complete fold
(until the end of the folded lines) + 2 separate lines.
---
 src/ex_docmd.c| 28 ++--
 src/testdir/Make_all.mak  |  1 +
 src/testdir/test_fold.vim | 65 +++
 3 files changed, 86 insertions(+), 8 deletions(-)
 create mode 100644 src/testdir/test_fold.vim

diff --git a/src/ex_docmd.c b/src/ex_docmd.c
index 2b0f15e..374f29a 100644
--- a/src/ex_docmd.c
+++ b/src/ex_docmd.c
@@ -137,7 +137,7 @@ static int	getargopt(exarg_T *eap);
 #endif
 
 static int	check_more(int, int);
-static linenr_T get_address(exarg_T *, char_u **, int addr_type, int skip, int to_other_file);
+static linenr_T get_address(exarg_T *, char_u **, int addr_type, int skip, int to_other_file, int count);
 static void	get_flags(exarg_T *eap);
 #if !defined(FEAT_PERL) \
 	|| !defined(FEAT_PYTHON) || !defined(FEAT_PYTHON3) \
@@ -1791,6 +1791,7 @@ do_one_cmd(
 cmdmod_T		save_cmdmod;
 int			ni;			/* set when Not Implemented */
 char_u		*cmd;
+int			count = 1;
 
 vim_memset(, 0, sizeof(ea));
 ea.line1 = 1;
@@ -2015,7 +2016,7 @@ do_one_cmd(
 			{
 #ifdef FEAT_WINDOWS
 			long tabnr = get_address(, , ADDR_TABS,
-ea.skip, FALSE);
+ea.skip, FALSE, 1);
 			if (tabnr == MAXLNUM)
 cmdmod.tab = tabpage_index(curtab) + 1;
 			else
@@ -2175,7 +2176,7 @@ do_one_cmd(
 	}
 	ea.cmd = skipwhite(ea.cmd);
 	lnum = get_address(, , ea.addr_type, ea.skip,
-			  ea.addr_count == 0);
+			  ea.addr_count == 0, count++);
 	if (ea.cmd == NULL)		/* error detected */
 	goto doend;
 	if (lnum == MAXLNUM)
@@ -4363,7 +4364,8 @@ get_address(
 char_u	**ptr,
 int		addr_type,  /* flag: one of ADDR_LINES, ... */
 int		skip,	/* only skip the address, don't use it */
-int		to_other_file)  /* flag: may jump to other file */
+int		to_other_file,  /* flag: may jump to other file */
+int		count)	/* being called first or second time */
 {
 int		c;
 int		i;
@@ -4639,10 +4641,20 @@ get_address(
 		|| addr_type == ADDR_BUFFERS)
 		lnum = compute_buffer_local_count(
 addr_type, lnum, (i == '-') ? -1 * n : n);
-	else if (i == '-')
-		lnum -= n;
 	else
-		lnum += n;
+	{
+#ifdef FEAT_FOLDING
+		/* relative line addressing, need to adjust for folded lines now,
+		 * but only do it for the second address */
+		if (addr_type == ADDR_LINES && (i == '-' || i == '+')
+			&& count == 2)
+		(void)hasFolding(lnum, NULL, );
+#endif
+		if (i == '-')
+		lnum -= n;
+		else
+		lnum += n;
+	}
 	}
 } while (*cmd == '/' || *cmd == '?');
 
@@ -9301,7 +9313,7 @@ ex_copymove(exarg_T *eap)
 {
 long	n;
 
-n = get_address(eap, >arg, eap->addr_type, FALSE, FALSE);
+n = get_address(eap, >arg, eap->addr_type, FALSE, FALSE, 1);
 if (eap->arg == NULL)	/* error detected */
 {
 	eap->nextcmd = NULL;
diff --git a/src/testdir/Make_all.mak b/src/testdir/Make_all.mak
index c78e34b..7f69303 100644
--- a/src/testdir/Make_all.mak
+++ b/src/testdir/Make_all.mak
@@ -150,6 +150,7 @@ NEW_TESTS = test_arglist.res \
 	test_digraph.res \
 	test_display.res \
 	test_farsi.res \
+	test_fold.res \
 	test_fnameescape.res \
 	test_gf.res \
 	test_gn.res \
diff --git a/src/testdir/test_fold.vim b/src/testdir/test_fold.vim
new file mode 100644
index 000..1b52e92
--- /dev/null
+++ b/src/testdir/test_fold.vim
@@ -0,0 +1,65 @@
+" Test for folding
+
+function! Test_address_fold()
+  new
+  call setline(1, ['int FuncName() {/*{{{*/', 1, 2, 3, 4, 5, '}/*}}}*/',
+	  \ 'after fold 1', 'after fold 2', 'after fold 3'])
+  setl fen fdm=marker
+  " The next ccommands should all copy the same part of the buffer,
+  " regardless of the adressing type, since the part to be copied
+  " is folded away
+  :1y
+  call assert_equal(['int FuncName() {/*{{{*/', '1', '2', '3', '4', '5', '}/*}}}*/'], getreg(0,1,1))
+  :.y
+  call 

Re: Fold-related bug and pointer to fix

2016-12-14 Thread Christian Brabandt

Am 2016-12-14 15:35, schrieb Efraim Yawitz:

On Wed, Dec 14, 2016 at 7:26 AM, Ben Fritz 
wrote:


On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz
wrote:

Has any fix been made for this?  I'm not subscribed to vim_dev,

and there are a lot of messages to look through in the archives.


Thanks,

Ephraim




I don't see it in the todo list nor do I see it in the recent
patches.

--


What happens next?  Does Bram know about it?

This is not particularly urgent, especially since there is a simple
workaround to just use explicit line numbers, i.e. :.,778y instead of
.,+5y, but it certainly is incorrect.


We need a proper patch with a test to make sure, this fix works 
correctly.


I might look into it and submit a patch.

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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-12-14 Thread Efraim Yawitz
On Wed, Dec 14, 2016 at 7:26 AM, Ben Fritz  wrote:

> On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz wrote:
> > Has any fix been made for this?  I'm not subscribed to vim_dev, and
> there are a lot of messages to look through in the archives.
> >
> > Thanks,
> >
> > Ephraim
> >
> >
>
> I don't see it in the todo list nor do I see it in the recent patches.
>
> --
>

What happens next?  Does Bram know about it?

This is not particularly urgent, especially since there is a simple
workaround to just use explicit line numbers, i.e. :.,778y instead of
.,+5y, but it certainly is incorrect.

> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-12-13 Thread Ben Fritz
On Tuesday, December 13, 2016 at 6:37:54 AM UTC-6, Efraim Yawitz wrote:
> Has any fix been made for this?  I'm not subscribed to vim_dev, and there are 
> a lot of messages to look through in the archives.
> 
> Thanks,
> 
> Ephraim
> 
> 

I don't see it in the todo list nor do I see it in the recent patches.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-12-13 Thread Efraim Yawitz
Has any fix been made for this?  I'm not subscribed to vim_dev, and there
are a lot of messages to look through in the archives.

Thanks,

Ephraim

On Tue, Nov 29, 2016 at 7:02 PM, Ben Fritz  wrote:

> On Wednesday, November 23, 2016 at 4:39:24 AM UTC-6, Efraim Yawitz wrote:
> > I had the following problem and I think it is a bug in some fold-related
> code:
> >
> > I was trying to use the NarrowRegion plugin to do diffs between two
> functions in the same file by creating narrowed buffers for each function
> and calling :diffthis on them.  When I tried to do this using folds, i.e.
> :.,+2NarrowRegion to create a buffer for a folded-up function which looked
> like this:
> >
> > int FuncName() {
> > .folded
> > }
> >
> > I got everything but the final brace in the narrowed buffer.  Eventually
> I discovered that this has nothing to do with NarrowRegion, but just a yank
> such as:
> >
> > :.,+2y
> >
> > over a fold gives only the folded lines but not the line after the fold.
> >
> > A normal command of y2j works just fine and gets the line after the
> fold.
>
> I can confirm this looks like a bug, seeing the same behavior in 64-bit
> Vim 8.0.95 on Windows 7.
>
> It gets worse actually. I tried several yanks from code that looks like
> this in Vim:
>
>   else
>   { ---3 lines folded--- }
> #endif
>
>   if ( ---2 lines folded--- )
>
> With the cursor on the top "else" line:
>
> :.,+2y yanks only the "else" and the folded lines beneath, when I expect
> to also get the #endif
>
> :.,+3y yanks the exact same thing (omitting the #endif *and* the empty
> line)
>
> :.,+4y finally includes the #endif (with nothing after it) but I expected
> it to yank everything from "else" to the content of the second folded
> section.
>
> The :d command acts in the same way.
>
> It appears something is wrong with handling of folded lines in the ranges
> specified for ex commands.
>
> Forwarding to vim_dev as this appears to be a bug.
>
> --
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-11-29 Thread Efraim Yawitz
On Tue, Nov 29, 2016 at 7:02 PM, Ben Fritz  wrote:

> On Wednesday, November 23, 2016 at 4:39:24 AM UTC-6, Efraim Yawitz wrote:
> > I had the following problem and I think it is a bug in some fold-related
> code:
> >
> > I was trying to use the NarrowRegion plugin to do diffs between two
> functions in the same file by creating narrowed buffers for each function
> and calling :diffthis on them.  When I tried to do this using folds, i.e.
> :.,+2NarrowRegion to create a buffer for a folded-up function which looked
> like this:
> >
> > int FuncName() {
> > .folded
> > }
> >
> > I got everything but the final brace in the narrowed buffer.  Eventually
> I discovered that this has nothing to do with NarrowRegion, but just a yank
> such as:
> >
> > :.,+2y
> >
> > over a fold gives only the folded lines but not the line after the fold.
> >
> > A normal command of y2j works just fine and gets the line after the
> fold.
>
> I can confirm this looks like a bug, seeing the same behavior in 64-bit
> Vim 8.0.95 on Windows 7.
>
> It gets worse actually. I tried several yanks from code that looks like
> this in Vim:
>
>   else
>   { ---3 lines folded--- }
> #endif
>
>   if ( ---2 lines folded--- )
>
> With the cursor on the top "else" line:
>
> :.,+2y yanks only the "else" and the folded lines beneath, when I expect
> to also get the #endif
>
> :.,+3y yanks the exact same thing (omitting the #endif *and* the empty
> line)
>
> :.,+4y finally includes the #endif (with nothing after it) but I expected
> it to yank everything from "else" to the content of the second folded
> section.
>
> The :d command acts in the same way.
>
> It appears something is wrong with handling of folded lines in the ranges
> specified for ex commands.
>
> Forwarding to vim_dev as this appears to be a bug.
>

Thanks.  As I wrote before, the handling of folds in do_one_cmd just has
one call to hasFolding() for the end of the fold while in cursor_down() in
edit.c, there is the following code which seems to take care of all folds:

#ifdef FEAT_FOLDING
if (hasAnyFolding(curwin))
{
linenr_Tlast;

/* count each sequence of folded lines as one logical line */
while (n--)
{
if (hasFolding(lnum, NULL, ))
lnum = last + 1;
else
++lnum;
if (lnum >= curbuf->b_ml.ml_line_count)
break;
}
if (lnum > curbuf->b_ml.ml_line_count)
lnum = curbuf->b_ml.ml_line_count;
}
else
#endif


>
> --
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Fold-related bug and pointer to fix

2016-11-29 Thread Ben Fritz
On Wednesday, November 23, 2016 at 4:39:24 AM UTC-6, Efraim Yawitz wrote:
> I had the following problem and I think it is a bug in some fold-related code:
> 
> I was trying to use the NarrowRegion plugin to do diffs between two functions 
> in the same file by creating narrowed buffers for each function and calling 
> :diffthis on them.  When I tried to do this using folds, i.e. 
> :.,+2NarrowRegion to create a buffer for a folded-up function which looked 
> like this:
> 
> int FuncName() {
> .folded
> }
> 
> I got everything but the final brace in the narrowed buffer.  Eventually I 
> discovered that this has nothing to do with NarrowRegion, but just a yank 
> such as:
> 
> :.,+2y
> 
> over a fold gives only the folded lines but not the line after the fold.
> 
> A normal command of y2j works just fine and gets the line after the fold.  

I can confirm this looks like a bug, seeing the same behavior in 64-bit Vim 
8.0.95 on Windows 7.

It gets worse actually. I tried several yanks from code that looks like this in 
Vim:

  else
  { ---3 lines folded--- }
#endif

  if ( ---2 lines folded--- )

With the cursor on the top "else" line:

:.,+2y yanks only the "else" and the folded lines beneath, when I expect to 
also get the #endif

:.,+3y yanks the exact same thing (omitting the #endif *and* the empty line)

:.,+4y finally includes the #endif (with nothing after it) but I expected it to 
yank everything from "else" to the content of the second folded section.

The :d command acts in the same way.

It appears something is wrong with handling of folded lines in the ranges 
specified for ex commands.

Forwarding to vim_dev as this appears to be a bug.

-- 
-- 
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+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.