Greetings vim-dev,

I have a patch I would like to submit to fix a bug in vim.



Description of the problem and the patch:
===========================

In the code below, place the cursor over the brace { on the end of the
first line.
Press % to jump the cursor to the matching brace.
The cursor jumps to the first brace inside the comment.

This patch modifies that behavior so that the cursor jumps to the
matching brace on the final line.

for( $x = 0; $x < 10; $x++ ) {  // Place the cursor on this brace.
     if( $x == 4 ) {
         echo "x is equal to 4!\n";
     }
     // } else { echo "x is not equal to 4... =(\n"; }
}  // It should jump to this brace, but it does not.  This patch
corrects this behavior.

===========================



The patch:
===========================
--- a/src/search.c Sun Dec 16
+++ b/src/search.c Wed Jan 02
@@ -20,6 +20,7 @@
  static int check_prevcol __ARGS((char_u *linep, int col, int ch, int
*prevcol));
  static int inmacro __ARGS((char_u *, char_u *));
  static int check_linecomment __ARGS((char_u *line));
+static int check_hashcomment __ARGS((char_u *line));
  static int cls __ARGS((void));
  static int skip_chars __ARGS((int, int));
  #ifdef FEAT_TEXTOBJ
@@ -1751,6 +1752,8 @@
      int  match_escaped = 0; /* search for escaped match */
      int  dir; 	 /* Direction to search */
      int  comment_col = MAXCOL;   /* start of / / comment */
+    int  hashcomment_col = MAXCOL;   /* start of # comment */
+    int     start_in_comment;   /* start position is in a comment */
  #ifdef FEAT_LISP
      int  lispcomm = FALSE; /* inside of Lisp-style comment */
      int  lisp = curbuf->b_p_lisp; /* engage Lisp-specific hacks ;) */
@@ -2018,6 +2021,12 @@

      do_quotes = -1;
      start_in_quotes = MAYBE;
+    // If we start in a line comment or hash comment, then we know
for a fact that we are in comments.
+    // Otherwise we don't know - we may or may not be in a block comment.
+    if( check_linecomment( linep ) < pos.col || check_hashcomment(
linep ) < pos.col )
+        start_in_comment = TRUE;
+    else
+        start_in_comment = MAYBE;
      clearpos(&match_pos);

      /* backward search: Check if this line contains a single-line comment */
@@ -2249,6 +2258,48 @@
 	 if (start_in_quotes == MAYBE)
 	     start_in_quotes = FALSE;

+    /*
+     * If we find the start of a block comment, set match_pos to
+     *     our position.  Clear match_pos if we find the end of
+     *     the block comment.
+     *
+     * Once we find the start or end of a block comment, we also
+     *     know for a fact whether or not we started in a comment.
+     *     ( If we were not yet sure... )
+     */
+    if( backwards )
+    {
+        if( linep[pos.col] == '/' && linep[pos.col+1] == '*' )
+        {
+            clearpos(&match_pos);
+            if( start_in_comment == MAYBE )
+                start_in_comment = TRUE;
+        }
+        else if( linep[pos.col] == '*' && linep[pos.col+1] == '/' )
+        {
+            match_pos.lnum = pos.lnum;
+            match_pos.col = pos.col;
+            if( start_in_comment == MAYBE )
+                start_in_comment = FALSE;
+        }
+    }
+    else
+    {
+        if( linep[pos.col] == '/' && linep[pos.col+1] == '*' )
+        {
+            match_pos.lnum = pos.lnum;
+            match_pos.col = pos.col;
+            if( start_in_comment == MAYBE )
+                start_in_comment = FALSE;
+        }
+        else if( linep[pos.col] == '*' && linep[pos.col+1] == '/' )
+        {
+            clearpos(&match_pos);
+            if( start_in_comment == MAYBE )
+                start_in_comment = TRUE;
+        }
+    }
+
 	 /*
 	  * If 'smartmatch' is set:
 	  *   Things inside quotes are ignored by setting 'inquote'.  If we
@@ -2260,6 +2311,8 @@
 	  *   inquote if the number of quotes in a line is even, unless this
 	  *   line or the previous one ends in a '\'.  Complicated, isn't it?
 	  */
+    comment_col = check_linecomment( linep );
+    hashcomment_col = check_hashcomment( linep );
 	 switch (c = linep[pos.col])
 	 {
 	 case NUL:
@@ -2363,14 +2416,17 @@
 		  * is what we expect. */
 		 if (cpo_bsl || (bslcnt & 1) == match_escaped)
 		 {
- 	    if (c == initc)
- 	 count++;
- 	    else
- 	    {
- 	 if (count == 0)
- 		    return &pos;
- 	 count--;
- 	    }
+            if( ( pos.col < comment_col && pos.col < hashcomment_col
&& match_pos.lnum == 0 && match_pos.col == 0 && start_in_comment !=
TRUE ) || ( start_in_comment == TRUE ) )
+            {
+                if (c == initc)
+                    count++;
+                else
+                {
+                    if (count == 0)
+                        return &pos;
+                    count--;
+                }
+            }
 		 }
 	     }
 	 }
@@ -2445,6 +2501,28 @@
  }

  /*
+ * Check if line[] contains a hash comment (a comment starting with #).
+ *    Example:
+ *       # This is a comment.
+ * Return MAXCOL if not, otherwise return the column.
+ * TODO: skip strings.
+ */
+    static int
+check_hashcomment(line)
+    char_u *line;
+{
+    char_u  *p;
+
+    p = line;
+
+    p = vim_strchr( p, '#' );
+
+    if( p == NULL )
+     return MAXCOL;
+    return (int)(p - line);
+}
+
+/*
   * Move cursor briefly to character matching the one under the cursor.
   * Used for Insert mode and "r" command.
   * Show the match only if it is visible on the screen.
===========================



Comments and questions welcome, and thanks for taking the time to
consider the patch.

Archer

--
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

On Wed, Jan 2, 2013 at 6:31 PM, GM <linuximp@...> wrote:
> Greetings vim-dev,
>
> I have a patch I would like to submit to fix a bug in vim.
>

[...]

Probably should have also submitted the patch as a text file...

Best regards,
Archer

--
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

On 2013-01-02, GM wrote:
> Greetings vim-dev,
>
> I have a patch I would like to submit to fix a bug in vim.
>
>
>
> Description of the problem and the patch:
> ===========================
>
> In the code below, place the cursor over the brace { on the end of the
> first line.
> Press % to jump the cursor to the matching brace.
> The cursor jumps to the first brace inside the comment.
>
> This patch modifies that behavior so that the cursor jumps to the
> matching brace on the final line.
>
> for( $x = 0; $x < 10; $x++ ) {  // Place the cursor on this brace.
>     if( $x == 4 ) {
>         echo "x is equal to 4!\n";
>     }
>     // } else { echo "x is not equal to 4... =(\n"; }
> }  // It should jump to this brace, but it does not.  This patch
> corrects this behavior.

You can also get this modified behavior by enabling the matchit.vim
plugin ($VIMRUNTIME/macros/matchit.vim) and enabling syntax
highlighting.

Regards,
Gary

--
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

On Tuesday, 28 June 2011 13:57:37 UTC+2, Andy Wokula  wrote:
> Strange: one can't write a collection with range [X-Y] where Y is the
> character ']'.
>
> I thought the following should work, but it doesn't:
>      /[@-\]]
>
> Is it a bug that '\' after '-' in a collection is taken literally?

No, that's normal vi behaviour. \ is not special in a character range (it stands
for itself) and to include ] you need to specify it as the first character in
the range. In the example you give
    /[]@-\]
(knowing that \ is the character previous to ])

    M

--
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

Hi

On So, 30 Dez 2012, Christian Brabandt wrote:

> here is a patch to make the matchpairs setting multibyte aware.
>

Updated patch, now also works for non multi-byte builts.


regards,
Christian
--
Aus einer Menge von unordentlichen Strichen bildet man sich leicht
eine Gegend, aber aus unordentlichen Tönen keine Musik.
		 -- Georg Christoph Lichtenberg

--
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

On Thursday, January 3, 2013 2:51:38 AM UTC-6, martinwguy wrote:
> On Tuesday, 28 June 2011 13:57:37 UTC+2, Andy Wokula  wrote:
> > Strange: one can't write a collection with range [X-Y] where Y is the
> > character ']'.
> >
> > I thought the following should work, but it doesn't:
> >      /[@-\]]
> >
> > Is it a bug that '\' after '-' in a collection is taken literally?
>
> No, that's normal vi behaviour. \ is not special in a character range (it
stands for itself) and to include ] you need to specify it as the first
character in the range.

I disagree, and consider it a bug. :help /\] says:

	 - To include a literal ']', '^', '-' or '\' in the collection, put a
	   backslash before it: "[xyz\]]", "[\^xyz]", "[xy\-z]" and "[xyz\\]".
	   (Note: POSIX does not support the use of a backslash this way).  For
	   ']' you can also make it the first character (following a possible
	   "^"):  "[]xyz]" or "[^]xyz]" {not in Vi}.
	   For '-' you can also make it the first or last character: "[-xyz]",
	   "[^-xyz]" or "[xyz-]".  For '\' you can also let it be followed by
	   any character that's not in "^]-\bdertnoUux".  "[\xyz]" matches '\',
	   'x', 'y' and 'z'.  It's better to use "\\" though, future expansions
	   may use other characters after '\'.

This works:

/[[\\\]]

This does not work, even though it should do the same thing if the above help
entry were implemented as stated:

/[[-\]]

Using your example, this does work, but I would not expect it to:

/[][-\]

I would expect this to not be treated as a collection at all, because the
closing ] has a \ in front.

There is obviously at least a documentation bug here.

--
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

Hi Ben!

On Do, 03 Jan 2013, Ben Fritz wrote:

> On Thursday, January 3, 2013 2:51:38 AM UTC-6, martinwguy wrote:
> > On Tuesday, 28 June 2011 13:57:37 UTC+2, Andy Wokula  wrote:
> > > Strange: one can't write a collection with range [X-Y] where Y is the
> > > character ']'.
> > >
> > > I thought the following should work, but it doesn't:
> > >      /[@-\]]
> > >
> > > Is it a bug that '\' after '-' in a collection is taken literally?
> >
> > No, that's normal vi behaviour. \ is not special in a character range (it
stands for itself) and to include ] you need to specify it as the first
character in the range.

That is how POSIX defines it:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_0\
3_05

,----
| A bracket expression is either a matching list expression or a
| non-matching list expression. It consists of one or more expressions:
| collating elements, collating symbols, equivalence classes, character
| classes, or range expressions. The <right-square-bracket> ( ']' ) shall
| lose its special meaning and represent itself in a bracket expression if
| it occurs first in the list (after an initial <circumflex> ( '^' ), if
| any). Otherwise, it shall terminate the bracket expression, unless it
| appears in a collating symbol (such as "[.].]" ) or is the ending
| <right-square-bracket> for a collating symbol, equivalence class, or
| character class. The special characters '.' , '*' , '[' , and '\\' (
| <period>, <asterisk>, <left-square-bracket>, and <backslash>,
| respectively) shall lose their special meaning within a bracket
| expression.
`----

>
> I disagree, and consider it a bug. :help /\] says:
>
>  - To include a literal ']', '^', '-' or '\' in the collection, put a
> 	  backslash before it: "[xyz\]]", "[\^xyz]", "[xy\-z]" and "[xyz\\]".
> 	  (Note: POSIX does not support the use of a backslash this way).  For
> 	  ']' you can also make it the first character (following a possible
> 	  "^"):  "[]xyz]" or "[^]xyz]" {not in Vi}.
> 	  For '-' you can also make it the first or last character: "[-xyz]",
> 	  "[^-xyz]" or "[xyz-]".  For '\' you can also let it be followed by
> 	  any character that's not in "^]-\bdertnoUux".  "[\xyz]" matches '\',
> 	  'x', 'y' and 'z'.  It's better to use "\\" though, future expansions
> 	  may use other characters after '\'.
>
> This works:
>
> /[[\\\]]

Looks like a Vim extension to BRE (as stated in your quotation from the
help).

>
> This does not work, even though it should do the same thing if the above help
entry were implemented as stated:
>
> /[[-\]]

Yes, the backslash doesn't have a special meaning when used within a
range. Not sure, we should fix this.

>
> Using your example, this does work, but I would not expect it to:
>
> /[][-\]
>
> I would expect this to not be treated as a collection at all, because the
closing ] has a \ in front.

Yes, but the standard demands other. However, I think
/[]\-] would be more cleaner and is suggested by the standard:

,----
| If a bracket expression specifies both '-' and ']' , the ']' shall be
| placed first (after the '^' , if any) and the '-' last within the
| bracket expression.
`----

regards,
Christian
--
Haben Sie Ihre Begabung von der Mutter? -
Nein, ich habe sie mit der Vatermilch eingesogen.
		 -- Heinz Erhardt

--
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

Am 03.01.2013 09:51, schrieb martinwguy:
> On Tuesday, 28 June 2011 13:57:37 UTC+2, Andy Wokula  wrote:
>> Strange: one can't write a collection with range [X-Y] where Y is the
>> character ']'.
>>
>> I thought the following should work, but it doesn't:
>>       /[@-\]]
>>
>> Is it a bug that '\' after '-' in a collection is taken literally?
>
> No, that's normal vi behaviour.

The context is Vim, not Vi:
      :set nocp cpo&vim

> \ is not special in a character range (it stands for itself) and to
> include ] you need to specify it as the first character in the range.

Even with set 'cp', `\]' is still special.  See:
      :h cpo-\

Do you actually use Vi?

> In the example you give
>     /[]@-\]
> (knowing that \ is the character previous to ])
(my pattern `[@-\\]]' also made use of it)

So far, it looks like if Vim just forgot to implement a certain case.
There is no apparent reason why `\]' is allowed for X but not for Y in
a [X-Y] collection.

--
Andy

--
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

Hi

On Fr, 04 Jan 2013, Christian Brabandt wrote:

> Hi Ben!
>
> On Do, 03 Jan 2013, Ben Fritz wrote:
>
> > On Thursday, January 3, 2013 2:51:38 AM UTC-6, martinwguy wrote:
> > > On Tuesday, 28 June 2011 13:57:37 UTC+2, Andy Wokula  wrote:
> > > > Strange: one can't write a collection with range [X-Y] where Y is the
> > > > character ']'.
> > > >
> > > > I thought the following should work, but it doesn't:
> > > >      /[@-\]]
> > > >
> > > > Is it a bug that '\' after '-' in a collection is taken literally?
> > >
> > > No, that's normal vi behaviour. \ is not special in a character range (it
stands for itself) and to include ] you need to specify it as the first
character in the range.
>
> That is how POSIX defines it:
>
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html#tag_09_0\
3_05
>
> ,----
> | A bracket expression is either a matching list expression or a
> | non-matching list expression. It consists of one or more expressions:
> | collating elements, collating symbols, equivalence classes, character
> | classes, or range expressions. The <right-square-bracket> ( ']' ) shall
> | lose its special meaning and represent itself in a bracket expression if
> | it occurs first in the list (after an initial <circumflex> ( '^' ), if
> | any). Otherwise, it shall terminate the bracket expression, unless it
> | appears in a collating symbol (such as "[.].]" ) or is the ending
> | <right-square-bracket> for a collating symbol, equivalence class, or
> | character class. The special characters '.' , '*' , '[' , and '\\' (
> | <period>, <asterisk>, <left-square-bracket>, and <backslash>,
> | respectively) shall lose their special meaning within a bracket
> | expression.
> `----
>
> >
> > I disagree, and consider it a bug. :help /\] says:
> >
> >  - To include a literal ']', '^', '-' or '\' in the collection, put a
> > 	  backslash before it: "[xyz\]]", "[\^xyz]", "[xy\-z]" and "[xyz\\]".
> > 	  (Note: POSIX does not support the use of a backslash this way).  For
> > 	  ']' you can also make it the first character (following a possible
> > 	  "^"):  "[]xyz]" or "[^]xyz]" {not in Vi}.
> > 	  For '-' you can also make it the first or last character: "[-xyz]",
> > 	  "[^-xyz]" or "[xyz-]".  For '\' you can also let it be followed by
> > 	  any character that's not in "^]-\bdertnoUux".  "[\xyz]" matches '\',
> > 	  'x', 'y' and 'z'.  It's better to use "\\" though, future expansions
> > 	  may use other characters after '\'.
> >
> > This works:
> >
> > /[[\\\]]
>
> Looks like a Vim extension to BRE (as stated in your quotation from the
> help).
>
> >
> > This does not work, even though it should do the same thing if the above
help entry were implemented as stated:
> >
> > /[[-\]]
>
> Yes, the backslash doesn't have a special meaning when used within a
> range. Not sure, we should fix this.

I think, this is implicitly mentioned below :h /[]

,----
| - The following translations are accepted when the 'l' flag is not
|   included in 'cpoptions' {not in Vi}:
|         \e <Esc>
|         \t <Tab>
|         \r <CR> (NOT end-of-line!)
|         \b <BS>
|         \n line break, see above |/[\n]|
|         \d123 decimal number of character
|         \o40 octal number of character up to 0377
|         \x20 hexadecimal number of character up to 0xff
|         \u20AC hex. number of multibyte character up to 0xffff
|         \U1234 hex. number of multibyte character up to 0xffffffff
|   NOTE: The other backslash codes mentioned above do not work inside
|   []!
`----

However, to fix this, the following patch can be applied:

diff --git a/src/regexp.c b/src/regexp.c
--- a/src/regexp.c
+++ b/src/regexp.c
@@ -2344,7 +2344,12 @@

                             /* Handle \o40, \x20 and \u20AC style sequences */
                             if (endc == '\\' && !cpo_lit && !cpo_bsl)
+                           {
                                 endc = coll_get_char();
+                               /* Skip over backslash */
+                               if (endc == '\\')
+                                   endc = *regparse++;
+                           }



Mit freundlichen Grüßen
Christian
--
Wenn der Knecht zum Waldrand hetzt, war das Örtchen schon besetzt.

--
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

Am 23.11.2012 22:09, schrieb Bram Moolenaar:
>
> Christian Brabandt wrote:
>
>> On Fr, 23 Nov 2012, Bram Moolenaar wrote:
>>
>>> Christian Brabandt wrote:
>>>
>>>> On Do, 22 Nov 2012, Bram Moolenaar wrote:
>>>>
>>>>>
>>>>> Andy Wokula wrote:
>>>>>
>>>>>> " Vim Parsing Bug
>>>>>>
>>>>>> func! Add2(x1, x2)
>>>>>>       return a:x1 + a:x2
>>>>>> endfunc
>>>>>>
>>>>>> :echo function('Add2')(2,3)
>>>>>> " 5 (ok)
>>>>>>
>>>>>> " Bug:
>>>>>> :echo 1 ? function('Add2')(1,2) : function('Add2')(2,3)
>>>>>> :echo 0 ? function('Add2')(1,2) : function('Add2')(2,3)
>>>>>>
>>>>>> " Error detected while processing D1223.vim:
>>>>>> " line   17:
>>>>>> " E110: Missing ')'
>>>>>> " E15: Invalid expression: (2,3)
>>>>>> " line   18:
>>>>>> " E109: Missing ':' after '?'
>>>>>> " E15: Invalid expression: 0 ? function('Add2')(1,2) :
function('Add2')(2,3)
>>>>>>
>>>>>>
>>>>>> Adding parentheses  1 ? (...) : (...)  doesn't help.
>>>>>
>>>>> Strange.  I'll add it to the todo list.
>>>>
>>>> Problem is, in expr1 ? expr2 : expr3
>>>> Vim explicitly resets evaluate in the false case which leads to being
>>>> rettv.v_type being VAR_UNKNOWN and then handle_subscript doesn't handle
>>>> the subscript anymore.
>>>>
>>>> Here is a patch:
(obsolete patch)
>>>
>>> Thanks for the quick fix.
>>>
>>> Now, how about a test?
>>
>> Well, I am not sure, what caused the segfault for Andy. But I have been
>> checking with him privately, that this patch works and added some tests.
>> So here we go, a different patch, including a test.
>
> Thanks!

So far, this latest patch works ok for me.

--
Andy

--
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

Hi

On Fr, 04 Jan 2013, Christian Brabandt wrote:

>
> However, to fix this, the following patch can be applied:

And finally, here is a better patch, supporting multibyte chars and
including a test.

Mit freundlichen Grüßen
Christian
--
Das unmittelbare Gewahrwerden der Urphänomene versetzt uns in
eine Art von Angst, wir fühlen unsere Unzulänglichkeit; nur durch das
ewige Spiel der Empirie belebt erfreuen sie uns.
		 -- Goethe, Maximen und Reflektionen, Nr. 817

--
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

Am 04.01.2013 14:29, schrieb Christian Brabandt:
>> /[[-\]]
>
> Yes, the backslash doesn't have a special meaning when used within a
> range. Not sure, we should fix this.

Whether to fix this was my original question (June 2011).
The rest is off-topic for this thread.

--
Andy

--
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

Hi,

2013/01/3 Thu 1:57:05 UTC+9 Bram Moolenaar wrote:
> Ken Takata wrote:
>
> > Many thanks to Frodak Baksik and Anton Sharonov for this feature.
> >
> > I have updated Anton's patches to be applied to the latest version
> > (7.3.762).
>
> Thanks, I'll update the todo list.

I have updated the full patch.
"make winclip.pro" didn't work well.

Thanks,
Ken Takata

--
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

I'm wondering if the behavior of normal mode "p" is correct in respect to the
cursor position?

The docs state for "gp":

    "Just like "p", but leave the cursor just after the new text."

which suggests/implies that after "p" the cursor should stay in its current
position (which - unfortunately - is not the case).

--
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

Hi Axel!

On Fr, 04 Jan 2013, Axel Bender wrote:

> I'm wondering if the behavior of normal mode "p" is correct in respect to the
cursor position?
>
> The docs state for "gp":
>
>    "Just like "p", but leave the cursor just after the new text."
>
> which suggests/implies that after "p" the cursor should stay in its current
position (which - unfortunately - is not the case).

Well, the cursor positioning seems rather complicated for p and P, see
the description of the standard:
http://pubs.opengroup.org/onlinepubs/9699919799/
(and search for Put from Buffer Following  and Put from Buffer Before).

However, when reading this section:

,----[ Put from Buffer Following ]-
| Synopsis:
| [buffer] p
|
| […]
| Current column:
|
| If the buffer text is in character mode:
|
| If the text in the buffer is from more than a single line, then set to
| the last column on which any portion of the first character from the
| buffer is displayed.
|
| Otherwise, if the buffer is the unnamed buffer, set to the last column
| on which any portion of the last character from the buffer is displayed.
|
| Otherwise, set to the first column on which any portion of the first
| character from the buffer is displayed.
`----

Reading the last sentence, it seems to me, that Vim does not behave like
this, in fact, 'p' for character mode always seems to move to the last
inserted character. This sounds like a bug to me? (nvi behaves as
documented). Should this be fixed (and possibly added yet-another flag
to the 'cpo' setting)?

Mit freundlichen Grüßen
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

On 4 January 2013 14:34, Andy Wokula <anwoku@...> wrote:
> Am 03.01.2013 09:51, schrieb martinwguy:
>>> Is it a bug that '\' after '-' in a collection is taken literally?
>> No, that's normal vi behaviour.
> The context is Vim, not Vi:
>     :set nocp cpo&vim

Er, I thought vim was a reimplementation of vi.

>> \ is not special in a character range (it stands for itself) and to
>> include ] you need to specify it as the first character in the range.
>
> Even with set 'cp', `\]' is still special.  See:
>     :h cpo-\

Mmm, sorry, I don't know what :se cp/nocp is.


> Do you actually use Vi?

Hum, it sounds like you're putting your fists up. Bad sign.
Yes, since 1982 for all my work. I am also the maintainer for another
vi clone, "xvi".
Is that enough for you?

>> In the example you give
>>     /[]@-\]
>> (knowing that \ is the character previous to ])
>
> (my pattern `[@-\\]]' also made use of it)
>
> So far, it looks like if Vim just forgot to implement a certain case.
> There is no apparent reason why `\]' is allowed for X but not for Y in
> a [X-Y] collection.

No, you're thinking that vi should do as you would expect according to
your own thinking.
That may be reasonable if we were designing a new editor, but vim is a
vi clone, so needs to implement what vi, and the other dozen vi
clones, do, so as not to break people's scripts.

That said, it is open source, so you are free to take it, make the
change you desire and suse your own version.

Or take it up with Bill Joy in the 1970s, but fr that you will need a
time machine...

    M

--
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

On 2013-01-04, martinwguy wrote:
> On 4 January 2013 14:34, Andy Wokula wrote:
> > Am 03.01.2013 09:51, schrieb martinwguy:
> >>> Is it a bug that '\' after '-' in a collection is taken literally?
> >> No, that's normal vi behaviour.
> > The context is Vim, not Vi:
> >     :set nocp cpo&vim
>
> Er, I thought vim was a reimplementation of vi.

It is.  To a point.  See

     :help design-compatible
     :help vi-differences

> >> \ is not special in a character range (it stands for itself) and to
> >> include ] you need to specify it as the first character in the range.
> >
> > Even with set 'cp', `\]' is still special.  See:
> >     :h cpo-\
>
> Mmm, sorry, I don't know what :se cp/nocp is.

     :help 'cp'

> > Do you actually use Vi?
>
> Hum, it sounds like you're putting your fists up. Bad sign.
> Yes, since 1982 for all my work. I am also the maintainer for another
> vi clone, "xvi".
> Is that enough for you?

There are a couple of ways that question could be read.  I think
Andy meant it as, "Do you use vi and not Vim?", and I think you
took it as, "Do you know how to use vi?"

Regards,
Gary

--
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

Apologies in advance if this is a duplicate post.  I sent a mail to
vim-dev@... before noticing that that my subscription request
triggered a join confirmation from vim_dev@googlegroups.com and the
e-mail did not appear to get sent back to me as a subscribed member.

In any event, I would like to request a vimdoc update relative to
column block editing in GVim under Microsoft Windows.  This request
is related to:

http://stackoverflow.com/questions/14163642/keyboard-only-column-block-selection\
-in-gvim-win32-or-why-does-ctrl-q-not-emula

In GVim, `:help Ctrl-C-Alternative` and/or `:help mswin` does not mention
an important difference between use of Ctrl-V in Vim versus use of Ctrl-Q
in GVim when mswin.vim is sourced in _vimrc.  I have been unable to find
documention of this difference after a lot of research, and think that
users are probably better served if the documentation was more complete
in this regard.

I refer to vimdoc content here:

http://vimdoc.sourceforge.net/htmldoc/gui_w32.html
*CTRL-V-alternative* *CTRL-Q*
*mswin.vim*

After much research and effort, I was not able to find out how to perform
columnar block selection in GVim using only the keyboard.  Eventually,
after a lot of brute-force experimentation, I stumbled upon the key:

   To select column blocks in GVim on Win32 using only the keyboard, press
   Ctrl-Q, release it, then press and hold down the Shift key while using
   the arrow keys to select the column block.

I could not find help that mentioned that the Shift key must be used.  In
Vim the shift key is used only for row block selection, and furthermore,
the shift key is not held down during block selection.

I hope that I have not simply missed the relevant documentation that
discloses this information, but if I have, then I propose that the
information is not indexed well enough as I spent a lot of time
trying to find out how to do this.

I tried to file a tracker item on SourceForge, but the network that I am
on terminates my connection upon clicking the `Add New` link, and I do
not use MS Windows at home, so might not particularly think about the
issue there.

---
Kevin R. Bulgrien
Design and Development Engineer

This message and/or attachments may include information subject to GD Corporate
Policy 07-105 and is intended to be accessed only by authorized personnel of
General Dynamics and approved service providers.  Use, storage and transmission
are governed by General Dynamics and its policies. Contractual restrictions
apply to third parties.  Recipients should refer to the policies or contract to
determine proper handling.  Unauthorized review, use, disclosure or distribution
is prohibited.  If you are not an intended recipient, please contact the sender
and destroy all copies of the original message.

--
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

Hi Christian,

thanks for the answer. It goes along with my perception. I consider this a bug
which needs a fix. Also, at times it would come very handy to have p's
functionality being different from gp's.


--
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

On 06/01/13 13:08, Axel Bender wrote:
> Hi Christian,
>
> thanks for the answer. It goes along with my perception. I consider this a bug
which needs a fix. Also, at times it would come very handy to have p's
functionality being different from gp's.
>
>
They are different. For characterwise put at least, p leaves the cursor
on the last character of the inserted string while gp puts it
immediately after it. And Bram is known to be extremely reluctant to
accept any behaviour change which might break something in an existing
script or mapping (even one not distributed with Vim).

Best regards,
Tony.
--
In Tennessee, it is illegal to shoot any game other than whales from a
moving automobile.

--
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

Hi Axel!

On So, 06 Jan 2013, Axel Bender wrote:

> Hi Christian,
>
> thanks for the answer. It goes along with my perception. I consider this a bug
which needs a fix. Also, at times it would come very handy to have p's
functionality being different from gp's.

What exactly do you consider a bug? Using p is a pretty basic action and
changing the cursor position will be a backwards incompatible change and
will probably break many scripts, macros and maps, thus it is not very
likely, that this behaviour is going to be "fixed", especially since
nobody has complained until now.

The best I can think of, is using something like the attached patch,
which only changes the cursor position for characterwise put of single
lines according to the POSIX standard (as quoted before, see also
http://pubs.opengroup.org/onlinepubs/9699919799/utilities/vi.html#tag_20_152_13_\
69).
This introduces the new cpo-flag '[' (we are running out of arguments
for the cpo setting so I used the first free char, that I found) and
only works, if set cpo+=[ has been used.

Mit freundlichen Grüßen
Christian
--
Jetzt wächst zusammen, was zusammen gehört.
		 -- Willy Brandt

--
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

Hello

I have found an unexpected behaviour in the normal command and I am not sure
if it is a bug or just not explicitly mentioned in the help.

Consider the following file (# depicts the cursor):

1 foo
2 #bar
3 zab

Now enter :norm! ddkP, the file should now look like this.

1 #bar
2 foo
3 zab

So far so good, execute the same command once more. Result:

1 #foo
2 zab

The first line was removed but not inserted; this doesn't happen when
executing ddkP manually. The help file says that :normal stops on errors but
is it an error when the cursor just can't move one line up?

I don't know what behaviour was intended, but I think it should either be
considered a bug or there should be an explicit hint in the help.

Best regards,
Mohammed

--
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

On 04-Jan-13 12:58:15 +0900, Mohammed Chelouti wrote:

> Hello
>
> I have found an unexpected behaviour in the normal command and I am not sure
> if it is a bug or just not explicitly mentioned in the help.
>
> Consider the following file (# depicts the cursor):
>
> 1 foo
> 2 #bar
> 3 zab
>
> Now enter :norm! ddkP, the file should now look like this.
>
> 1 #bar
> 2 foo
> 3 zab
>
> So far so good, execute the same command once more. Result:
>
> 1 #foo
> 2 zab
>
> The first line was removed but not inserted; this doesn't happen when
> executing ddkP manually.

When you type this manually, you're effectively executing this:

     execute 'norm! dd' | execute 'norm! k' | execute 'norm! P'

And this indeed doesn't stop.

> The help file says that :normal stops on errors but is it an error
> when the cursor just can't move one line up?

Yes it is. The beep that is issued is a clear indication of the error.

> I don't know what behaviour was intended, but I think it should either
> be considered a bug or there should be an explicit hint in the help.

Yes, it is intended, and it's very helpful to abort (recursive) macros. And the
reference in the help is exactly what you've quoted. Sorry that some Vim
peculiarities are so hard to discover, but I guess that's the price one has to
pay for such a powerful editor.

-- regards, ingo

--
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

> It's in the todo list.  That list is very long, and bug fixes have
> priority.  Might take a while.

Bump :)

Philippe

--
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

Am 07.01.2013 01:39, schrieb Ingo Karkat:
> On 04-Jan-13 12:58:15 +0900, Mohammed Chelouti wrote:
>
>> Hello
>>
>> I have found an unexpected behaviour in the normal command and I am
>> not sure if it is a bug or just not explicitly mentioned in the help.
>>
>> Consider the following file (# depicts the cursor):
>>
>> 1 foo
>> 2 #bar
>> 3 zab
>>
>> Now enter :norm! ddkP, the file should now look like this.
>>
>> 1 #bar
>> 2 foo
>> 3 zab
>>
>> So far so good, execute the same command once more. Result:
>>
>> 1 #foo
>> 2 zab
>>
>> The first line was removed but not inserted; this doesn't happen when
>> executing ddkP manually.
>
> When you type this manually, you're effectively executing this:
>
>      execute 'norm! dd' | execute 'norm! k' | execute 'norm! P'
>
> And this indeed doesn't stop.
>
>> The help file says that :normal stops on errors but is it an error
>> when the cursor just can't move one line up?
>
> Yes it is. The beep that is issued is a clear indication of the error.
>
>> I don't know what behaviour was intended, but I think it should either
>> be considered a bug or there should be an explicit hint in the help.
>
> Yes, it is intended, and it's very helpful to abort (recursive)
> macros. And the reference in the help is exactly what you've quoted.
> Sorry that some Vim peculiarities are so hard to discover, but I guess
> that's the price one has to pay for such a powerful editor.

And one more hint in the help is
      :h map_return

it applies because arguments from :normal are like arguments from a
mapping (although :h :normal says "{commands} are executed like they are
typed." ... which is a bit misleading (it should say "{commands} are
executed like coming from a mapping"))

There is one weird detail though:
      Without [!], :normal continues.
      Same for a mapping for which remapping is allowed: it continues
      after the error.
I actually didn't notice this before.

--
Andy

--
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

Am 04.01.2013 22:22, schrieb Gary Johnson:
> On 2013-01-04, martinwguy wrote:
>> On 4 January 2013 14:34, Andy Wokula wrote:
>>> Am 03.01.2013 09:51, schrieb martinwguy:
>>>>> Is it a bug that '\' after '-' in a collection is taken literally?
>>>> No, that's normal vi behaviour.
>>> The context is Vim, not Vi:
>>>      :set nocp cpo&vim
>>
>> Er, I thought vim was a reimplementation of vi.
>
> It is.  To a point.  See
>
>      :help design-compatible
>      :help vi-differences
>
>>>> \ is not special in a character range (it stands for itself) and to
>>>> include ] you need to specify it as the first character in the range.
>>>
>>> Even with set 'cp', `\]' is still special.  See:
>>>      :h cpo-\
>>
>> Mmm, sorry, I don't know what :se cp/nocp is.
>
>      :help 'cp'
>
>>> Do you actually use Vi?
>>
>> Hum, it sounds like you're putting your fists up. Bad sign.
>> Yes, since 1982 for all my work. I am also the maintainer for another
>> vi clone, "xvi".
>> Is that enough for you?
>
> There are a couple of ways that question could be read.  I think
> Andy meant it as, "Do you use vi and not Vim?", and I think you
> took it as, "Do you know how to use vi?"

Yep, I meant the former.

Vim added the backslash for escaping within a collection, but it does so
inconsistently.  This has nothing to do with Vi.

--
Andy

--
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

Hi skeept,

can you give me a Win32.mak of Windows SDK 7? I only have Windows SDK
8 and VC2012 Express installed. and I can not build Vim with it.

how can I pass it without this file? can Bram make a patch to workaround it?

2012/11/10 skeept <skeept@...>:
> On Friday, November 9, 2012 5:39:32 PM UTC-5, skeept wrote:
>> Could anyone successfully compile vim in windows 8 with visual studio 12?
>>
>> I just installed the system yesterday, and I was trying to compile vim but I
am having issues.
>>
>> These are the steps:
>> first setting up the variables:
>> call "c:\Program Files (x86)\Microsoft Visual Studio
11.0\VC\bin\x86_amd64\vcvarsx86_amd64.bat"
>>
>> then
>> nmake -f Make_mvc.mak CPU=AMD64 GUI=yes
>>
>> this stops with the error:
>> Microsoft (R) Program Maintenance Utility Version 11.00.50727.1
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Make_mvc.mak(236) : fatal error U1052: file 'Win32.mak' not found
>> Stop.
>>
>>
>> I searched and found out that in windows 7 this file was under:
>> C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Include\Win32.Mak
>>
>> but with this in windows 8 I cannot find the file in the same folder (the
folder doesn't exist anymore).
>>
>> Any idea on how to solve this?
>>
>> Thanks!
>
> Copying the mentioned file from the old location to vim source fixes this,
should have thought of that before!
>
> Regards.
>
> --
> 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



--
regards,
Xavier Wang.

--
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

Hello!

I've put a new syntax/tex.vim on my website
(http://www.drchip.org/astronaut/vim/index.html#SYNTAX_TEX).  It uses a
new optional variable, g:tex_fast, to allow for fast syntax highlighting
with LaTeX/TeX.  I've included some additional text I'll be proposing to
Bram for inclusion in the help:

Finally, if syntax highlighting is still too slow, you may set
      :let g:tex_fast= 1
in your .vimrc.  This variable causes the syntax highlighting script to
avoid
defining any regions and associated synchronization.  The result will be
much
faster syntax highlighting; the price: you will no longer have as much
highlighting or any syntax-based folding, and you will be missing error
checking via highlighting.

Please let me know if some problem shows up with this new feature (other
than "folding doesn't work", "highlighting is missing", etc :) ).

Regards,
Chip 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

On Monday 07 January 2013 09:39:18 Ingo Karkat wrote:
> Yes it is. The beep that is issued is a clear indication of the error.

Apparently my speakers are disabled and visualbell is not set. That explains
why I was confused by the lack of feedback. :)

Thanks for clarifying that.

Best regards,
Mohammed

--
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

> Vim added the backslash for escaping within a collection, but it does so
> inconsistently.  This has nothing to do with Vi.

OK, my bad. I didn't know that vim was becoming deliberately
non-backward-compatible with standard vi.

Good luck resolving this issue in whatever way you think best

     M

--
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