The man.vim script assumes that foldcolumn and numberwidth are 0. If
they are not, the generated lines are too long.
Here's a patch to fix this:

~$ diff -u /usr/share/vim/vim70/ftplugin/man.vim
/home/guivho/.vim/ftplugin/man.vim
--- /usr/share/vim/vim70/ftplugin/man.vim       2006-10-20
11:48:47.000000000 +0200
+++ /home/guivho/.vim/ftplugin/man.vim  2006-12-03 09:15:37.000000000 +0100
@@ -141,7 +141,13 @@

     setl ma
     silent exec "norm 1GdG"
-  let $MANWIDTH = winwidth(0)
+  " leave room for foldcolumn and numberwidth
+  let s:notfree = &numberwidth + &foldcolumn
+  if &foldcolumn == 4
+    " one extra col allows for man pages > 999 lines, e.g. bash
+    let s:notfree = s:notfree + 1
+  endif
+  let $MANWIDTH = winwidth(0) - s:notfree
     silent exec "r!/usr/bin/man ".s:GetCmdArg(sect, page)." | col -b"
     " Remove blank lines from top and bottom.
     while getline(1) =~ '^\s*$'
~$

Guido

Guido Van Hoecke wrote:

> The man.vim script assumes that foldcolumn and numberwidth are 0. If
> they are not, the generated lines are too long.
> Here's a patch to fix this:
>
> ~$ diff -u /usr/share/vim/vim70/ftplugin/man.vim
> /home/guivho/.vim/ftplugin/man.vim
> --- /usr/share/vim/vim70/ftplugin/man.vim       2006-10-20
> 11:48:47.000000000 +0200
> +++ /home/guivho/.vim/ftplugin/man.vim  2006-12-03 09:15:37.000000000 +0100
> @@ -141,7 +141,13 @@
>
>     setl ma
>     silent exec "norm 1GdG"
> -  let $MANWIDTH = winwidth(0)
> +  " leave room for foldcolumn and numberwidth
> +  let s:notfree = &numberwidth + &foldcolumn
> +  if &foldcolumn == 4
> +    " one extra col allows for man pages > 999 lines, e.g. bash
> +    let s:notfree = s:notfree + 1
> +  endif
> +  let $MANWIDTH = winwidth(0) - s:notfree
>     silent exec "r!/usr/bin/man ".s:GetCmdArg(sect, page)." | col -b"
>     " Remove blank lines from top and bottom.
>     while getline(1) =~ '^\s*$'
> ~$

Do you really want line numbers and a foldcolumn in you man page window?
I suppose not.  Then it's easier to do

	 :setlocal nonumber foldcolumn=0

--
Windows
M!uqoms

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Hello,

I apologize if some of you are seeing this a second time, since I know
same people subscribe to both vim and vimdev. I thought I'd try the
vimdev list in case this is a bug.


Original Message:

When writing C syntax, every time I make a paren error it gets
highlighted. For example 'if (foo))', the second paren gets highlighted
as white on red. I guess it is because of my 'hi Error guibg=Red
guifg=White' in the colorscheme file.

Here is a problem: when the error is on the line my cursor is positioned
on and I have the 'set cursorline' in my gvimrc, all I see is a white
paren - no red background.

Is this a bug or a feature? If it is a feature, how do I make errors
stand out on highlighted lines? I noticed one other e-mail about mixing
colors of cursorline and normal syntax highlighting, but I think there
was no solution given?

-denis
--
// mailto: Denis Perelyubskiy <lists at overwhelmTAKECAPITALSOUT dot net>
// icq   : 12359698

Denis Perelyubskiy wrote:

> I apologize if some of you are seeing this a second time, since I know
> same people subscribe to both vim and vimdev. I thought I'd try the
> vimdev list in case this is a bug.
>
>
> Original Message:
>
> When writing C syntax, every time I make a paren error it gets
> highlighted. For example 'if (foo))', the second paren gets highlighted
> as white on red. I guess it is because of my 'hi Error guibg=Red
> guifg=White' in the colorscheme file.
>
> Here is a problem: when the error is on the line my cursor is positioned
> on and I have the 'set cursorline' in my gvimrc, all I see is a white
> paren - no red background.
>
> Is this a bug or a feature? If it is a feature, how do I make errors
> stand out on highlighted lines? I noticed one other e-mail about mixing
> colors of cursorline and normal syntax highlighting, but I think there
> was no solution given?

There is no solution.  The paren error highlighting is from the syntax
highlighting.  The cursorline highlighting needs to overrule the syntax
highlighting, otherwise it would disappear in several situations, esp.
if the syntax highlighting uses background highlighting.

--
     With sufficient thrust, pigs fly just fine.
                    -- RFC 1925

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Hi VIM developers,

I found a bug in VIM 7.0's new tr() function. If the {src} string contains
exactly 80 characters, an additional junk character is appended to the tr()
result; this happens regardless of whether a character translation has occurred
or not.

How to reproduce:
vim -u NONE
:echo
tr('1234567890123456789012345678901234567890123456789012345678901234567890123456\
7890', 'x', 'y')

Note: If {src} contains more or less than 80 characters, the bug does not occur.
If it occurs, it usually prints something like:
12345678901234567890123456789012345678901234567890123456789012345678901234567890\
^E
though the last junk character (^E) may differ.

Affected platforms:
I could reproduce this in console vim and gvim, on MS Windows XP SP2 and HP-UX
11.0 PA-RISC systems with the official, unpatched version 7.0, e.g.:
VIM - Vi IMproved 7.0 (2006 May 7, compiled May  7 2006 16:18:30)
MS-Windows 32 bit console version

I hope this helps. Keep up the good work, I use VIM daily and couldn't live
without it!

-- regards, ingo

/^-- Ingo Karkat -- /^-- /^-- /^-- /^-- /^-- /^-- http://ingo-karkat.de/ --

My favorite prime number is 57. Well, it certainly _looks_ prime, doesn't it?

Patch 7.0.175
Problem:    The result of tr() is missing the terminating NUL. (Ingo Karkat)
Solution:   Add the NUL.
Files:     src/eval.c


*** ../vim-7.0.174/src/eval.c Tue Nov 28 20:54:32 2006
--- src/eval.c Tue Dec  5 10:30:00 2006
***************
*** 16072,16077 ****
--- 16072,16081 ----
  	     ++instr;
  	 }
       }
+
+     /* add a terminating NUL */
+     ga_grow(&ga, 1);
+     ga_append(&ga, NUL);

       rettv->vval.v_string = ga.ga_data;
   }
*** ../vim-7.0.174/src/version.c Tue Nov 28 21:41:19 2006
--- src/version.c Tue Dec  5 10:32:58 2006
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     175,
   /**/

--
BLACK KNIGHT:  I move for no man.
ARTHUR:        So be it!
     [hah] [parry thrust]
     [ARTHUR chops the BLACK KNIGHT's left arm off]
ARTHUR:        Now stand aside, worthy adversary.
BLACK KNIGHT:  'Tis but a scratch.
                                   The Quest for the Holy Grail (Monty Python)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Ingo Karkat wrote:

> I found a bug in VIM 7.0's new tr() function. If the {src} string
> contains exactly 80 characters, an additional junk character is
> appended to the tr() result; this happens regardless of whether a
> character translation has occurred or not.
>
> How to reproduce:
> vim -u NONE
> :echo
tr('1234567890123456789012345678901234567890123456789012345678901234567890123456\
7890', 'x', 'y')
>
> Note: If {src} contains more or less than 80 characters, the bug does
> not occur. If it occurs, it usually prints something like:
>
12345678901234567890123456789012345678901234567890123456789012345678901234567890\
^E
> though the last junk character (^E) may differ.
>
> Affected platforms:
> I could reproduce this in console vim and gvim, on MS Windows XP SP2
> and HP-UX 11.0 PA-RISC systems with the official, unpatched version
> 7.0, e.g.:
> VIM - Vi IMproved 7.0 (2006 May 7, compiled May  7 2006 16:18:30)
> MS-Windows 32 bit console version
>
> I hope this helps. Keep up the good work, I use VIM daily and couldn't
> live without it!

That's a bug.  There is no terminating NUL.  I'll make a patch.

--
ARTHUR:        I command you as King of the Britons to stand aside!
BLACK KNIGHT:  I move for no man.
                                   The Quest for the Holy Grail (Monty Python)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.176
Problem:    ":emenu" isn't executed directly, causing the encryption key
	     prompt to fail. (Life Jazzer)
Solution:   Fix wrong #ifdef.
Files:     src/menu.c


*** ../vim-7.0.175/src/menu.c Wed Aug 16 21:42:34 2006
--- src/menu.c Wed Nov 29 21:15:36 2006
***************
*** 2246,2252 ****
       {
  	 /* When executing a script or function execute the commands right now.
  	  * Otherwise put them in the typeahead buffer. */
! #ifdef FEAT_En
  	 if (current_SID != 0)
  	     exec_normal_cmd(menu->strings[idx], menu->noremap[idx],
  							    menu->silent[idx]);
--- 2246,2252 ----
       {
  	 /* When executing a script or function execute the commands right now.
  	  * Otherwise put them in the typeahead buffer. */
! #ifdef FEAT_EVAL
  	 if (current_SID != 0)
  	     exec_normal_cmd(menu->strings[idx], menu->noremap[idx],
  							    menu->silent[idx]);
*** ../vim-7.0.175/src/version.c Tue Dec  5 10:33:57 2006
--- src/version.c Tue Dec  5 21:31:03 2006
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     176,
   /**/

--
-rwxr-xr-x  1 root          24 Oct 29  1929 /bin/ed
-rwxr-xr-t  4 root      131720 Jan  1  1970 /usr/ucb/vi
-rwxr-xr-x  1 root  5.89824e37 Oct 22  1990 /usr/bin/emacs

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.177
Problem:    When the press-enter prompt gets a character from a non-remappable
	     mapping, it's put back in the typeahead buffer as remappable,
	     which may cause an endless loop.
Solution:   Restore the non-remappable flag and the silent flag when putting a
	     char back in the typeahead buffer.
Files:     src/getchar.c, src/message.c, src/normal.c


*** ../vim-7.0.176/src/getchar.c Tue Oct  3 15:36:09 2006
--- src/getchar.c Tue Dec  5 21:17:42 2006
***************
*** 76,82 ****
    */
   static mapblock_T *first_abbr = NULL; /* first entry in abbrlist */

! static int  KeyNoremap = FALSE; /* remapping disabled */

   /*
    * variables used by vgetorpeek() and flush_buffers()
--- 76,82 ----
    */
   static mapblock_T *first_abbr = NULL; /* first entry in abbrlist */

! static int  KeyNoremap = 0;     /* remapping flags */

   /*
    * variables used by vgetorpeek() and flush_buffers()
***************
*** 1035,1040 ****
--- 1037,1044 ----
   /*
    * Put character "c" back into the typeahead buffer.
    * Can be used for a character obtained by vgetc() that needs to be put back.
+  * Uses cmd_silent, KeyTyped and KeyNoremap to restore the flags belonging to
+  * the char.
    */
       void
   ins_char_typebuf(c)
***************
*** 1061,1067 ****
  	 buf[1] = NUL;
   #endif
       }
!     (void)ins_typebuf(buf, REMAP_YES, 0, !KeyTyped, FALSE);
   }

   /*
--- 1065,1071 ----
  	 buf[1] = NUL;
   #endif
       }
!     (void)ins_typebuf(buf, KeyNoremap, 0, !KeyTyped, cmd_silent);
   }

   /*
***************
*** 2270,2278 ****
  					 gotchars(typebuf.tb_buf
  							  + typebuf.tb_off, 1);
  				     }
! 				    KeyNoremap = (typebuf.tb_noremap[
! 						   typebuf.tb_off]
! 						       & (RM_NONE|RM_SCRIPT));
  				     del_typebuf(1, 0);
  				 }
  				 break;     /* got character, break for loop */
--- 2276,2283 ----
  					 gotchars(typebuf.tb_buf
  							  + typebuf.tb_off, 1);
  				     }
! 				    KeyNoremap = typebuf.tb_noremap[
! 							      typebuf.tb_off];
  				     del_typebuf(1, 0);
  				 }
  				 break;     /* got character, break for loop */
***************
*** 4196,4202 ****

       if (typebuf.tb_no_abbr_cnt) /* abbrev. are not recursive */
  	 return FALSE;
!     if (KeyNoremap)  /* no remapping implies no abbreviation */
  	 return FALSE;

       /*
--- 4201,4208 ----

       if (typebuf.tb_no_abbr_cnt) /* abbrev. are not recursive */
  	 return FALSE;
!     if ((KeyNoremap & (RM_NONE|RM_SCRIPT)) != 0)
!  /* no remapping implies no abbreviation */
  	 return FALSE;

       /*
*** ../vim-7.0.176/src/normal.c Tue Nov  7 18:43:10 2006
--- src/normal.c Tue Dec  5 21:16:07 2006
***************
*** 651,659 ****
  	 /* Fake a "c"hange command.  When "restart_edit" is set (e.g., because
  	  * 'insertmode' is set) fake a "d"elete command, Insert mode will
  	  * restart automatically.
! 	 * Insert the typed character in the typeahead buffer, so that it will
! 	 * be mapped in Insert mode.  Required for ":lmap" to work.  May cause
! 	 * mapping a character from ":vnoremap"... */
  	 ins_char_typebuf(c);
  	 if (restart_edit != 0)
  	     c = 'd';
--- 651,658 ----
  	 /* Fake a "c"hange command.  When "restart_edit" is set (e.g., because
  	  * 'insertmode' is set) fake a "d"elete command, Insert mode will
  	  * restart automatically.
! 	 * Insert the typed character in the typeahead buffer, so that it can
! 	 * be mapped in Insert mode.  Required for ":lmap" to work. */
  	 ins_char_typebuf(c);
  	 if (restart_edit != 0)
  	     c = 'd';
*** ../vim-7.0.176/src/version.c Tue Dec  5 21:32:00 2006
--- src/version.c Tue Dec  5 21:36:07 2006
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     177,
   /**/

--
5 out of 4 people have trouble with fractions.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Patch 7.0.178
Problem:    When 'enc' is "utf-8" and 'ignorecase' is set the result of ":echo
	     ("\xe4" == "\xe4")" varies.
Solution:   In mb_strnicmp() avoid looking past NUL bytes.
Files:     src/mbyte.c


*** ../vim-7.0.177/src/mbyte.c Wed Nov  1 18:10:36 2006
--- src/mbyte.c Tue Dec  5 22:04:34 2006
***************
*** 2294,2301 ****
--- 2294,2307 ----
  	     }
  	     /* Check directly first, it's faster. */
  	     for (j = 0; j < l; ++j)
+ 	    {
  		 if (s1[i + j] != s2[i + j])
  		     break;
+ 	 if (s1[i + j] == 0)
+ 		    /* Both stings have the same bytes but are incomplete or
+ 		     * have illegal bytes, accept them as equal. */
+ 		    l = j;
+ 	    }
  	     if (j < l)
  	     {
  		 /* If one of the two characters is incomplete return -1. */
*** ../vim-7.0.177/src/version.c Tue Dec  5 21:45:20 2006
--- src/version.c Tue Dec  5 22:08:08 2006
***************
*** 668,669 ****
--- 668,671 ----
   {   /* Add new patch number below this line */
+ /**/
+     178,
   /**/

--
Trees moving back and forth is what makes the wind blow.

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Hmm, the subject should have been "patch 7.0.175".  Remove the "about"!
Hopefully no scripts got confused by this.

--
BLACK KNIGHT:  Come on you pansy!
     [hah] [parry thrust]
     [ARTHUR chops the BLACK KNIGHT's right arm off]
ARTHUR:        Victory is mine!  [kneeling]
                We thank thee Lord, that in thy merc-
     [Black Knight kicks Arthur in the head while he is praying]
                                   The Quest for the Holy Grail (Monty Python)

  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

I have run across a rather strange error in the syntax highlighting for
either vb.vim or html.vim.  I'm unsure which is causing the problem.
Here are the circumstances under which this error occurs:

I am developing an HTA program.  An HTA program (for those who do not
use Windows) is an HTML executable program.  I'm using vbscript inside
of the HTML via the <script> tag to write a small program.  What happens
is that if multiple lines of comments in a vbscript are placed together
with several single character comments sparced between the longer
comments, then for some reason all of the code is marked as "Normal" in
the syntax coloring.  Once this happens, various things such as the "<>"
in IF statements turn red (I haven't figured out which syntax coloration
this is) and other statements turn green (again, I am still tracking
down which of the syntax commands this represents in my color scheme).

I was wondering if anyone else has run across this problem?  Here is
(off the top of my head) an example of what seems to cause this problem:

Example:

<html>
<head>
<title>Test Program</title>
<script language="vbscript">
     dim i
     dim a
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\
'''''''''''''''''''''''''''''
'BEGIN DOC
'
'-Calling Sequence:
'
'   myFunc()
'
'-Description:
'
'   This function does nothing.
'
'-Inputs:
'
'   None.
'
'-Outputs:
'
'   None.
'
'END DOC
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''\
'''''''''''''''''''''''''''''''''
     set objFSO = CreateObject( "whatever.FileSystem.Object" )
     set objFile = CreateTextFile( "myfile.dat" )
     set anotherObj = "About this time the lines should turn all one color."

     objFSO.stdout.Write "I know this isn't good vbscript - it's just for
show"
</script>
</head>

<body>
Test program
</body>
</html>

Usually, as the above line says, all of the lines turn one color.  If
this doesn't do it for you, then I'll see about sending some code from
work that this happens on.  But it will look a lot like the above.  :-)

On 12/6/06, Bram Moolenaar <Bram@...> wrote:
>
> Hmm, the subject should have been "patch 7.0.175".  Remove the "about"!
> Hopefully no scripts got confused by this.

Many scripts will got confused, I think. :-P

Fortunately I don't use script. I do my job manually because the
censorship makes the network situation so bad that the script cannot
handle many unexpected situations.

>
> --
> BLACK KNIGHT:  Come on you pansy!
>     [hah] [parry thrust]
>     [ARTHUR chops the BLACK KNIGHT's right arm off]
> ARTHUR:        Victory is mine!  [kneeling]
>                We thank thee Lord, that in thy merc-
>     [Black Knight kicks Arthur in the head while he is praying]
>                                   The Quest for the Holy Grail (Monty Python)
>
>  /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net   \\\
> ///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\        download, build and distribute -- http://www.A-A-P.org        ///
>  \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
>

The message cannot be represented in 7-bit ASCII encoding and has been sent as a
binary attachment.

Mohsin wrote:
> Is it possible to display (highlight) matches for /Word
> simultaneously in 3 different colors:
>
>  1. Word              .. hlsearch
>  2. \<Word\>       .. hlsearchword
>  3. (?i)word          .. hlsearchicase
>
> how hard would it be? I don't want to use script to it.
> thanks,
> mohsin.
>

Maybe you can do the following (untested):

	 :map <Bslash>/ :match DiffAdd /<Bslash><lt><C-R>/<Bslash><gt>/<CR>
	 :map <Bslash>? :2match DiffChange /<Bslash>c<C-R>//<CR>

- Search normally for case 1.
- Hit \/ to highlight the latest search in DiffAdd colours (by default in
gvim: black on pale cyan) but only when present as a full word (case 2).
- Hit \? to highlight the latest search in DiffChange highlight (black on pale
magenta) regardless of case (case 3).
- Hit \/ or \? again to update the highlights. Type ":match none" or ":2match
none" to clear them.
- Change the highlight group names if you want different colours.

If, to you, this is already "script", then you would need to hack the C source
to get the desired result "without script"; but I wouldn't recommend it for
something this trivial, which can be accomplished by a couple of mappings or
(in a less obvious way) by using self-modifying mappings (map / to change the
way we search and, in the mapping, cmap <CR> to both finalize the first
mapping and unmap the second one...).


Best regards,
Tony.

Is it possible to display (highlight) matches for /Word
simultaneously in 3 different colors:

   1. Word              .. hlsearch
   2. \<Word\>       .. hlsearchword
   3. (?i)word          .. hlsearchicase

how hard would it be? I don't want to use script to it.
thanks,
mohsin.

Mechelynck,

It has to be done with one mapping, the reason being *simultaneous*
display, since
sometimes the same word is with wrong case, should be immediately visible
without having to make a mental switch to find it.

I will try using with the syntax/highlight mappings.
thanks,
mohsin.


On 12/6/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:
> Mohsin wrote:
> > Is it possible to display (highlight) matches for /Word
> > simultaneously in 3 different colors:
> >
> >  1. Word              .. hlsearch
> >  2. \<Word\>       .. hlsearchword
> >  3. (?i)word          .. hlsearchicase
> >
> > how hard would it be? I don't want to use script to it.
> > thanks,
> > mohsin.
> >
>
> Maybe you can do the following (untested):
>
>         :map <Bslash>/ :match DiffAdd /<Bslash><lt><C-R>/<Bslash><gt>/<CR>
>         :map <Bslash>? :2match DiffChange /<Bslash>c<C-R>//<CR>
>
> - Search normally for case 1.
> - Hit \/ to highlight the latest search in DiffAdd colours (by default in
> gvim: black on pale cyan) but only when present as a full word (case 2).
> - Hit \? to highlight the latest search in DiffChange highlight (black on pale
> magenta) regardless of case (case 3).
> - Hit \/ or \? again to update the highlights. Type ":match none" or ":2match
> none" to clear them.
> - Change the highlight group names if you want different colours.
>
> If, to you, this is already "script", then you would need to hack the C source
> to get the desired result "without script"; but I wouldn't recommend it for
> something this trivial, which can be accomplished by a couple of mappings or
> (in a less obvious way) by using self-modifying mappings (map / to change the
> way we search and, in the mapping, cmap <CR> to both finalize the first
> mapping and unmap the second one...).
>
>
> Best regards,
> Tony.
>

Mohsin wrote:
> Mechelynck,
>
> It has to be done with one mapping, the reason being *simultaneous*
> display, since
> sometimes the same word is with wrong case, should be immediately visible
> without having to make a mental switch to find it.
>
> I will try using with the syntax/highlight mappings.
> thanks,
> mohsin.

Well, I won't give you an answer, because I'm too liable to stumble while
writing it, but here is how it can be done:

- Make a permanent mapping for / and ?. Each of them should, as part of the
{rhs}, issue a cmap for <CR> (see below), and map the start of the search
command, until but not including the start of the search pattern.

- The cmap should not only finalize the search command but also issue :match
and :2match with the variable part represented by <C-R>/ (Ctrl-R slash), and
finally it should also unmap itself (and the next mapping) so the next use of
<Enter> (or <Esc>) in command mode should not invoke these special cmaps.

- If you want completeness, the maps for / and ? should also create a
temporary cmap for <Esc> to cancel the search, and also unmap itself and the
cmap for <CR>.

I think it is doable, but it's not my province really. Some other Vim
old-timers are much more versed than I in the creation of that kind of
"self-undoing" mappings.


Best regards,
Tony.

On 12/6/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:

> I think it is doable, but it's not my province really. Some other Vim
> old-timers are much more versed than I in the creation of that kind of
> "self-undoing" mappings.

It can probably be simplified by mapping <CR> in command mode and
check if getcmdtype() is '/' or '?' and, if so, call :match as
appropriate.

However, there's no good way of doing this type of highlighting while
in 'incsearch' mode (i.e., while typing the pattern).

Anyway, here's something I cooked up for you 'incsearch' users that
actually thought this was sort of a neat idea, i.e., being able to
quickly toggle between the word anywhere in the buffer, the complete
word, and the case insensitive word.  It definitely needs work to deal
with anything but trivial patterns, e.g., only wrap the word under the
cursor, but you probably only want to do this for simple, word-type
patterns.

cmap <C-I> <C-\>e<SID>toggle_word_style()<CR>

let s:word_types = [
       \ [ '^\\<\|\\>$', "", 'g', '\c', "" ],
       \ [ '^\\c', "", "", "", "" ],
       \ [ '^', "", "", '\<', '\>' ]
       \ ]

function! s:toggle_word_style()
   let line = getcmdline()
   let type = getcmdtype()

   if type != '/' && type != '?'
     return line
   endif

   for word_type in s:word_types
     if line =~ word_type[0]
       let line = word_type[3] .
                \ substitute(line, word_type[0], word_type[1], word_type[2]) .
                \ word_type[4]
       call setcmdpos(len(line) + 1)
       return line
     endif
   endfor

   return line
endfunction

Actually sort of neat, although it's not what Mohsin wants.

   nikolai

Hello Vim Developers,

Here's what the docs say:

===============================================================================
                                                 *^*
^               To the first non-blank character of the line.
                 |exclusive| motion.

                                                 *0*
0               To the first character of the line.  |exclusive|
                 motion.  When moving up or down, stay in same screen
                 column (if possible).

                                                 *<Home>* *<kHome>*
<Home>          To the first character of the line.  |exclusive|
                 motion.  When moving up or down, stay in same text
                 column (if possible).  Works like "1|", which differs
                 from "0" when the line starts with a <Tab>.  {not in
                 Vi}

                                                 *bar*
|               To screen column [count] in the current line.
                 |exclusive| motion.
===============================================================================

(1) The sentence starting with "When moving" (in the help
     for both '0' and '<Home>' appears to also belong with
     the help for '^'.

(2) The sentence starting with "Works like" (in the help for
     '<Home>') does not appear to be correct.  '<Home>'
     appears to work like '0'.  The movement is just like
     '1|' (which is equivalent to '|') except for the
     behavior of moving up or down.

(3) '0' and '<Home>' appear to be identical.  Does anyone
     see a difference?

--
Best regards,
Bill

On 12/7/06, Nikolai Weibull <now@...> wrote:
> On 12/6/06, A.J.Mechelynck <antoine.mechelynck@...> wrote:
>
> > I think it is doable, but it's not my province really. Some other Vim
> > old-timers are much more versed than I in the creation of that kind of
> > "self-undoing" mappings.
>
> It can probably be simplified by mapping <CR> in command mode and
> check if getcmdtype() is '/' or '?' and, if so, call :match as
> appropriate.

Hm, you of course need to know how you got /into/ search mode, so that
you only do this at the appropriate times.  Setting a variable and
checking for it would work, but you have to make sure to unset it if
the command line is abandoned as well.  We need
CmdLineEnter/CmdLineLeave and v:cmdexecuted or some such, so that we
can tell if the line was executed or not.  Or perhaps even better:
CmdLineEnter/CmdLineLeave/CmdLineExecutePre/CmdLineExecutePost.  With
the *Pre autocmd one can perhaps change the command line in some way
before executing it.  With *Post one can do stuff after it, like
:matching.  *Leave would be called when it is abandoned, although
perhaps the name suggests other cases as well?

Anyway, good night.

   nikolai

Hello All,

I've found two tasks that are done in vim scripts routinely and it would be nice
to streamline them:

Here's the first one: "If some variable isn't set yet, then set it to a default
value". The code always looks something like this:

if !exists("g:MyScriptSetting")
   let g:MyScriptSetting = "default_value"
endif

To make this easier, I would love to see is the vim 7.0 "get()" function
expanded to handle regular variables. The get() function is currently defined
this way:
get({list}, {idx} [, {default}])
                                Get item {idx} from List {list}.  When this item
is not
                                available return {default}.  Return zero when
{default} is
                                omitted.
get({dict}, {key} [, {default}])
                                Get item with key {key} from Dictionary {dict}. 
When this
                                item is not available return {default}.  Return
zero when
                                {default} is omitted.

How about adding this:
get({string} [, {default}])
                                Get value from variable {string}.  When this
variable does not
                                exist, return {default}.  Return zero when
{default} is
                                omitted.

The second one is: "Make these vim settings during this function call only, so
save the current values first, set them to what I want, then restore them before
leaving". There is an item on the TODO list to make this easier:

":with option=value | command": temporarily set an option value and restore it
after the command has executed.

The problem is that this could get ugly if many options need to be changed, and
those settings have to be made *every time* the routine is called. Typically,
the function only works correctly when those settings are set. It would be nice
to see something like the current setlocal command instead:

:sett[emp] ...                    
Like ":set" but set only the value local to the current function.  The value is
restored to the value set before the current function was called when the
function ends. Not valid outside of a
function.

What do you think?

David

Bill McCarthy wrote:
> Hello Vim Developers,
>
> Here's what the docs say:
>
>
===============================================================================
>                                                 *^*
> ^               To the first non-blank character of the line.
>                 |exclusive| motion.
>
>                                                 *0*
> 0               To the first character of the line.  |exclusive|
>                 motion.  When moving up or down, stay in same screen
>                 column (if possible).
>
>                                                 *<Home>* *<kHome>*
> <Home>          To the first character of the line.  |exclusive|
>                 motion.  When moving up or down, stay in same text
>                 column (if possible).  Works like "1|", which differs
>                 from "0" when the line starts with a <Tab>.  {not in
>                 Vi}
>
>                                                 *bar*
> |               To screen column [count] in the current line.
>                 |exclusive| motion.
>
===============================================================================
>
> (1) The sentence starting with "When moving" (in the help
>     for both '0' and '<Home>' appears to also belong with
>     the help for '^'.
>
> (2) The sentence starting with "Works like" (in the help for
>     '<Home>') does not appear to be correct.  '<Home>'
>     appears to work like '0'.  The movement is just like
>     '1|' (which is equivalent to '|') except for the
>     behavior of moving up or down.
>
> (3) '0' and '<Home>' appear to be identical.  Does anyone
>     see a difference?
>

(1) After ^ followed by jjjjj or kkkkk I see the cursor staying (as far as
possible) in the same _screen_ column regardless of preceding hard tabs. When
this would place the cursor halfway a tab, the cursor will shift temporarily,
and come back if you go on hitting j or k. This is normal behaviour when
moving up or down, so it doesn't need to be mentioned.

(2) Here, <Home> works like 1| (not like 0), see below.

(3) Yes I do. Notice the one mentions "the same _text_ column" and the other
"the same _screen_ column". Hit 0 on a line starting with a hard tab, then
jjjjj : Vim will try to keep the cursor in column 8 (except, of course, on
lines shorter than 1 tab or 8 other characters). After <Home> or 1| it would
try to keep the cursor in column 1 (if possible: when the first character on a
line is a hard tab the cursor will move temporarily to column 8).

I have

*motion.txt*    For Vim version 7.0.  Last change: 2006 Jun 18
[...] (next line is #170)
							 *0*
0 	 To the first character of the line.  |exclusive|
			 motion.  When moving up or down, stay in same screen
			 column (if possible).

							 *<Home>* *<kHome>*
<Home> 	 To the first character of the line.  |exclusive|
			 motion.  When moving up or down, stay in same text
			 column (if possible).  Works like "1|", which differs
			 from "0" when the line starts with a <Tab>.  {not in
			 Vi}

							 *^*
^ 	 To the first non-blank character of the line.
			 |exclusive| motion.
[...] (next line is #235)
							 *bar*
| 	 To screen column [count] in the current line.
			 |exclusive| motion.

and

VIM - Vi IMproved 7.0 (2006 May 7, compiled Dec  5 2006 22:18:11)
Included patches: 1-178
Compiled by antoine.mechelynck@...
Huge version with GTK2-GNOME GUI.  Features included (+) or not (-):
[etc.]


Best regards,
Tony.

Hello,

* On Wed, Dec 06, 2006 at 04:11:24PM -0800, Eggum, DavidX S
<davidx.s.eggum@...> wrote:
> I've found two tasks that are done in vim scripts routinely and it
> would be nice to streamline them:
>
> Here's the first one: "If some variable isn't set yet, then set it to
> a default value". The code always looks something like this:
>
> if !exists("g:MyScriptSetting")
>    let g:MyScriptSetting = "default_value"
> endif
>
> How about adding this:
> [...]
> get({string} [, {default}])
>            value from variable {string}.  When this variable does not
>            exist, return {default}.  Return zero when {default} is
>            omitted.

Well, I've started to refactor my plugins to isolate a similar similar
function in an autoload plugin. My function also takes another argument:
a list of scopes in which the variable can be defined.

" Function: lh#option#Get({name}, {default} [, {scope}])
" @return b:{name} if it exists, of g:{name} if it exists, or {default}
" otherwise
" The order of the variables checked can be specified through the optional
" argument {scope}

Then, in my script, I systematically call this function, and never
directly use a variable. Indeed, I have no way of knowing if the
variable is b:goo, g:foo, w:foo or even s:foo.

The support of non global options is very important to me as I mainly
maintain ftplugins, and work on the files from various projects that
don't share the same configuration (like different targets used in the
makefiles).

A typical use is:
     let l:foo = lh#option#Get('foo', s:foo_default, 'wbg')
Which will return the value of the first variable found among w:foo,
b:foo and g:foo. Or s:foo_default otherwise.

So far, {default} is not optional as I have both integer and string
variables, and I can't easily tell the exact type of the variable.

Having such function as builtin would be nice. I can easily cope without
it. But still, it would be nice.

--
Luc Hermitte
http://hermitte.free.fr/vim/

On Wed 6-Dec-06 6:24pm -0600, A.J.Mechelynck wrote:

> Bill McCarthy wrote:

>> (3) '0' and '<Home>' appear to be identical.  Does anyone
>>     see a difference?

> (3) Yes I do. Notice the one mentions "the same _text_
> column" and the other "the same _screen_ column". Hit 0 on
> a line starting with a hard tab, then jjjjj : Vim will try
> to keep the cursor in column 8 (except, of course, on
> lines shorter than 1 tab or 8 other characters). After
> <Home> or 1| it would try to keep the cursor in column 1
> (if possible: when the first character on a line is a hard
> tab the cursor will move temporarily to column 8).

Thanks Tony, that clears it up nicely.  Somehow I just
wasn't seeing the difference - I certainly see it now!

--
Best regards,
Bill

Hello, vim-developers!

   It is still impossible to use multibyte characters in langmaps,
   when main Vim encoding is set to UTF-8.
   As far as I remember in mid-october there was a patch submitted by
   Konstantin Korikov <lostclus@...>, which allows using
   multibyte characters in langmaps.
   Will this patch becomes 'official' one?

--
Best regards,
  Valery Kondakoff                          mailto:strauss@...

PGP key: mailto:pgp-public-keys@...?subject=GET%20strauss@...

np: (Player is not active)

Valery Kondakoff wrote:
> Hello, vim-developers!
>
>   It is still impossible to use multibyte characters in langmaps,
>   when main Vim encoding is set to UTF-8.
>   As far as I remember in mid-october there was a patch submitted by
>   Konstantin Korikov <lostclus@...>, which allows using
>   multibyte characters in langmaps.
>   Will this patch becomes 'official' one?
>

According to ":help 'langmap'", the value may be specified using multibyte
characters but only the lower 8 bits will be used. I suppose some collisions
might happen; but since keyboards usually have only a hundred keys or so, it
might be quite possible that each key gives a different lower-8-bits (255
possibilities) in which case 'langmap' would, I suppose, be usable.


Best regards,
Tony.

Since no one had mentioned it yet; the scripts appear to be inaccessible.
Clicking on "top rated" yields:

Can't open file: 'vs_scripts.MYI' (errno: 145)

Regards,
Chip Campbell

Hi! This is the ezmlm program. I'm managing the
vim-dev@... mailing list.


Messages to you from the vim-dev mailing list seem to
have been bouncing. I sent you a warning message, but it bounced.
I've attached a copy of the bounce message.

This is a probe to check whether your address is reachable. If this
probe bounces, I will remove your address from the
vim-dev@... mailing list, without further notice. You can re-subscribe
by sending an empty message to the following address:
    <vim-dev-subscribe@...>


--- Enclosed is a copy of the bounce message I received.

Return-Path: <>
Received: (qmail 26607 invoked for bounce); 25 Nov 2006 22:45:44 -0000
Date: 25 Nov 2006 22:45:44 -0000
From: MAILER-DAEMON@...
To:
vim-dev-return-warn-1164475143.gpojcjfgjcghddlfipke-listsaver-of-vimdev=yahoogro\
ups.com@...
Subject: failure notice

Hi. This is the qmail-send program at foobar.math.fu-berlin.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<listsaver-of-vimdev@yahoogroups.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

--- Below this line is a copy of the message.

Return-Path:
<vim-dev-return-warn-1164475143.gpojcjfgjcghddlfipke-listsaver-of-vimdev=yahoogr\
oups.com@...>
Received: (qmail 25256 invoked by uid 200); 25 Nov 2006 17:19:03 -0000
Mailing-List: contact vim-dev-help@...; run by ezmlm
Date: 25 Nov 2006 17:19:03 -0000
Message-ID: <1164475143.25254.ezmlm-warn@...>
From: vim-dev-help@...
To: listsaver-of-vimdev@yahoogroups.com
Content-type: text/plain; charset=us-ascii
Subject: ezmlm warning

Hi! This is the ezmlm program. I'm managing the
vim-dev@... mailing list.


Messages to you from the vim-dev mailing list seem to
have been bouncing. I've attached a copy of the first bounce
message I received.

If this message bounces too, I will send you a probe. If the probe bounces,
I will remove your address from the vim-dev mailing list,
without further notice.


I've kept a list of which messages from the vim-dev mailing list have
bounced from your address.

Copies of these messages may be in the archive.
To retrieve a set of messages 123-145 (a maximum of 100 per request),
send an empty message to:
    <vim-dev-get.123_145@...>

To receive a subject and author list for the last 100 or so messages,
send an empty message to:
    <vim-dev-index@...>

Here are the message numbers:

    36658
    36674
    36675
    36677
    36678
    36681
    36686
    36687
    36694
    36696
    36698
    36700
    36699
    36703
    36702
    36704
    36705
    36706
    36708
    36707
    36709
    36712
    36714
    36720
    36721
    36723
    36727
    36729
    36735

--- Enclosed is a copy of the bounce message I received.

Return-Path: <>
Received: (qmail 11739 invoked for bounce); 13 Nov 2006 22:18:33 -0000
Date: 13 Nov 2006 22:18:33 -0000
From: MAILER-DAEMON@...
To: vim-dev-return-36658-@...
Subject: failure notice

Hi. This is the qmail-send program at foobar.math.fu-berlin.de.
I'm afraid I wasn't able to deliver your message to the following addresses.
This is a permanent error; I've given up. Sorry it didn't work out.

<listsaver-of-vimdev@yahoogroups.com>:
Sorry, I wasn't able to establish an SMTP connection. (#4.4.1)
I'm not going to try again; this message has been in the queue too long.

On 12/7/06, Eggum, DavidX S <davidx.s.eggum@...> wrote:
> Confirmed, I see it too...

And I can confirm receiving your confirmation.

   nikolai