Vim 7.3d ready for beta testing

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Vim 7.3d ready for beta testing

Bram Moolenaar


Hello Vim users,


Announcing:  Vim (Vi IMproved) version 7.3d BETA


This is a BETA release of Vim 7.3.  It consists of Vim 7.2 plus all
patches, updated runtime files and some more.

7.3d is for a large part the same as 7.3c, but the MS-Windows
executables have been build with MSVC 2008.  They should now work on
Windows 2000 too.  The install and uninstall problems for 64 bit systems
have been fixed (I hope).

Please report every problem you find!  The 7.3 release should not
contain a problem because you didn't report it.

The biggest additions since 7.2:
- Persistent undo, undo for reload
- Blowfish encryption, also encrypt the swap file
- Conceal text (note: since 7.3a 'conc' was renamed to 'cole')
- Lua interface
- Python 3 interface

I will no longer include new features in 7.3, it's only testing now.

Once you have installed Vim 7.3d BETA you can find details about the
changes since Vim 7.2 with:
        :help version-7.3


Testing
-------

Please especially test the persistent undo and encryption.  These need
to work reliably.

Report anything that isn't right.  That includes a crash but also a typo
in the documentation and a missing file.


Gratitude
---------

If you like Vim, this is the way to say thanks:
http://iccf-holland.org/clinic.html


Where to get it
---------------

The best way to obtain the latest Vim 7.3 is using Mercurial.
Summary:
        hg clone https://vim.googlecode.com/hg/ vim
        cd vim
        hg update vim73
More information here: http://www.vim.org/mercurial.php

All downloadable files can be found below this directory:
        ftp://ftp.vim.org/pub/vim/unstable/

Direct link to the MS-Windows self-installing executable:
        ftp://ftp.vim.org/pub/vim/unstable/pc/gvim73d.exe

Information about which files to download for what system (don't use the
links, they are still for Vim 7.2):
        http://www.vim.org/download.php

A list of mirror sites can be found here:
        http://www.vim.org/mirrors.php


An overview of the files below "unstable":

UNIX:
unix/vim-7.3d.tar.bz2           sources + runtime files, bzip2 compressed

MS-WINDOWS one-size-fits-all:
pc/gvim73d.exe                  self-installing, includes all runtime files

VARIOUS:
doc/vim73dhtml.zip              help files converted to HTML

MS-WINDOWS separate files:
pc/vim73drt.zip                 runtime files
pc/gvim73d.zip                  GUI binary for Windows 95/98/NT/2000/XP
pc/gvim73dole.zip               GUI binary with OLE support
pc/gvim73d_s.zip                GUI binary for Windows 3.1 (untested)
pc/vim73dd32.zip                console version for MS-DOS/Windows 95/98
pc/vim73dw32.zip                console version for Windows NT/2000/XP
pc/vim73dsrc.zip                sources for PC (with CR-LF)

DIFFS TO PREVIOUS RELEASE:
unix/vim-7.3c-7.3d.diff.gz    sources + runtime files

Omitted in this version are:
- Extra and lang archives, these are now included in the main source
  and runtime archives.
- The 16-bit DOS, OS/2 and Amiga versions, these are obsolete.


Mailing lists
-------------

For user questions you can turn to the Vim mailing list.  There are a
lot of tips, scripts and solutions.  You can ask your Vim questions, but
only if you subscribe.  See http://www.vim.org/maillist.php#vim

If you want to help Vim development, discuss new features or get the
latest patches, subscribe to the vim-dev mailing list.  See
http://www.vim.org/maillist.php#vim-dev

Subject specific lists:
Multi-byte issues: http://www.vim.org/maillist.php#vim-multibyte
Macintosh issues:  http://www.vim.org/maillist.php#vim-mac

Before you ask a question you should search the archives, someone may
already have given the answer.


Reporting bugs
--------------

Send them to <[hidden email]>.  Please describe the problem precisely.
All the time spent on answering mail is subtracted from the time that is
spent on improving Vim!  Always give a reproducible example and try to
find out which settings or other things influence the appearance of the
bug.  Try starting without your own vimrc file: "vim -u NONE".  Try
different machines if possible.  See ":help bugs" in Vim.  Send me a
patch if you can!


Happy Vimming!


--
hundred-and-one symptoms of being an internet addict:
3. Your bookmark takes 15 minutes to scroll from top to bottom.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Yue Wu
On Thu, 05 Aug 2010 01:15:17 +0800, Bram Moolenaar <[hidden email]>  
wrote:

>
> 7.3d is for a large part the same as 7.3c, but the MS-Windows
> executables have been build with MSVC 2008.  They should now work on
> Windows 2000 too.  The install and uninstall problems for 64 bit systems
> have been fixed (I hope).
>

Thank you for nice work, work fine now on windows 2000 here.

--
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Tony Mechelynck
In reply to this post by Bram Moolenaar
On 04/08/10 19:15, Bram Moolenaar wrote:

>
>
> Hello Vim users,
>
>
> Announcing:  Vim (Vi IMproved) version 7.3d BETA
>
>
> This is a BETA release of Vim 7.3.  It consists of Vim 7.2 plus all
> patches, updated runtime files and some more.
>
> 7.3d is for a large part the same as 7.3c, but the MS-Windows
> executables have been build with MSVC 2008.  They should now work on
> Windows 2000 too.  The install and uninstall problems for 64 bit systems
> have been fixed (I hope).
[...]

Wow! Thats's a fast one!


Happy Vimming!
Tony.
--
One man's theology is another man's belly laugh.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Boyko Bantchev
In reply to this post by Bram Moolenaar
On 4 August 2010 20:15, Bram Moolenaar <[hidden email]> wrote:
> ...
> Please report every problem you find!  The 7.3 release should not
> contain a problem because you didn't report it.
> ...

Well, I did point out to two bugs earlier, and they are still
present in 7.3d.

1. Function input()'s echo is broken.  If one executes, e.g.

      :while 1 | let s = input('') | echo "\n" | endw

   one would expect to see a succession of strings that he enters.
   Instead, we are left with nothing but empty lines.
   This bug seems to be very old, and seriously hampers writing
   interactive vimscriptlets.

2. Under Linux + GTK, all Unicode characters combined-accented with
   U+0300, U+0301, ... (any of those) are incorrectly displayed:
   the accent is either (mis)placed above the character on the left,
   or is not displayed at all.
   This seems to have originated with Vim 7.2.

Best regards,
   Boyko

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Yue Wu
In reply to this post by Bram Moolenaar
On Thu, 05 Aug 2010 01:15:17 +0800, Bram Moolenaar <[hidden email]>  
wrote:

>
>
> Hello Vim users,
>
>
> Announcing:  Vim (Vi IMproved) version 7.3d BETA
>

On windows, !cmd completion doesn't work at all.

--
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Bram Moolenaar
In reply to this post by Boyko Bantchev

Boyko Bantchev wrote:

> On 4 August 2010 20:15, Bram Moolenaar <[hidden email]> wrote:
> > ...
> > Please report every problem you find! =A0The 7.3 release should not
> > contain a problem because you didn't report it.
> > ...
>
> Well, I did point out to two bugs earlier, and they are still
> present in 7.3d.
>
> 1. Function input()'s echo is broken.  If one executes, e.g.
>
>       :while 1 | let s = input('') | echo "\n" | endw
>
>    one would expect to see a succession of strings that he enters.
>    Instead, we are left with nothing but empty lines.
>    This bug seems to be very old, and seriously hampers writing
>    interactive vimscriptlets.

Try this:

       :while 1 | let s = input('') | echo s "\n" | endw

Not sure this is a bug.  If someone wants to erase the typed text this
would work now but not when making it work the way you suggest.


> 2. Under Linux + GTK, all Unicode characters combined-accented with
>    U+0300, U+0301, ... (any of those) are incorrectly displayed:
>    the accent is either (mis)placed above the character on the left,
>    or is not displayed at all.
>    This seems to have originated with Vim 7.2.

I see this too.  I can fix it with this change:


--- a/gui_gtk_x11.c 2010-07-25 15:48:22.000000000 +0200
+++ b/gui_gtk_x11.c 2010-08-05 23:09:43.000000000 +0200
@@ -5108,10 +5108,11 @@
 
     /* There is a previous glyph, so we deal with combining
      * characters the canonical way.  That is, setting the
-     * width of the previous glyph to 0. */
+     * width of the previous glyph to 0 and set the x_offset
+     * to puth the accent glyph in the middle. */
     glyphs->glyphs[i - 1].geometry.width = 0;
     width = cells * gui.char_width * PANGO_SCALE;
-    glyph->geometry.x_offset +=
+    glyph->geometry.x_offset =
     MAX(0, width - cluster_width) / 2;
 #if 0
     /* Dirty hack: for "monospace 13" font there is a bug that


But that might break it for others...

--
hundred-and-one symptoms of being an internet addict:
18. Your wife drapes a blond wig over your monitor to remind you of what she
    looks like.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Bram Moolenaar
In reply to this post by Yue Wu

> On windows, !cmd completion doesn't work at all.

Perhaps this is a problem with a space in $PATH?

--
hundred-and-one symptoms of being an internet addict:
19. All of your friends have an @ in their names.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Libo Song
On Thu, Aug 5, 2010 at 5:15 PM, Bram Moolenaar <[hidden email]> wrote:

>
>> On windows, !cmd completion doesn't work at all.
>
> Perhaps this is a problem with a space in $PATH?
>
> --
> hundred-and-one symptoms of being an internet addict:
> 19. All of your friends have an @ in their names.
>
>  /// Bram Moolenaar -- [hidden email] -- 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    ///
>
> --
> You received this message from the "vim_use" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>

Thanks. Great work.

I have an issue in the new Vim7.3e BETA. It is probably not a bug.
When I use :find, type some letters, then <TAB> gives me a list of
choices. In 7.2, it shows, for example, the files under a dir. But in
7.3e, it shows the files with the path, then fewer item on the list.
If I have a deep path, there will be no files shown, only a ">".

BTW, how can I get to the next "set of items" show on the list other
than press the <RIGHT ARROW>? For example, I have the items shown:
aprutil.Makefile  aprutil.gyp  aprutil.target.mk  gen/  include.target.mk  >
I want to see more items.

Thanks.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Nazri Ramliy
On Fri, Aug 6, 2010 at 6:22 AM, Libo Song <[hidden email]> wrote:

> I have an issue in the new Vim7.3e BETA. It is probably not a bug.
> When I use :find, type some letters, then <TAB> gives me a list of
> choices. In 7.2, it shows, for example, the files under a dir. But in
> 7.3e, it shows the files with the path, then fewer item on the list.
> If I have a deep path, there will be no files shown, only a ">".
>
> BTW, how can I get to the next "set of items" show on the list other
> than press the <RIGHT ARROW>? For example, I have the items shown:
> aprutil.Makefile  aprutil.gyp  aprutil.target.mk  gen/  include.target.mk  >
> I want to see more items.

Try

        :set wildmode:list

See

        :help 'wildmode'

For details.

nazri.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Yue Wu
In reply to this post by Bram Moolenaar
On Thu, Aug 05, 2010 at 11:15:21PM +0200, Bram Moolenaar wrote:
>
> > On windows, !cmd completion doesn't work at all.
>
> Perhaps this is a problem with a space in $PATH?
>

No, I've tried removing the paths with space in $PATH, still not work.

--
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Bram Moolenaar

Yue Wu wrote:

> On Thu, Aug 05, 2010 at 11:15:21PM +0200, Bram Moolenaar wrote:
> >
> > > On windows, !cmd completion doesn't work at all.
> >
> > Perhaps this is a problem with a space in $PATH?
> >
>
> No, I've tried removing the paths with space in $PATH, still not work.

I did have it work to complete local files at least.  It doesn't check
the matches to be executable.

Can you try a few different values for $PATH to see what works and what
doesn't?  Perhaps it only works with one entry?

--
When a fly lands on the ceiling, does it do a half roll or
a half loop?

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Yue Wu
On Fri, 06 Aug 2010 17:48:20 +0800, Bram Moolenaar <[hidden email]>  
wrote:

>
> Yue Wu wrote:
>
>> On Thu, Aug 05, 2010 at 11:15:21PM +0200, Bram Moolenaar wrote:
>> >
>> > > On windows, !cmd completion doesn't work at all.
>> >
>> > Perhaps this is a problem with a space in $PATH?
>> >
>>
>> No, I've tried removing the paths with space in $PATH, still not work.
>
> I did have it work to complete local files at least.  It doesn't check
> the matches to be executable.
>
> Can you try a few different values for $PATH to see what works and what
> doesn't?  Perhaps it only works with one entry?

Even with one entry, !cmd completion doesn't work. File/dir completion  
always works well, but cmd completion not at all.

--
Regards,
Yue Wu

Key Laboratory of Modern Chinese Medicines
Department of Traditional Chinese Medicine
China Pharmaceutical University
No.24, Tongjia Xiang Street, Nanjing 210009, China

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Bram Moolenaar
In reply to this post by Libo Song

Libo Song wrote:

> Thanks. Great work.
>
> I have an issue in the new Vim7.3e BETA. It is probably not a bug.
> When I use :find, type some letters, then <TAB> gives me a list of
> choices. In 7.2, it shows, for example, the files under a dir. But in
> 7.3e, it shows the files with the path, then fewer item on the list.
> If I have a deep path, there will be no files shown, only a ">".

This was probably fixed yesterday.

> BTW, how can I get to the next "set of items" show on the list other
> than press the <RIGHT ARROW>? For example, I have the items shown:
> aprutil.Makefile  aprutil.gyp  aprutil.target.mk  gen/  include.target.mk  >
> I want to see more items.

Are you using 'wildmenu'?  You can use Tab multiple times or perhaps
change 'wildmode' to change how it works.

--
hundred-and-one symptoms of being an internet addict:
28. You have comandeered your teenager's phone line for the net and even his
    friends know not to call on his line anymore.

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Libo Song
On Fri, Aug 6, 2010 at 3:16 PM, Bram Moolenaar <[hidden email]> wrote:

>
> Libo Song wrote:
>
>> Thanks. Great work.
>>
>> I have an issue in the new Vim7.3e BETA. It is probably not a bug.
>> When I use :find, type some letters, then <TAB> gives me a list of
>> choices. In 7.2, it shows, for example, the files under a dir. But in
>> 7.3e, it shows the files with the path, then fewer item on the list.
>> If I have a deep path, there will be no files shown, only a ">".
>
> This was probably fixed yesterday.

Run hg pull; hg update; make
Then,
I set wildmode=list. Here is the output after press <TAB>.
~
:find ~/work/temp/
~/work/temp/1/
~/work/temp/apache_rewrite_driver_factory.cc
~/work/temp/c-httpd
~/work/temp/dump_cache.gyp
~/work/temp/favicon.ico
~/work/temp/filename_encoder.cc
~/work/temp/filename_encoder.h
~/work/temp/filename_encoder_test.cc
....

Set wildmode=full. The result is
~/work/temp/1/  ~/work/temp/apache_rewrite_driver_factory.cc  >
:find ~/work/temp/1/


>
>> BTW, how can I get to the next "set of items" show on the list other
>> than press the <RIGHT ARROW>? For example, I have the items shown:
>> aprutil.Makefile  aprutil.gyp  aprutil.target.mk  gen/  include.target.mk  >
>> I want to see more items.
>
> Are you using 'wildmenu'?  You can use Tab multiple times or perhaps
> change 'wildmode' to change how it works.

No, I was not using 'wildmenu'. I was still using V7.2, Tab does not work.

>
> --
> hundred-and-one symptoms of being an internet addict:
> 28. You have comandeered your teenager's phone line for the net and even his
>    friends know not to call on his line anymore.
>
>  /// Bram Moolenaar -- [hidden email] -- 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    ///
>

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Fwd: Vim 7.3d ready for beta testing

Boyko Bantchev
In reply to this post by Bram Moolenaar
Hitting Reply, I didn't realize this post of mine was only sent to Bram.
It might be of interest to others, so I am forwarding to the group now.

Best regards,
   Boyko


---------- Forwarded message ----------
From: Boyko Bantchev <[hidden email]>
Date: 6 August 2010 15:25
Subject: Re: Vim 7.3d ready for beta testing
To: Bram Moolenaar <[hidden email]>


On 6 August 2010 00:15, Bram Moolenaar <[hidden email]> wrote:
> Try this:
>
>       :while 1 | let s = input('') | echo s "\n" | endw
>
> Not sure this is a bug.  If someone wants to erase the typed text this
> would work now but not when making it work the way you suggest.

Bram,

I see what you mean but I find the use of input() in combination
with echo *very* confusing the way it is now.

First, it seems to me that having to re-echo what has been just
typed is more unnatural than having to erase it when it is not needed.
Erasure should be possible through printing \r or some amount of \b-s,
provided that after input() is done we are on the same line.

See the discussion two years ago

http://groups.google.com/group/vim_use/browse_thread/thread/84bebe4fa57a7618?fwc=1&pli=1

where the current behaviour of input() did look erroneous to whoever
posted – including you :)

Second, the way input() interacts with echo is rather strange.
Let's start from assuming (the documentation does not specify this)
that input() starts on a new line.  Then, in the expression you gave

   while 1 | let s = input('') | echo s "\n" | endw

why do we need printing the final \n?  I'd expect the input() after
that \n to leave a blank line but it doesn't.

Also, how does echo manage to print on the same line as input(), when
the documentation says that echo “… starts on a new line”?

But does indeed input() itself start on a new line?  Trying

   echo ">>>" | let s = input('')

seems to prove so.  However, extending this to

   echo ">>>" | let s = input('') | echo s "\n"

brings quite a surprise: now the input()'s implicit echo is partially (!)
retained and repeated by the explicit echo.  See also

   while 1 | echo ">>>" | let s = input('') | echo "\n" | endw

in that respect.  And try

   while 1 | echo ">>>" | let s = input('') | endw

typing in at least several lines for a complete amazement …
Finally, try

   while 1 | let s = input('') | echo s "\n" | echo "...\n" | endw

which appears to print a ...\n after each input line.  Again, how
does the second echo *not* leave a blank line where it should by
definition?

In fact, echo alone behaves strangely.  Try

   echo 'abc' | echo '' | echo 'def'

or even better

   for s in ['abc', '', 'def'] | echo s | endfor

It turns out that echo starts on a new line only when its argument
is a non-empty string.  (And still works even more strangely in
combination with input().)


> I see this too.  I can fix it with this change:
>
> --- a/gui_gtk_x11.c     2010-07-25 15:48:22.000000000 +0200
> +++ b/gui_gtk_x11.c     2010-08-05 23:09:43.000000000 +0200
> ...

I know nothing of that ...   I only remember that combined accents
worked correctly in 7.0, if that is any useful information.

Best regards,
  Boyko

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Tony Mechelynck
In reply to this post by Bram Moolenaar
On 05/08/10 23:15, Bram Moolenaar wrote:

>
> Boyko Bantchev wrote:
>
>> On 4 August 2010 20:15, Bram Moolenaar<[hidden email]>  wrote:
>>> ...
>>> Please report every problem you find! =A0The 7.3 release should not
>>> contain a problem because you didn't report it.
>>> ...
>>
>> Well, I did point out to two bugs earlier, and they are still
>> present in 7.3d.
>>
>> 1. Function input()'s echo is broken.  If one executes, e.g.
>>
>>        :while 1 | let s = input('') | echo "\n" | endw
>>
>>     one would expect to see a succession of strings that he enters.
>>     Instead, we are left with nothing but empty lines.
>>     This bug seems to be very old, and seriously hampers writing
>>     interactive vimscriptlets.
>
> Try this:
>
>         :while 1 | let s = input('') | echo s "\n" | endw
>
> Not sure this is a bug.  If someone wants to erase the typed text this
> would work now but not when making it work the way you suggest.
>
>
>> 2. Under Linux + GTK, all Unicode characters combined-accented with
>>     U+0300, U+0301, ... (any of those) are incorrectly displayed:
>>     the accent is either (mis)placed above the character on the left,
>>     or is not displayed at all.
>>     This seems to have originated with Vim 7.2.
>
> I see this too.  I can fix it with this change:
>
>
> --- a/gui_gtk_x11.c 2010-07-25 15:48:22.000000000 +0200
> +++ b/gui_gtk_x11.c 2010-08-05 23:09:43.000000000 +0200
> @@ -5108,10 +5108,11 @@
>
>      /* There is a previous glyph, so we deal with combining
>       * characters the canonical way.  That is, setting the
> -     * width of the previous glyph to 0. */
> +     * width of the previous glyph to 0 and set the x_offset
> +     * to puth the accent glyph in the middle. */
>      glyphs->glyphs[i - 1].geometry.width = 0;
>      width = cells * gui.char_width * PANGO_SCALE;
> -    glyph->geometry.x_offset +=
> +    glyph->geometry.x_offset =
>      MAX(0, width - cluster_width) / 2;
>   #if 0
>      /* Dirty hack: for "monospace 13" font there is a bug that
>
>
> But that might break it for others...
>
After applying this patch (changeset 2070b63605a7 dated 2010-08-07
15:46:45 +0200), my gvim display is worse than before.

I'm using Bitstream Vera Sans Mono 8 in gvim (Huge) +gui_gtk2 +gui_gnome
and currently I'm editing a Russian dictionary, with many combining
acute accents (U+0301) over Cyrillic vowels.

Before the patch, the accents came beautifully over the concerned
vowels. After the patch, the accent is displayed too much to the right,
between the concerned vowel and the next letter. This resembles what I
get with Times New Roman in the Mozilla SeaMonkey browser; it is not as
bad, though, as what I see with "monospace" (not sure which font this
brings) in the SeaMonkey mailer, where the accent is squarely over the
next letter, one character width to the right of where it ought to be.

So I suspect that this is a font-related problem. Boyko, what 'guifont'
are you using?

Bram, is it possible to know the width of the glyph, in order not to
move it so far to the right that it overshoots the next character? Also,
what will happen in Arabic, where it is common (at least in Koranic
Arabic) to have two combining characters over a single spacing letter?
For instance: in the formula, "to the name of God the Benevolent the
Merciful", bismillâh ar-rahmân ar-rahîm,
بِسْمِ ٱللّٰهِ ٱلرَّحْمٰنِ ٱلرَّحِيمِ؛
in the last (leftmost) two words (of four), the third consonant (which
goes down below the line and is not joined to the next one to its left)
has two combining signs, making it in both cases rah + shadda + fatha,
U+0631 + U+0651 + U+064E

I'm attaching an "Arabic testcase" file which displays horribly in this
new Vim changeset. Use ":setlocal arabic" to display the Arabic text RTL
as it should be, then compare lines 87-92 (in vocalized Arabic) with
lines 94-99 (the same text without the combining characters). You should
see the same consonants, just without the combining marks (the
"harakaat" as they're called in Arabic) but that's not what I see. Some
letters move about, others disappear completely, moving the cursor over
the text makes the letters go left or right... (The unvocalized part,
lines 94-99, is displayed correctly.)

Since this testcase is HTML, you can also view it in a browser; however
even browsers may display the consonants differently because when there
exists a digram or a trigram to make some letter-combinations "nicer",
the browser may not recognise it if there is a combining mark in the
middle. This, however, should not affect Vim, which pays no attention to
polygrams other than lam+alif.


Best regards,
Tony.
--
New members are urgently needed in the Society for Prevention of
Cruelty to Yourself.  Apply within.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

arabtest.htm (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Tony Mechelynck
In reply to this post by Libo Song
On 06/08/10 21:53, Libo Song wrote:

> On Fri, Aug 6, 2010 at 3:16 PM, Bram Moolenaar<[hidden email]>  wrote:
>>
>> Libo Song wrote:
>>
>>> Thanks. Great work.
>>>
>>> I have an issue in the new Vim7.3e BETA. It is probably not a bug.
>>> When I use :find, type some letters, then<TAB>  gives me a list of
>>> choices. In 7.2, it shows, for example, the files under a dir. But in
>>> 7.3e, it shows the files with the path, then fewer item on the list.
>>> If I have a deep path, there will be no files shown, only a ">".
>>
>> This was probably fixed yesterday.
>
> Run hg pull; hg update; make
> Then,
> I set wildmode=list. Here is the output after press<TAB>.
> ~
> :find ~/work/temp/
> ~/work/temp/1/
> ~/work/temp/apache_rewrite_driver_factory.cc
> ~/work/temp/c-httpd
> ~/work/temp/dump_cache.gyp
> ~/work/temp/favicon.ico
> ~/work/temp/filename_encoder.cc
> ~/work/temp/filename_encoder.h
> ~/work/temp/filename_encoder_test.cc
> ....
>
> Set wildmode=full. The result is
> ~/work/temp/1/  ~/work/temp/apache_rewrite_driver_factory.cc>
> :find ~/work/temp/1/

If you hit Ctrl-D while on the command-line, you'll see all possible
completions. Then you can type a few letters of the one which interests
you, and use completion again thereafter.

>
>
>>
>>> BTW, how can I get to the next "set of items" show on the list other
>>> than press the<RIGHT ARROW>? For example, I have the items shown:
>>> aprutil.Makefile  aprutil.gyp  aprutil.target.mk  gen/  include.target.mk>
>>> I want to see more items.
>>
>> Are you using 'wildmenu'?  You can use Tab multiple times or perhaps
>> change 'wildmode' to change how it works.
>
> No, I was not using 'wildmenu'. I was still using V7.2, Tab does not work.

The problem you describe looks like what 'wildmenu' would show.

..."Tab does not work"... Are you sure you're in 'nocompatible' mode?
Otherwise (in 'compatible' mode) it's Ctrl-E instead of Tab.

See ":help cmdline-completion" and the help for the various options
starting in 'wild


Best regards,
Tony.
--
Life is a whim of several billion cells to be you for a while.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Boyko Bantchev
In reply to this post by Tony Mechelynck
2010/8/7 Tony Mechelynck <[hidden email]>:
> So I suspect that this is a font-related problem. Boyko, what 'guifont' are
> you using?

I set it to Monospace, which I think actually is DejaVu Sans Mono.

Best regards,
   Boyko

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Bram Moolenaar
In reply to this post by Tony Mechelynck

Tony Mechelynck wrote:

> On 05/08/10 23:15, Bram Moolenaar wrote:
> >
> > Boyko Bantchev wrote:
> >
> >> On 4 August 2010 20:15, Bram Moolenaar<[hidden email]>  wrote:
> >>> ...
> >>> Please report every problem you find! =A0The 7.3 release should not
> >>> contain a problem because you didn't report it.
> >>> ...
> >>
> >> Well, I did point out to two bugs earlier, and they are still
> >> present in 7.3d.
> >>
> >> 1. Function input()'s echo is broken.  If one executes, e.g.
> >>
> >>        :while 1 | let s = input('') | echo "\n" | endw
> >>
> >>     one would expect to see a succession of strings that he enters.
> >>     Instead, we are left with nothing but empty lines.
> >>     This bug seems to be very old, and seriously hampers writing
> >>     interactive vimscriptlets.
> >
> > Try this:
> >
> >         :while 1 | let s = input('') | echo s "\n" | endw
> >
> > Not sure this is a bug.  If someone wants to erase the typed text this
> > would work now but not when making it work the way you suggest.
> >
> >
> >> 2. Under Linux + GTK, all Unicode characters combined-accented with
> >>     U+0300, U+0301, ... (any of those) are incorrectly displayed:
> >>     the accent is either (mis)placed above the character on the left,
> >>     or is not displayed at all.
> >>     This seems to have originated with Vim 7.2.
> >
> > I see this too.  I can fix it with this change:
> >
> >
> > --- a/gui_gtk_x11.c 2010-07-25 15:48:22.000000000 +0200
> > +++ b/gui_gtk_x11.c 2010-08-05 23:09:43.000000000 +0200
> > @@ -5108,10 +5108,11 @@
> >
> >      /* There is a previous glyph, so we deal with combining
> >       * characters the canonical way.  That is, setting the
> > -     * width of the previous glyph to 0. */
> > +     * width of the previous glyph to 0 and set the x_offset
> > +     * to puth the accent glyph in the middle. */
> >      glyphs->glyphs[i - 1].geometry.width = 0;
> >      width = cells * gui.char_width * PANGO_SCALE;
> > -    glyph->geometry.x_offset +=
> > +    glyph->geometry.x_offset =
> >      MAX(0, width - cluster_width) / 2;
> >   #if 0
> >      /* Dirty hack: for "monospace 13" font there is a bug that
> >
> >
> > But that might break it for others...
> >
>
> After applying this patch (changeset 2070b63605a7 dated 2010-08-07
> 15:46:45 +0200), my gvim display is worse than before.
>
> I'm using Bitstream Vera Sans Mono 8 in gvim (Huge) +gui_gtk2 +gui_gnome
> and currently I'm editing a Russian dictionary, with many combining
> acute accents (U+0301) over Cyrillic vowels.
>
> Before the patch, the accents came beautifully over the concerned
> vowels. After the patch, the accent is displayed too much to the right,
> between the concerned vowel and the next letter. This resembles what I
> get with Times New Roman in the Mozilla SeaMonkey browser; it is not as
> bad, though, as what I see with "monospace" (not sure which font this
> brings) in the SeaMonkey mailer, where the accent is squarely over the
> next letter, one character width to the right of where it ought to be.
>
> So I suspect that this is a font-related problem. Boyko, what 'guifont'
> are you using?
>
> Bram, is it possible to know the width of the glyph, in order not to
> move it so far to the right that it overshoots the next character? Also,
> what will happen in Arabic, where it is common (at least in Koranic
> Arabic) to have two combining characters over a single spacing letter?
> For instance: in the formula, "to the name of God the Benevolent the
> Merciful", bismillâh ar-rahmân ar-rahîm,
> ب٠سْم٠ Ù±Ù„لّٰه٠ Ù±Ù„رَّحْمٰن٠ Ù±Ù„رَّح٠يم٠؛
> in the last (leftmost) two words (of four), the third consonant (which
> goes down below the line and is not joined to the next one to its left)
> has two combining signs, making it in both cases rah + shadda + fatha,
> U+0631 + U+0651 + U+064E
>
> I'm attaching an "Arabic testcase" file which displays horribly in this
> new Vim changeset. Use ":setlocal arabic" to display the Arabic text RTL
> as it should be, then compare lines 87-92 (in vocalized Arabic) with
> lines 94-99 (the same text without the combining characters). You should
> see the same consonants, just without the combining marks (the
> "harakaat" as they're called in Arabic) but that's not what I see. Some
> letters move about, others disappear completely, moving the cursor over
> the text makes the letters go left or right... (The unvocalized part,
> lines 94-99, is displayed correctly.)
>
> Since this testcase is HTML, you can also view it in a browser; however
> even browsers may display the consonants differently because when there
> exists a digram or a trigram to make some letter-combinations "nicer",
> the browser may not recognise it if there is a combining mark in the
> middle. This, however, should not affect Vim, which pays no attention to
> polygrams other than lam+alif.

Sorry, these scribbles don't show me what's wrong.  Viewing the text in
a browser looks completely different.

Please try the latest version, I solved it in a slightly different way.
For older GTK versions it might do the same as before.

--
How To Keep A Healthy Level Of Insanity:
4. Put your garbage can on your desk and label it "in".

 /// Bram Moolenaar -- [hidden email] -- 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    ///

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
Reply | Threaded
Open this post in threaded view
|

Re: Vim 7.3d ready for beta testing

Tony Mechelynck
On 07/08/10 18:53, Bram Moolenaar wrote:

>
> Tony Mechelynck wrote:
>
>> On 05/08/10 23:15, Bram Moolenaar wrote:
>>>
>>> Boyko Bantchev wrote:
>>>
>>>> On 4 August 2010 20:15, Bram Moolenaar<[hidden email]>   wrote:
>>>>> ...
>>>>> Please report every problem you find! =A0The 7.3 release should not
>>>>> contain a problem because you didn't report it.
>>>>> ...
>>>>
>>>> Well, I did point out to two bugs earlier, and they are still
>>>> present in 7.3d.
>>>>
>>>> 1. Function input()'s echo is broken.  If one executes, e.g.
>>>>
>>>>         :while 1 | let s = input('') | echo "\n" | endw
>>>>
>>>>      one would expect to see a succession of strings that he enters.
>>>>      Instead, we are left with nothing but empty lines.
>>>>      This bug seems to be very old, and seriously hampers writing
>>>>      interactive vimscriptlets.
>>>
>>> Try this:
>>>
>>>          :while 1 | let s = input('') | echo s "\n" | endw
>>>
>>> Not sure this is a bug.  If someone wants to erase the typed text this
>>> would work now but not when making it work the way you suggest.
>>>
>>>
>>>> 2. Under Linux + GTK, all Unicode characters combined-accented with
>>>>      U+0300, U+0301, ... (any of those) are incorrectly displayed:
>>>>      the accent is either (mis)placed above the character on the left,
>>>>      or is not displayed at all.
>>>>      This seems to have originated with Vim 7.2.
>>>
>>> I see this too.  I can fix it with this change:
>>>
>>>
>>> --- a/gui_gtk_x11.c 2010-07-25 15:48:22.000000000 +0200
>>> +++ b/gui_gtk_x11.c 2010-08-05 23:09:43.000000000 +0200
>>> @@ -5108,10 +5108,11 @@
>>>
>>>        /* There is a previous glyph, so we deal with combining
>>>         * characters the canonical way.  That is, setting the
>>> -     * width of the previous glyph to 0. */
>>> +     * width of the previous glyph to 0 and set the x_offset
>>> +     * to puth the accent glyph in the middle. */
>>>        glyphs->glyphs[i - 1].geometry.width = 0;
>>>        width = cells * gui.char_width * PANGO_SCALE;
>>> -    glyph->geometry.x_offset +=
>>> +    glyph->geometry.x_offset =
>>>        MAX(0, width - cluster_width) / 2;
>>>    #if 0
>>>        /* Dirty hack: for "monospace 13" font there is a bug that
>>>
>>>
>>> But that might break it for others...
>>>
>>
>> After applying this patch (changeset 2070b63605a7 dated 2010-08-07
>> 15:46:45 +0200), my gvim display is worse than before.
>>
>> I'm using Bitstream Vera Sans Mono 8 in gvim (Huge) +gui_gtk2 +gui_gnome
>> and currently I'm editing a Russian dictionary, with many combining
>> acute accents (U+0301) over Cyrillic vowels.
>>
>> Before the patch, the accents came beautifully over the concerned
>> vowels. After the patch, the accent is displayed too much to the right,
>> between the concerned vowel and the next letter. This resembles what I
>> get with Times New Roman in the Mozilla SeaMonkey browser; it is not as
>> bad, though, as what I see with "monospace" (not sure which font this
>> brings) in the SeaMonkey mailer, where the accent is squarely over the
>> next letter, one character width to the right of where it ought to be.
>>
>> So I suspect that this is a font-related problem. Boyko, what 'guifont'
>> are you using?
>>
>> Bram, is it possible to know the width of the glyph, in order not to
>> move it so far to the right that it overshoots the next character? Also,
>> what will happen in Arabic, where it is common (at least in Koranic
>> Arabic) to have two combining characters over a single spacing letter?
>> For instance: in the formula, "to the name of God the Benevolent the
>> Merciful", bismillâh ar-rahmân ar-rahîm,
>> ب٠سْم٠ Ù±Ù„لّٰه٠ Ù±Ù„رَّحْمٰن٠ Ù±Ù„رَّح٠يم٠؛
>> in the last (leftmost) two words (of four), the third consonant (which
>> goes down below the line and is not joined to the next one to its left)
>> has two combining signs, making it in both cases rah + shadda + fatha,
>> U+0631 + U+0651 + U+064E
>>
>> I'm attaching an "Arabic testcase" file which displays horribly in this
>> new Vim changeset. Use ":setlocal arabic" to display the Arabic text RTL
>> as it should be, then compare lines 87-92 (in vocalized Arabic) with
>> lines 94-99 (the same text without the combining characters). You should
>> see the same consonants, just without the combining marks (the
>> "harakaat" as they're called in Arabic) but that's not what I see. Some
>> letters move about, others disappear completely, moving the cursor over
>> the text makes the letters go left or right... (The unvocalized part,
>> lines 94-99, is displayed correctly.)
>>
>> Since this testcase is HTML, you can also view it in a browser; however
>> even browsers may display the consonants differently because when there
>> exists a digram or a trigram to make some letter-combinations "nicer",
>> the browser may not recognise it if there is a combining mark in the
>> middle. This, however, should not affect Vim, which pays no attention to
>> polygrams other than lam+alif.
>
> Sorry, these scribbles don't show me what's wrong.  Viewing the text in
> a browser looks completely different.

These "scribbles", as you call them, are Arabic text, representing a
common salutation, "May peace be with you, and God's benevolence and His
blessings" (lines 87 and 94), plus the first half of the Fatiha, the
first and shortest sûra of the Qur`an (lines 89-92 and 96-99). Text in
the browser vs. in gvim is just "proportional" vs. "monospaced" text;
the difference comes from the high prestige calligraphy has always had
in Arabic, whose flowing writing is not really made for a monospaced
kind of font.

View the file in gvim with 'encoding' set to utf-8 and :setlocal arabic.
The fact that I also have 'cursorline' and 'cursorcolumn' both on may be
relevant, I'm not sure. The following "wrong behaviour" happens with
'guifont' set to "Bitstream Vera Sans Mono 8", "Luxi Mono 8" or "DejaVu
Sans Mono 8" but not with "Courier New 8" or "Lucida Sans Typewriter 8";
I don't know why (and remember: use either
        :let &gfn = "quoted value"
or
        :set gfn=value\ with\ spaces\ escaped
).

Lines 87-92 should (but for me they don't) look the same as lines 94-99
except that the latter have no combining characters. Now move the
Normal-mode cursor this way and that using hjkl over the text in lines
87-92. With the latest changeset (3607f126a661 "use different Czech
keymap") what I see is that the file looks "bad" when loaded, with
approximately every second letter replaced by a space, and some letters
displayed one character cell off or even two, thus "erasing" what
belongs there; then moving the cursor left and right over a line
"corrects" what the cursor has gone over, but moving the cursor to a
different line, or hitting Ctrl-L, makes the text "bad" again.

To know which "scribbles" are spacing characters and which ones are
combining characters, use ga. The first glyph (the spacing one) should
be repeated at the same position in lines 94-99. There may also be
combining characters: usually one, sometimes zero or two.

>
> Please try the latest version, I solved it in a slightly different way.
> For older GTK versions it might do the same as before.
>

My GTK2 package is called "gtk2-2.20.1-2.13.i586" as distributed with
openSUSE Linux 11.3.


Best regards,
Tony.

--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
12