Patch 7.0.122

2006-10-09 Thread Bram Moolenaar

Patch 7.0.122
Problem:GUI: When clearing after a bold, double-wide character half a
character may be drawn.
Solution:   Check for double-wide character and redraw it. (Yukihiro Nakadaira)
Files:  src/screen.c


*** ../vim-7.0.121/src/screen.c Thu Sep 14 21:04:09 2006
--- src/screen.cSat Oct  7 15:13:43 2006
***
*** 5079,5093 
 * character too.  If we didn't skip any blanks above, then we
 * only redraw if the character wasn't already redrawn anyway.
 */
!   if (gui.in_use && (col > startCol || !redraw_this)
! # ifdef FEAT_MBYTE
!   && enc_dbcs == 0
! # endif
!  )
{
hl = ScreenAttrs[off_to];
if (hl > HL_ALL || (hl & HL_BOLD))
!   screen_char(off_to - 1, row, col + coloff - 1);
}
  #endif
screen_fill(row, row + 1, col + coloff, clear_width + coloff,
--- 5079,5116 
 * character too.  If we didn't skip any blanks above, then we
 * only redraw if the character wasn't already redrawn anyway.
 */
!   if (gui.in_use && (col > startCol || !redraw_this))
{
hl = ScreenAttrs[off_to];
if (hl > HL_ALL || (hl & HL_BOLD))
!   {
!   int prev_cells = 1;
! # ifdef FEAT_MBYTE
!   if (enc_utf8)
!   /* for utf-8, ScreenLines[char_offset + 1] == 0 means
!* that its width is 2. */
!   prev_cells = ScreenLines[off_to - 1] == 0 ? 2 : 1;
!   else if (enc_dbcs != 0)
!   {
!   /* find previous character by counting from first
!* column and get its width. */
!   unsigned off = LineOffset[row];
! 
!   while (off < off_to)
!   {
!   prev_cells = (*mb_off2cells)(off);
!   off += prev_cells;
!   }
!   }
! 
!   if (enc_dbcs != 0 && prev_cells > 1)
!   screen_char_2(off_to - prev_cells, row,
!  col + coloff - prev_cells);
!   else
! # endif
!   screen_char(off_to - prev_cells, row,
!  col + coloff - prev_cells);
!   }
}
  #endif
screen_fill(row, row + 1, col + coloff, clear_width + coloff,
*** ../vim-7.0.121/src/version.cSun Oct  8 13:56:53 2006
--- src/version.c   Mon Oct  9 22:10:17 2006
***
*** 668,669 
--- 668,671 
  {   /* Add new patch number below this line */
+ /**/
+ 122,
  /**/

-- 
How To Keep A Healthy Level Of Insanity:
7. Finish all your sentences with "in accordance with the prophecy".

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- 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///


Re: bugs in vim scripting highlighting

2006-10-09 Thread Benji Fisher
On Tue, Oct 03, 2006 at 12:00:23PM +0200, Mikolaj Machowski wrote:
> Hello,
> 
> Noticed two bugs in vim script highlighting:
> 
> 1. xnoremap and snoremap are not fully recognized. Compare highlighting
>of those three lines:
> 
>   inoremap CtrlC()
>   xnoremap CtrlC()
>   snoremap CtrlC()
> 
>Arguments of xnoremap and snoremap aren't highlighted
> 
> 2. Function element addButton is highlighted as error:
> 
> function! forms#form.addButton(fname, flabel, fvalue, hotkey, listener)
> 
>But it works (as in forms.vim). the same apply to call call.
> 
> syntax/vim.vim version: 
> " Last Change:May 02, 2006
> " Version:7.0-50
> 
> m.

 There is a more recent version at

ftp://ftp.vim.org/pub/vim/runtime/syntax/vim.vim

If that does not solve the problem, then you should e-mail the
maintainer directly.  (Dr. C, a.k.a. Chip Campbell, usually follows this
list, but a direct e-mail is more reliable.)  The Maintainer line is
just above the Last Change line you quoted; you will have to remove the
non-contiguous letters "NOSPAM" to un-obfuscate the e-mail address.

HTH --Benji Fisher


Re: New Versions of 4nt and tcmd

2006-10-09 Thread Martin Krischik
Am Montag, 9. Oktober 2006 02:31 schrieb Bill McCarthy:

> On Sun 8-Oct-06 7:29pm -0600, Bill McCarthy wrote:

> > New versions of 4nt and tcmd were recently loaded to the FTP
> > site.  These are still called 8.00.49.  What is the
> > difference?

I am still on 6.x and wonder whats the difference...

> Sorry, I sent that to the wrong email address.

;-)

Martin
-- 
Martin Krischik
mailto://[EMAIL PROTECTED]


pgphpIpesA9EK.pgp
Description: PGP signature


Re: [BOF] Killer feature

2006-10-09 Thread Aaron Griffin

On 10/7/06, Martin Krischik <[EMAIL PROTECTED]> wrote:

Eclipse-Integration

And yes, I already voted on it. I soon have to work with Eclipse - no two ways
around it. And I don't think I am the only one. And while Eclipse has tons of
features when it comes to text editing it's just another CUA Editor.


Don't forget visual studio too!


Re: Vim 7.0 (1-109 patches) completion bug.

2006-10-09 Thread Mikolaj Machowski
Dnia poniedziałek, 9 października 2006 12:38, Igor Prischepoff napisał:
> Thank you, Bill.
> I can confirm same behaviour as you described with my vim.
> Now it is up to Bram to decide if this is wrong or right.

IMO it is bug because it prevents chained completion.

m.



RE: Vim 7.0 (1-109 patches) completion bug.

2006-10-09 Thread Igor Prischepoff
Thank you, Bill.
I can confirm same behaviour as you described with my vim.
Now it is up to Bram to decide if this is wrong or right.

---
[EMAIL PROTECTED]



Re: Q: rsync://ftp.vim.org/Vim/runtime/ - when?

2006-10-09 Thread A.J.Mechelynck

Bill McCarthy wrote:

On Sun 8-Oct-06 7:39pm -0600, A.J.Mechelynck wrote:



Bill McCarthy wrote:

On Sun 8-Oct-06 5:42pm -0600, Alexey I. Froloff wrote:


When "current" version of vim runtime will be updated for latest
patches?  Patch 111 modifies autoload/gzip.vim and doc/eval.txt
which are still outdated on ftp...

The gzip.vim is clearly old, but comparing (vimdiff) the
eval.txt on the FTP site to the patch version on CVS, they
both share the same internal date of 22-Sep-2006 yet the one
on the FTP site looks newer.

I generally find it easier to ignore the patches to runtime
files and, instead, rely on the FTP site for those.  They
are usually updated fairly quickly.


After checking, the "new" versions of the files mentioned in patch 111 agree
with the latest versions I downloaded from the rsync server, except that the
gzip.vim lacks the new datestamp (the rest of the file is OK though.)


After deleting gzip.vim and performing a copy update from
the ftp site, the gzip.vim downloaded is older.  It will not
use the new shellescape function.  It has this logic:

  if v:version > 700 || (v:version == 700 && has('patch999'))
return shellescape(a:name)
  endif

The patched version on the CVS, has the same code but the
has() has:

  has('patch111'))

so it will use the new function.



I suggest the attached patch, to test function existence directly, rather than 
patch number.



Best regards,
Tony.
*** runtime/autoload/gzip.vim.orig	Mon Oct  9 11:59:07 2006
--- runtime/autoload/gzip.vim	Mon Oct  9 11:59:07 2006
***
*** 176,183 
  endfun
  
  fun s:escape(name)
!   " shellescape() was added by patch 7.0.999
!   if v:version > 700 || (v:version == 700 && has('patch999'))
  return shellescape(a:name)
endif
return "'" . a:name . "'"
--- 176,182 
  endfun
  
  fun s:escape(name)
!   if exists("*shellescape")
  return shellescape(a:name)
endif
return "'" . a:name . "'"


Re: Vim 7.0 (1-109 patches) completion bug.

2006-10-09 Thread Bill McCarthy
This was a response to a personal mail from Igor, but I am
unable to reach his address by mail.  I got my message back
with:

<[EMAIL PROTECTED]>:
80.91.16.141 does not like recipient.
Remote host said: 553 5.7.1 : 
Client
host rejected: Big domain level
Giving up on 80.91.16.141.

This continues the conversion with the same subject.  There
does appear to be a bug.

Please read on.

On Sun 8-Oct-06 10:42pm -0600, Igor Prischepoff wrote:

> Hello, Bill.
> Can you try _one more last time_ please ?
> gvim - 
> set cot+=longest
> set cot-=menuone
> set complete-=t

After starting with:

gvim -u NONE -i NONE -N

I typed:

:se cot+=longest cpt-=t cot cpt

Gvim outputs:

  completeopt=menu,preview,longest
  complete=w,b,u,i

which is hopefully the same state you get.

> i
> one : word
> two : word
> o:t

On the first , 'o' is expanded to 'one', however I get
a message "Back at original".  That is wrong.  The original
is 'o' not 'one'.  Gvim appears confused.  Typing any non-
whitespace printable characters continues its confusion and
another , after typing one or more of these characters,
does nothing.

After the 'one' is completed from the first , a second
 changes the message to "The only match".  Now you can
continue typing - the completion text in the command area
will be cleared and  will "work" on 't' (but you'll be
in the same wrong state of completion with the incorrect
message of "Back at original".

BTW, a  is supposed to tell Gvim you are done with
completion.  It behaves strangely here.  After the 
completes the 'o' to 'one', a  indeed ends the
completion but I am not left with 'one', I am left with
'ow'!

> what I've got is
> one : word
> two : word
> one:t
> and message "Back at original"
> Please note that when you type C-N first time (after 'o')
> you should get 'one' expanded automatically because it's
> only match in this case. And when type  after 't' you
> should get nothing (that's a bug I think). In both cases
> you should get NO MENU. (because of longest and no menuone
> in completeoption)

I get no menu because there is no menuone, not because of
longest.  Don't you also see the problem begins with the
first  after the 'o'?

> If you got other result's can you please send you :ver output?

> mine is : vi Improved 7.0
> Included patches:1-118

Here the output of :version

VIM - Vi IMproved 7.0 (2006 May 7, compiled Oct  8 2006 13:02:44)
MS-Windows 32 bit GUI version with OLE support
Included patches: 1-121
Compiled by Bill McCarthy <[EMAIL PROTECTED]>
Big version with GUI.  Features included (+) or not (-):
+arabic +autocmd +balloon_eval +browse ++builtin_terms +byte_offset +cindent 
+clientserver +clipboard +cmdline_compl +cmdline_hist +cmdline_info +comments 
+cryptv +cscope +cursorshape +dialog_con_gui +diff +digraphs -dnd -ebcdic 
+emacs_tags +eval +ex_extra +extra_search +farsi +file_in_path +find_in_path 
+folding -footer +gettext/dyn -hangul_input +iconv/dyn +insert_expand +jumplist
 +keymap +langmap +libcall +linebreak +lispindent +listcmds +localmap +menu 
+mksession +modify_fname +mouse +mouseshape +multi_byte_ime/dyn +multi_lang 
+mzscheme/dyn +netbeans_intg +ole -osfiletype +path_extra -perl -postscript 
+printer -profile +python/dyn +quickfix +reltime +rightleft -ruby +scrollbind 
+signs +smartindent -sniff +statusline -sun_workshop +syntax +tag_binary 
+tag_old_static -tag_any_white -tcl -tgetent -termresponse +textobjects +title 
+toolbar +user_commands +vertsplit +virtualedit +visual +visualextra +viminfo 
+vreplace +wildignore +wildmenu +windows +writebackup -xfontset -xim 
-xterm_save -xpm_w32 
   system vimrc file: "$VIM\vimrc"
 user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$VIM\_vimrc"
  user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$VIM\_gvimrc"
system menu file: "$VIMRUNTIME\menu.vim"
Compilation: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT 
-DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe 
-w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME 
-DMZSCHEME_COLLECTS="c:/util/MzScheme/collects" -DDYNAMIC_MZSCHEME 
-DDYNAMIC_MZSCH_DLL="libmzsch209_000.dll" 
-DDYNAMIC_MZGC_DLL="libmzgc209_000.dll" -DFEAT_PYTHON -I 
c:/util/python24/include -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL="python24.dll" 
-O3 -fomit-frame-pointer -freg-struct-return -s
Linking: gcc -Iproto -DWIN32 -DWINVER=0x0400 -D_WIN32_WINNT=0x0400 
-DHAVE_PATHDEF -DFEAT_BIG -DHAVE_GETTEXT -DHAVE_LOCALE_H -DDYNAMIC_GETTEXT 
-DFEAT_CSCOPE -DFEAT_MBYTE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DDYNAMIC_ICONV -pipe 
-w -march=pentium3 -Wall -Ic:/util/MzScheme/include -DFEAT_MZSCHEME 
-DMZSCHEME_COLLECTS="c:/util/MzScheme/collects" -DDYNAMIC_MZSCHEME 
-DDYNAMIC_MZSCH_DLL="libmzsch209_000.dll" 
-DDYNAMIC_MZGC_DLL="libmzgc209_000.dll" -DFEAT_