Your requested mail has been attached.

Greetings, Vim users.

You may have noticed patches for Vim 7 appear at a slow pace.  I
currently have limited time to work on Vim.  And my internet connection
isn't 100% reliable, and SourceForge was down for a day, and [insert
your favorite excuse here]...

On the positive side: I found a nice apartment in Zurich.  Once I have
moved in there and have a proper internet connection again I'll try to
work away the most important items in the todo list.  First the ones for
which I have received a patch (hint!).


While we are enjoying unusually sunny weather here in western Europe,
children in Uganda are suffering from an unusual drought.  Especially in
the area around Kibaale the situation is really bad.  Planted crops
withered and died.  It has not been this bad since 1992.

Kibaale Childrens Centre (KCC), the charity supported by Vim, has
started food assistance to over 400 families.  This has helped them
through the most difficult period.  However, we expect the families to
run out of food again after August, by the end of the dry season.  We
need to prepare to help the children and their families again.

For more background information read about the famine relief program:

	 http://iccf-holland.org/famine2006.html

Please consider making a donation this month!

- Bram

--
Tips for aliens in New York: Land anywhere.  Central Park, anywhere.
No one will care or indeed even notice.
		 -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy"

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

Mail transaction failed. Partial message is available.

Your document is attached.

Mail transaction failed. Partial message is available.

The message contains Unicode characters and has been sent as a binary
attachment.

Hi,
I try to map the alt key to some function in gvim, but it does not work.
I use the zh_CN.UTF-8 locale in linux with gnome, and gvim is gtk
version. After mapping <M-x> (x is a letter or number key) in insert
mode, I get an x in insert mode when type the <M-x> key. But mapping
<M-Left> (and <M-Right>...) do work.

I change the LC_CTYPE to en_US.UTF-8, the mappings have no problem. But
I can not input Chinese if I set LC_CTYPE to en_US.UTF-8. Is there a
solution to this problem? Thank you.

Best regards,

Dingkun Zhong

Zhong, Dingkun wrote:
> Hi,
> I try to map the alt key to some function in gvim, but it does not work.
> I use the zh_CN.UTF-8 locale in linux with gnome, and gvim is gtk
> version. After mapping <M-x> (x is a letter or number key) in insert
> mode, I get an x in insert mode when type the <M-x> key. But mapping
> <M-Left> (and <M-Right>...) do work.
>
> I change the LC_CTYPE to en_US.UTF-8, the mappings have no problem. But
> I can not input Chinese if I set LC_CTYPE to en_US.UTF-8. Is there a
> solution to this problem? Thank you.

I guess your 'imactivatekey' is not set.  In that case, Vim always pass
inputted key to Input Method.  If the Input Method catch the <M-x> key and
drop the modifier, "x" is inserted.  It happened for me when
GTK_IM_MODULE=xim.  I can use <M-x> when 'imactivatekey' is set to something
or GTK_IM_MODULE=scim (or uim or iiim).

--
Yukihiro Nakadaira <hopper2@...>

Thanks for your help. I solve the problem with your instruction.

Yukihiro Nakadaira wrote:
> Zhong, Dingkun wrote:
>> Hi,
>> I try to map the alt key to some function in gvim, but it does not
>> work. I use the zh_CN.UTF-8 locale in linux with gnome, and gvim is
>> gtk version. After mapping <M-x> (x is a letter or number key) in
>> insert mode, I get an x in insert mode when type the <M-x> key. But
>> mapping <M-Left> (and <M-Right>...) do work.
>>
>> I change the LC_CTYPE to en_US.UTF-8, the mappings have no problem.
>> But I can not input Chinese if I set LC_CTYPE to en_US.UTF-8. Is
>> there a solution to this problem? Thank you.
>
> I guess your 'imactivatekey' is not set.  In that case, Vim always pass
> inputted key to Input Method.  If the Input Method catch the <M-x> key
> and
> drop the modifier, "x" is inserted.  It happened for me when
> GTK_IM_MODULE=xim.  I can use <M-x> when 'imactivatekey' is set to
> something
> or GTK_IM_MODULE=scim (or uim or iiim).
>

The message contains Unicode characters and has been sent as a binary
attachment.

The message contains Unicode characters and has been sent as a binary
attachment.

Here is the website. ;-)

I hope the patch works.

Hi,
I am interested in adding support for Syriac in Vim. Syriac is similar to
Arabic, Hebrew, and Farsi. It is right-to-left and has its own shaping rules.

Where do I start? I will appreciate your help.

Thanks
Tony Khoshaba

Tony Khoshaba wrote:
> Hi,
> I am interested in adding support for Syriac in Vim. Syriac is similar to
Arabic, Hebrew, and Farsi. It is right-to-left and has its own shaping rules.
>
> Where do I start? I will appreciate your help.
>
> Thanks
> Tony Khoshaba
>

If I were you, I'd have a serious hard look at arabic.c and arabic.h in
the src/ subdirectory of wherever you downloaded (or will have
downloaded) the Vim source. IIUC, the rules for Syriac should be similar
to those for Arabic, except that the Unicode blocks for isolated glyphs
and for presentation forms (i.e., initial, medial, final and possibly
digraph or multicharacter forms if any) would be different, and that any
"national.


Bset regards,
Tony.

Tony Khoshaba wrote:
> Hi,
> I am interested in adding support for Syriac in Vim. Syriac is similar to
Arabic, Hebrew, and Farsi. It is right-to-left and has its own shaping rules.
>
> Where do I start? I will appreciate your help.
>
> Thanks
> Tony Khoshaba
>

If I were you, I'd have a serious hard look at arabic.c and arabic.h in
the src/ subdirectory of wherever you downloaded (or will have
downloaded) the Vim source. IIUC, the rules for Syriac should be similar
to those for Arabic, except that the Unicode blocks for isolated glyphs
and for presentation forms (i.e., initial, medial, final and possibly
digraph or multicharacter forms if any) would be different, and that any
"national ISO-8859-n encoding" would also be different.


Bset regards,
Tony.

Tony Khoshaba wrote:
> If you were to create a list things to do to do this project what would
> it be?

1. Look how the Arabic module does it.
2. Look how the Arabic module is hooked into the main loop.
3. Look in http://www.unicode.org/charts/ how Arabic and Syriac Unicode
blocks (including presentation forms) differ.
4. Take into account any idiosyncrasies of either language (such as the
fact that Arabic laam+alif is a mandatory digraph).
5. Either you can do it, or you can't. If you can, write it. If you
can't, leave it, but (if possible) upload your notes on the Web. Maybe
someone else will pick it up where you left.



Best regards,
Tony.

I am motivated to do it. But first would like to outline the list of things to
do.
I once wrote a rendering engine in Dephi and hooked it to a Windows edit box and
used a TTF font for it. That was before Microsoft added Syriac rendering engine
to professional XP. But most people do not have access to professional XP.

To adopt my Syriac TTF fonts for such project what should I do? Sorry for asking
basic questions but my knowledge in this area has become rusty and I need to
come to speed.

Tony

"A.J.Mechelynck" <antoine.mechelynck@...> wrote: Tony Khoshaba wrote:
> If you were to create a list things to do to do this project what would
> it be?

1. Look how the Arabic module does it.
2. Look how the Arabic module is hooked into the main loop.
3. Look in http://www.unicode.org/charts/ how Arabic and Syriac Unicode
blocks (including presentation forms) differ.
4. Take into account any idiosyncrasies of either language (such as the
fact that Arabic laam+alif is a mandatory digraph).
5. Either you can do it, or you can't. If you can, write it. If you
can't, leave it, but (if possible) upload your notes on the Web. Maybe
someone else will pick it up where you left.



Best regards,
Tony.

If you were to create a list things to do to do this project what would it be?

Tony

"A.J.Mechelynck" <antoine.mechelynck@...> wrote: Tony Khoshaba wrote:
> Hi,
> I am interested in adding support for Syriac in Vim. Syriac is similar to
Arabic, Hebrew, and Farsi. It is right-to-left and has its own shaping rules.
>
> Where do I start? I will appreciate your help.
>
> Thanks
> Tony Khoshaba
>

If I were you, I'd have a serious hard look at arabic.c and arabic.h in
the src/ subdirectory of wherever you downloaded (or will have
downloaded) the Vim source. IIUC, the rules for Syriac should be similar
to those for Arabic, except that the Unicode blocks for isolated glyphs
and for presentation forms (i.e., initial, medial, final and possibly
digraph or multicharacter forms if any) would be different, and that any
"national ISO-8859-n encoding" would also be different.


Bset regards,
Tony.

Tony Khoshaba wrote:
>
> I am motivated to do it. But first would like to outline the list of
> things to do.
> I once wrote a rendering engine in Dephi and hooked it to a Windows edit
> box and used a TTF font for it. That was before Microsoft added Syriac
> rendering engine to professional XP. But most people do not have access
> to professional XP.
>
> To adopt my Syriac TTF fonts for such project what should I do? Sorry
> for asking basic questions but my knowledge in this area has become
> rusty and I need to come to speed.
>
> Tony


If your Syriac TTF fonts include all the necessary glyphs, they
shouldn't be the problem; they should work "out of the box" once the
support for the Syriac alphabet will have been built into the C source
of Vim, just by setting 'guifont', 'rightleft', etc. to proper settings.
The problem is to have Vim display the proper contextual forms in the
proper contexts, like it does for Arabic, and that requires a C module
which should IMHO be very similar to the Arabic one.


Best regards,
Tony.

If this is the case then the project looks easier. Adding Syriac would mean just
changing some of the shaping rules for Arabic. But my impression was that there
is more into font design than just using a TTF font out of the box. Anyway nut I
thing I have enough material to work with.

So if I start with Windows version of Vim, can I build it straight forwardly
using Microsoft VC++ tools?

Tony


"A.J.Mechelynck" <antoine.mechelynck@...> wrote: Tony Khoshaba wrote:
>
> I am motivated to do it. But first would like to outline the list of
> things to do.
> I once wrote a rendering engine in Dephi and hooked it to a Windows edit
> box and used a TTF font for it. That was before Microsoft added Syriac
> rendering engine to professional XP. But most people do not have access
> to professional XP.
>
> To adopt my Syriac TTF fonts for such project what should I do? Sorry
> for asking basic questions but my knowledge in this area has become
> rusty and I need to come to speed.
>
> Tony


If your Syriac TTF fonts include all the necessary glyphs, they
shouldn't be the problem; they should work "out of the box" once the
support for the Syriac alphabet will have been built into the C source
of Vim, just by setting 'guifont', 'rightleft', etc. to proper settings.
The problem is to have Vim display the proper contextual forms in the
proper contexts, like it does for Arabic, and that requires a C module
which should IMHO be very similar to the Arabic one.


Best regards,
Tony.

Tony Khoshaba wrote:
> If this is the case then the project looks easier. Adding Syriac would
> mean just changing some of the shaping rules for Arabic. But my
> impression was that there is more into font design than just using a TTF
> font out of the box. Anyway nut I thing I have enough material to work
> with.
>
> So if I start with Windows version of Vim, can I build it straight
> forwardly using Microsoft VC++ tools?

Adding Arabic to Vim required no change in the existing fonts: once I
had a gvim with +arabic, I could edit Arabic text, even vocalised
Arabic, using the Courier_New font that came with Windows; but Syriac is
a "rarer" language than Arabic, you may have to make sure that you have
a fixed-width font with Syriac glyphs. Start with Courier_New and use
":set guifont=*" if that doesn't work. After using ":set guifont=*" I
recommend to use ":set guifont=<Tab>" to replace the :c part of the font
by :cDEFAULT as in (for example) ":set guifont=Courier_New:h12:cDEFAULT"
-- with that setting I've been able to see Latin, Russian and Arabic
text in a single file (of course, seeing the Arabic text "properly"
required toggling the text direction with ":setlocal invrightleft").

You should be able to edit the Vim C source with Vim itself, then build
it with any set of make, C/C++ compiler and linker that can work
together. I have used Borland BCC32 and Cygwin gcc, but yes, MSVC has
also been used. In that case, the makefile to use is src/Make_mvc.mak .
You may want to set some configuration settings by means of environment
variables before running make, but I'm not sure of the details -- MSVC
is one compiler I haven't used. You may want to look at the comments in
the Make_mvc.mak and/or at how I have built Vim for Windows using BCC
and (later) gcc, see
http://users.skynet.be/antoine.mechelynck/vim/compile.htm .

Once you have a working patch for Vim, don't forget to submit it to Bram
for inclusion into the "official" source. ;-)


Best regards,
Tony.

Great info thank you. I was playing with Courier_New as well. I was wondering
what proper tool I can use to just add Syriac to Courier_New and name it
something else so the same way Syriac would be supported along with other
languages using the same font.

Tony

"A.J.Mechelynck" <antoine.mechelynck@...> wrote: Tony Khoshaba wrote:
> If this is the case then the project looks easier. Adding Syriac would
> mean just changing some of the shaping rules for Arabic. But my
> impression was that there is more into font design than just using a TTF
> font out of the box. Anyway nut I thing I have enough material to work
> with.
>
> So if I start with Windows version of Vim, can I build it straight
> forwardly using Microsoft VC++ tools?

Adding Arabic to Vim required no change in the existing fonts: once I
had a gvim with +arabic, I could edit Arabic text, even vocalised
Arabic, using the Courier_New font that came with Windows; but Syriac is
a "rarer" language than Arabic, you may have to make sure that you have
a fixed-width font with Syriac glyphs. Start with Courier_New and use
":set guifont=*" if that doesn't work. After using ":set guifont=*" I
recommend to use ":set guifont=" to replace the :c part of the font
by :cDEFAULT as in (for example) ":set guifont=Courier_New:h12:cDEFAULT"
-- with that setting I've been able to see Latin, Russian and Arabic
text in a single file (of course, seeing the Arabic text "properly"
required toggling the text direction with ":setlocal invrightleft").

You should be able to edit the Vim C source with Vim itself, then build
it with any set of make, C/C++ compiler and linker that can work
together. I have used Borland BCC32 and Cygwin gcc, but yes, MSVC has
also been used. In that case, the makefile to use is src/Make_mvc.mak .
You may want to set some configuration settings by means of environment
variables before running make, but I'm not sure of the details -- MSVC
is one compiler I haven't used. You may want to look at the comments in
the Make_mvc.mak and/or at how I have built Vim for Windows using BCC
and (later) gcc, see
http://users.skynet.be/antoine.mechelynck/vim/compile.htm .

Once you have a working patch for Vim, don't forget to submit it to Bram
for inclusion into the "official" source. ;-)


Best regards,
Tony.

Tony Khoshaba wrote:
> Great info thank you. I was playing with Courier_New as well. I was
> wondering what proper tool I can use to just add Syriac to Courier_New
> and name it something else so the same way Syriac would be supported
> along with other languages using the same font.

I don't know how to edit fonts; if you do it, make sure that all your
Courier_New glyphs (including the existing Latin glyphs) have exactly
the same dimensions: height, width, and height of the top and bottom of
a letter like lowercase x relative to the character cell. Anyway, I
don't know of any fixed-width font covering the full Unicode range: when
editing my front page
http://users.skynet.be/antoine.mechelynck/index.htm , which has not only
Latin but also Cyrillic (Russian) and East-Asian (Chinese and Japanese)
text, I have to change the 'guifont' depending on which part I'm editing.

If your Courier_New font hasn't got (even with :cDEFAULT) the Syriac
glyphs you need, well, try to find a fixed-with font with a different
name, providing the Syriac glyphs, and also if possible the basic Latin
glyphs. Or you might want to check if there is a language pack that
includes Syriac on the Windows Update site: installing that might be
enough to add the required glyphs to Courier_New (and also to common
"proportional" fonts like Arial or Times New Roman: Vim cannot use them,
but if you create HTML pages in Syriac you can load them in your
favourite browser to check that they display OK).


Best regards,
Tony.

Yukihiro Nakadaira wrote:

> I am using GTK2 GUI.  When using Input Method, undo sequence is broken at
> each start of multibyte character.  For example, after insert some multibyte
> characters (A B C),
>   line: A B C
> Do undo
>   line: A B C
> Do undo
>   line: A B
> Do undo
>   line: A
> Do undo
>   line:
> I must undo four times to undo one insert command.
>
> When using Input Method, Left key is added to typeahead buffer by
> mbyte.c:im_correct_cursor().  Then, the Left key command is interpreted and
> later new undo sequence is started.  To avoid this problem, check if
> im_is_preediting() is true in start_arrow().
>
> Thanks.
>
>
> *** edit.c.orig Fri Aug 25 06:14:48 2006
> --- edit.c Fri Aug 25 06:14:55 2006
> ***************
> *** 6026,6031 ****
> --- 6026,6035 ----
>   start_arrow(end_insert_pos)
>       pos_T    *end_insert_pos;     /* can be NULL */
>   {
> + #if defined(FEAT_XIM) && defined(FEAT_GUI_GTK)
> +     if (im_is_preediting())
> +  return; 	    /* XIM is busy, don't break an undo sequence */
> + #endif
>       if (!arrow_used)     /* something has been inserted */
>       {
>    AppendToRedobuff(ESC_STR);

I don't understand why the cursor is moved.  This appears to happen
after inserting characters, thus moving cursor to before these inserted
characters.  Hmm, it appears they are later deleted with the Del key.

I find it a little bit dangerous to simply return from start_arrow().
To make this a bit more strict perhaps the call to start_arrow() in
ins_left() can be skipped when im_is_preediting() returns TRUE?

--
A computer without Windows is like a fish without a bicycle.

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

Bram Moolenaar wrote:
> I don't understand why the cursor is moved.  This appears to happen
> after inserting characters, thus moving cursor to before these inserted
> characters.  Hmm, it appears they are later deleted with the Del key.

Cursor is moved just for displaying.  And also cursor can be positioned
at middle of preedit string.

Those inserted characters are preedit string.  Preedit string is
temporarily inserted to show what is to be inserted (like a Vim's
completion).  It can be edited with Input Method until it is committed.
"commit" means inserting edited string.  When preedit string is changed,
it is deleted and new preedt string is inserted.  When preedit string is
committed, it is deleted and the edited string is inserted really.

> I find it a little bit dangerous to simply return from start_arrow().
> To make this a bit more strict perhaps the call to start_arrow() in
> ins_left() can be skipped when im_is_preediting() returns TRUE?

I agree with you.  I think that im_is_preediting() returns TRUE only
when start_arrow() is called from ins_left().

--
Yukihiro Nakadaira - yukihiro.nakadaira@...

# I failed in sending this mail.  I'll resend it.

This is old subject but I think this report might help someone.

When using GTK2 GUI and XIM and GTK_IM_MODULE=scim, one undo command undoes
several insert command because undo sequence is not broken.  And also it
causes error E438.  This is because ...
1. scim doesn't invoke im_preedit_start_cb() and im_preedit_end_cb(), so the
    xim_has_preediting can be reset in im_preedit_changed_cb() only.
2. To delete preedit, scim invoke im_preedit_changed_cb() with empty
    preedit string only one time.  But at the time preedit_start_col is not
    MAXCOL and xim_is_preediting is not reset.
Therefore xim_is_preediting is always TRUE and undo sequence is not broken
(u_sync() is canceled).

This problem can be avoided to use OverTheSpot instead of OnTheSpot (this
can be set with scim-setup), or to set environment variables,
GTK_IM_MODULE=xim and XMODIFIERS=@im=SCIM, or to use the following patch.
The code around there was added at 6.2.451.  I don't understand why checking
if preedit_start_col is MAXCOL.  I think that the line can be removed.


*** mbyte.c.orig Mon Aug 28 17:19:28 2006
--- mbyte.c Mon Aug 28 17:19:30 2006
***************
*** 3741,3748 ****
       }
       else if (cursor_index == 0 && preedit_string[0] == '\0')
       {
!  if (preedit_start_col == MAXCOL)
! 	    xim_has_preediting = FALSE;

  	 /* If at the start position (after typing backspace)
  	  * preedit_start_col must be reset. */
--- 3741,3747 ----
       }
       else if (cursor_index == 0 && preedit_string[0] == '\0')
       {
!  xim_has_preediting = FALSE;

  	 /* If at the start position (after typing backspace)
  	  * preedit_start_col must be reset. */


-- Yukihiro Nakadaira <hopper2@...>

Yukihiro Nakadaira wrote:

> This is old subject but I think this report might help someone.
>
> When using GTK2 GUI and XIM and GTK_IM_MODULE=scim, one undo command undoes
> several insert command because undo sequence is not broken.  And also it
> causes error E438.  This is because ...
> 1. scim doesn't invoke im_preedit_start_cb() and im_preedit_end_cb(), so the
>    xim_has_preediting can be reset in im_preedit_changed_cb() only.
> 2. To delete preedit, scim invoke im_preedit_changed_cb() with empty
>    preedit string only one time.  But at the time preedit_start_col is not
>    MAXCOL and xim_is_preediting is not reset.
> Therefore xim_is_preediting is always TRUE and undo sequence is not broken
> (u_sync() is canceled).
>
> This problem can be avoided to use OverTheSpot instead of OnTheSpot (this
> can be set with scim-setup), or to set environment variables,
> GTK_IM_MODULE=xim and XMODIFIERS=@im=SCIM, or to use the following
> patch.  The code around there was added at 6.2.451.  I don't
> understand why checking if preedit_start_col is MAXCOL.  I think that
> the line can be removed.

Most of the variables involved aren't properly explained, thus I can't
oversee what happens here.  I'll assume your fix is right and doesn't
cause trouble for someone with another setup.

--
hundred-and-one symptoms of being an internet addict:
254. You wake up daily with your keyboard printed on your forehead.

  /// 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 contains Unicode characters and has been sent as a binary
attachment.