Nagano wrote:

> Now, please let me change vim against for following problem.
> I hope these patch will be included in vim5.7.

I'm currently working very hard to bring out the first Vim 6.0 test version.
It will include a lot of multi-byte changes, mostly to support UTF-8.
The work on 5.7 patches will be slow for a while.

Anyway, thanks for your patches.  I'll include them later.

This change doesn't look right:

> @@ -3130,6 +3130,26 @@
>   gtk_main();  /* wait for selection_received_event */
>
>      if (received_selection == RS_FAIL)
> +    {
> + /* Now try to get it out of the usual string selection. */
> + received_selection = RS_NONE;
> + (void)gtk_selection_convert(gui.drawarea, GDK_SELECTION_PRIMARY,
> + 			    gdk_atom_intern("COMPOUND_TEXT", FALSE),
> + 			    (guint32)GDK_CURRENT_TIME);
> + while (received_selection == RS_NONE)
> +     gtk_main();  /* wait for selection_received_event */
> +    }
> +    else if (received_selection == RS_FAIL)
> +    {
> + /* Now try to get it out of the usual string selection. */
> + received_selection = RS_NONE;
> + (void)gtk_selection_convert(gui.drawarea, GDK_SELECTION_PRIMARY,
> + 			    gdk_atom_intern("TEXT", FALSE),
> + 			    (guint32)GDK_CURRENT_TIME);
> + while (received_selection == RS_NONE)
> +     gtk_main();  /* wait for selection_received_event */
> +    }
> +    else if (received_selection == RS_FAIL)
>      {
>   /* Now try to get it out of the usual string selection. */
>   received_selection = RS_NONE;

It seems only the first "if" is every used.  Shouldn't those "else if" be
changed to "if"?

--
hundred-and-one symptoms of being an internet addict:
144. You eagerly await the update of the "Cool Site of the Day."

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Invitation for Vim presentation

There will be a presentation about Vim on the WAN event (We Are Networking).
This is a camp site in the north-east of Holland where computer enthousiasts
meet for a week.  More info about WAN: http://www.wan.nl .

I will do the presentation on Saturday July 29, starting at 14:30h.  Everybody
is welcome to listen and discuss about Vim.  If possible, there will also be a
workshop to tackle some Vim issues.  Perhaps we can implement a new feature
together?

There is an entrance fee, they provide a whole program for that.  Before my
presentation there is another one on Sendmail.  You can spend the night there
(if you bring a tent).  I have never been there before, but it looks like
there is going to be a lot of fun besides the serious computer stuff.

Depending on the audience the presentation will be in Dutch or English.  There
will be plenty of time to meet Vim users and developers (and me!).

--
Microsoft's definition of a boolean: TRUE, FALSE, MAYBE
"Embrace and extend"...?

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Hello,

I just re-made the OnTheSpot patch against vim-6.0b.
It worked fine for me.
If you have any problem with the OnTheSpot patch, please test
with removing the 'GDK_IM_PREEDIT_CALLBACKS' in multibyte.c, line 1487(?).
Then gvim may run using OverTheSpot. Please reply your result.
I test it with gtk+-1.2.8.

regards,

namsh

diff -u -u -r1.2 gui_gtk_x11.c
--- ./src/gui_gtk_x11.c 2000/07/17 00:34:31 1.2
+++ ./src/gui_gtk_x11.c 2000/07/17 00:48:34
@@ -566,6 +566,14 @@
      state = event->state;
      g_assert(len <= sizeof(string));

+#ifdef FEAT_XIM
+    {
+ extern int xim_queue_key_press_event(GdkEvent *ev);
+ if (xim_queue_key_press_event((GdkEvent *) event))
+     return TRUE;
+    }
+#endif
+
  #ifdef FEAT_HANGULIN
      if (event->keyval == GDK_space && (state & GDK_SHIFT_MASK))
      {
@@ -1108,6 +1116,14 @@
       */
      if (event->type != GDK_BUTTON_PRESS)
 	 return FALSE;
+
+#ifdef FEAT_XIM
+    {
+ extern void xim_reset(void);
+
+ xim_reset();
+    }
+#endif

      x = event->x;
      y = event->y;
diff -u -u -r1.2 multibyte.c
--- ./src/multibyte.c 2000/07/17 00:34:32 1.2
+++ ./src/multibyte.c 2000/07/17 00:48:34
@@ -1484,6 +1484,8 @@
      GdkIMStyle supported_style = GDK_IM_PREEDIT_NONE |
 				  GDK_IM_PREEDIT_NOTHING |
 				  GDK_IM_PREEDIT_POSITION |
+ 			 GDK_IM_PREEDIT_CALLBACKS |
+ 			 /* GDK_IM_STATUS_CALLBACKS | */
 				  GDK_IM_STATUS_AREA |
 				  GDK_IM_STATUS_NONE |
 				  GDK_IM_STATUS_NOTHING;
@@ -1511,8 +1513,148 @@
      }
  }

+#include <gdk/gdkx.h>
+
+    static void
+preedit_start_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    static void
+xim_back_delete(int n)
+{
+    char str[3];
+
+    str[0] = CSI;
+    str[1] = 'k';
+    str[2] = 'b';
+    while (n-- > 0)
+ add_to_input_buf(str, 3);
+}
+
+static GSList *key_press_event_queue = NULL;
+static int preedit_buf_len = 0;
+
+    static void
+preedit_draw_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+    XIMPreeditDrawCallbackStruct *draw_data;
+    XIMText *text;
+    GdkWChar *wstr = NULL;
+    char *src;
+    GSList *event_queue;
+    extern int draw_queue_flush(void);
+
+    draw_data = (XIMPreeditDrawCallbackStruct *) call_data;
+    text = (XIMText *) draw_data->text;
+
+    if (draw_data->chg_length > 0)
+    {
+ xim_back_delete(draw_data->chg_length);
+ preedit_buf_len -= draw_data->chg_length;
+    }
+    if (text && (src = text->string.multi_byte))
+    {
+ int len = strlen(src);
+
+ wstr = g_new(GdkWChar, len);
+ preedit_buf_len += gdk_mbstowcs(wstr, src, len);
+ g_free(wstr);
+ add_to_input_buf(src, len);
+    }
+    event_queue = key_press_event_queue;
+    while (event_queue)
+    {
+ GdkEvent *ev = event_queue->data;
+ gboolean *ret;
+ gtk_signal_emit_by_name((GtkObject*)gui.mainwin, "key_press_event",
+ 		 ev, &ret);
+ gdk_event_free(ev);
+ event_queue = event_queue->next;
+    }
+    if (key_press_event_queue)
+    {
+ g_slist_free(key_press_event_queue);
+ key_press_event_queue = NULL;
+    }
+    if (gtk_main_level() > 0)
+ gtk_main_quit();
+}
+
+    static void
+preedit_caret_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    static void
+preedit_done_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    void
+xim_reset(void)
+{
+    char * text;
+
+    if (xic)
+    {
+ text = XmbResetIC(((GdkICPrivate *)xic)->xic);
+ if (!(xim_input_style & GDK_IM_PREEDIT_CALLBACKS))
+     add_to_input_buf(text, strlen(text));
+ else
+     preedit_buf_len = 0;
+ if (text)
+     XFree(text);
+    }
+}
+
+    int
+xim_queue_key_press_event(GdkEvent *ev)
+{
+    if (preedit_buf_len <= 0)
+ return FALSE;
+
+    key_press_event_queue = g_slist_append(key_press_event_queue,
+                                           gdk_event_copy(ev));
+    return TRUE;
+}
+
+    static void
+preedit_callback_setup(GdkIC *ic)
+{
+    XIC xxic;
+    XVaNestedList preedit_attr;
+    XIMCallback preedit_start_cb;
+    XIMCallback preedit_draw_cb;
+    XIMCallback preedit_caret_cb;
+    XIMCallback preedit_done_cb;
+
+    xxic = ((GdkICPrivate*)xic)->xic;
+    preedit_start_cb.callback = (XIMProc)preedit_start_cbproc;
+    preedit_draw_cb.callback = (XIMProc)preedit_draw_cbproc;
+    preedit_caret_cb.callback = (XIMProc)preedit_caret_cbproc;
+    preedit_done_cb.callback = (XIMProc)preedit_done_cbproc;
+    preedit_attr
+ = XVaCreateNestedList (0,
+ 		       XNPreeditStartCallback, &preedit_start_cb,
+ 		       XNPreeditDrawCallback, &preedit_draw_cb,
+ 		       XNPreeditCaretCallback, &preedit_caret_cb,
+ 		       XNPreeditDoneCallback, &preedit_done_cb,
+ 		       XNPreeditStartCallback, &preedit_start_cb,
+ 		       0);
+    XSetICValues (xxic, XNPreeditAttributes, preedit_attr, 0);
+    XFree(preedit_attr);
+}
+
+    static void
+reset_state_setup(GdkIC *ic)
+{
+    /* don't change the input context when we call reset */
+    XSetICValues(((GdkICPrivate*)ic)->xic, XNResetState, XIMPreserveState, 0);
+}
+
      void
-xim_init()
+xim_init(void)
  {
      xic = NULL;
      xic_attr = NULL;
@@ -1584,6 +1726,11 @@
 		 attr->status_fontset = gui.fontset;
 	     }
 	 }
+ else if ((xim_input_style & GDK_IM_STATUS_MASK)
+ 	 == GDK_IM_STATUS_CALLBACKS)
+ {
+     /* FIXME */
+  }
  #endif

 	 xic = gdk_ic_new(attr, attrmask);
@@ -1595,6 +1742,9 @@
 	     mask = gdk_window_get_events(widget->window);
 	     mask |= gdk_ic_get_events(xic);
 	     gdk_window_set_events(widget->window, mask);
+     if (xim_input_style & GDK_IM_PREEDIT_CALLBACKS)
+  preedit_callback_setup(xic);
+     reset_state_setup(xic);
 	 }
      }
  }

Sung-Hyun -

> I just re-made the OnTheSpot patch against vim-6.0b.
> It worked fine for me.
> If you have any problem with the OnTheSpot patch, please test
> with removing the 'GDK_IM_PREEDIT_CALLBACKS' in multibyte.c, line 1487(?).
> Then gvim may run using OverTheSpot. Please reply your result.
> I test it with gtk+-1.2.8.

Should I include this patch in Vim 6.0?  I don't mind if it's a bit risky, as
long as we will be able to solve problems later.

- Bram

--
     f y cn rd ths thn y cn hv grt jb n cmptr prgrmmng

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Hello, vim team,

This is patch for vim-6.0b.
The code included in vim-6.0b is a buggy one.
(Sorry, Bram. That's my fault.)

--- search.c.orig Mon Jul 17 21:43:57 2000
+++ search.c Mon Jul 17 21:58:26 2000
@@ -2265,7 +2265,6 @@
 	 }
 	 else if (cc_dbcs == (int)DBCS_KOR)
 	 {
-     /* TODO: this code has been reported not to work correctly! */
 	     /*
 	      * If stype is non-zero, report these as class 1.
 	      */
@@ -2291,6 +2290,14 @@
 	     if (c1 >= 0xB0 && c1 <= 0xC8)
 		 /* Hangul */
 		 return 20;
+#ifdef WIN32
+     else if (c1 <= 0xA0 || c2 <= 0xA0)
+  /* Extended Hangul Region : MS UHC(Unified Hangul Code) */
+  /* c1: 0x81-0xA0 with c2: 0x41-0x5A, 0x61-0x7A, 0x81-0xFE
+ 	 * c1: 0xA1-0xC6 with c2: 0x41-0x5A, 0x61-0x7A, 0x81-0xA0
+ 	 */
+  return 20;
+#endif
 	     else if (c1 >= 0xCA && c1 <= 0xFD)
 		 /* Hanja */
 		 return 21;
@@ -2332,11 +2339,6 @@
 		     /* Cyrillic Letter */
 		     return 30;
 	     }
-#ifdef WIN32
-     if (c1 >= 0x81 && (c1 <= 0xA0 || c2 <= 0xA0))
-  /* Extended Hangul Region : MS UHC(Unified Hangul Code) */
-  return 20;
-#endif
 	 }
 	 return 3;
      }

OOPS.. There is a BUG!!!
The behavior of gchar_cursor() is changed from 5.X to 6.0.
So, cls() does not work correctly for Japanese, TOO.

This is a newer patch. Pleas test and apply it.

--- search.c.orig Mon Jul 17 21:43:57 2000
+++ search.c Mon Jul 17 22:20:33 2000
@@ -2186,8 +2186,8 @@
      if (cc_dbcs && c > 0xFF)
      {
 	 /* process code leading/trailing bytes */
- unsigned char c1 = c & 0xff;
- unsigned char c2 = (unsigned)c >> 8;
+ unsigned char c1 = (unsigned)c >> 8;
+ unsigned char c2 = c & 0xff;

 	 if (cc_dbcs == (int)DBCS_JPN)
 	 {
@@ -2265,7 +2265,6 @@
 	 }
 	 else if (cc_dbcs == (int)DBCS_KOR)
 	 {
-     /* TODO: this code has been reported not to work correctly! */
 	     /*
 	      * If stype is non-zero, report these as class 1.
 	      */
@@ -2291,6 +2290,14 @@
 	     if (c1 >= 0xB0 && c1 <= 0xC8)
 		 /* Hangul */
 		 return 20;
+#ifdef WIN32
+     else if (c1 <= 0xA0 || c2 <= 0xA0)
+  /* Extended Hangul Region : MS UHC(Unified Hangul Code) */
+  /* c1: 0x81-0xA0 with c2: 0x41-0x5A, 0x61-0x7A, 0x81-0xFE
+ 	 * c1: 0xA1-0xC6 with c2: 0x41-0x5A, 0x61-0x7A, 0x81-0xA0
+ 	 */
+  return 20;
+#endif
 	     else if (c1 >= 0xCA && c1 <= 0xFD)
 		 /* Hanja */
 		 return 21;
@@ -2332,11 +2339,6 @@
 		     /* Cyrillic Letter */
 		     return 30;
 	     }
-#ifdef WIN32
-     if (c1 >= 0x81 && (c1 <= 0xA0 || c2 <= 0xA0))
-  /* Extended Hangul Region : MS UHC(Unified Hangul Code) */
-  return 20;
-#endif
 	 }
 	 return 3;
      }


--
Chong-Dae Park
--
Han Solo: That's 'cause droids don't pull people's arms out of their sockets
           when they lose. Wookiees are known to do that.
C-3PO:    I see your point, sir. I suggest a new strategy, R2! let the Wookiee
           win.
                                           - from "Star Wars: A New Hope"

Chong-Dae Park wrote:

> This is patch for vim-6.0b.
> The code included in vim-6.0b is a buggy one.
> (Sorry, Bram. That's my fault.)

Thanks, I'll include it.

I'm glad that you also found the problem of swapping c1 and c2.  There was a
mixup of using the leading byte as MSB or LSB in an int.  I now always use the
leading byte as MSB.  Perhaps there is still some place where it isn't.  Let
me know if you find one.

--
MESKIMEN'S LAW
     There's never time to do it right, but always time to do it over.

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Takuhiro Nishioka wrote:
>
> Sung-Hyun Nam wrote:
> > I just re-made the OnTheSpot patch against vim-6.0b.
> > It worked fine for me.
> > If you have any problem with the OnTheSpot patch, please test
> > with removing the 'GDK_IM_PREEDIT_CALLBACKS' in multibyte.c, line 1487(?).
> > Then gvim may run using OverTheSpot. Please reply your result.
> > I test it with gtk+-1.2.8.
>
> I tried this patch.  The OnTheSpot feature is great, I
> think.  But it doesn't work correctly on my Japanese
> environment.  While connecting to XIM, pressing CTRL key
> makes gvim hangs often.
> My environments:
>  OS: FreeBSD 4.0-STABLE
>  X: XFree86 4.0.1
>  GTK: gtk+-1.2.8
>  IM: kinput2 version 3
> 	 or
> 	 VJE-Delta 3.0 Trial

Because I have no problem, I cannot help.
X and gtk+ are almost same. My environments:

MiziOS-1.1 (similar to RedHat). glibc-2.1.2 based
XFree86 4.0.1 (CVS version), gtk+-1.2.8 (CVS version).
Ami-1.0.6

So, Bram, vim should have a option
(such as 'set xim_method=OverTheSpot,StatusArea')
to include this patch though the above problem could be fixed.

> And I'd like to suggest a feature: Coloring preediting
> texts.  So that we can easily distingish what we are
> writing from what we have written.

I hope also, but how can it be done in vim.
I think when we do 'add_to_input_buf()', we also should do
'these_char_has_underline_or_color_attribute()'
in preedit_draw_cbproc(). Can we do?

namsh

Sung-Hyun Nam wrote:

> So, Bram, vim should have a option
> (such as 'set xim_method=OverTheSpot,StatusArea')
> to include this patch though the above problem could be fixed.

The option should probably be used to disable input methods that don't work.
Something like:
	 :set ximdisable=OverTheSpot

Is this what we need?

I notice GTK takes the command line arguments (gui_gtk_x11.c):
     "--xim-preedit",
     "--xim-status",
Do these interfere somehow?

> > And I'd like to suggest a feature: Coloring preediting
> > texts.  So that we can easily distingish what we are
> > writing from what we have written.
>
> I hope also, but how can it be done in vim.
> I think when we do 'add_to_input_buf()', we also should do
> 'these_char_has_underline_or_color_attribute()'
> in preedit_draw_cbproc(). Can we do?

I'll leave this to someone who understans how XIM works...

--
TIM:   That is not an ordinary rabbit ... 'tis the most foul cruel and
        bad-tempered thing you ever set eyes on.
ROBIN: You tit.  I soiled my armour I was so scared!
                  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Hi,

Sung-Hyun Nam wrote:
> I just re-made the OnTheSpot patch against vim-6.0b.
> It worked fine for me.
> If you have any problem with the OnTheSpot patch, please test
> with removing the 'GDK_IM_PREEDIT_CALLBACKS' in multibyte.c, line 1487(?).
> Then gvim may run using OverTheSpot. Please reply your result.
> I test it with gtk+-1.2.8.

I tried this patch.  The OnTheSpot feature is great, I
think.  But it doesn't work correctly on my Japanese
environment.  While connecting to XIM, pressing CTRL key
makes gvim hangs often.

My environments:
	 OS: FreeBSD 4.0-STABLE
	 X: XFree86 4.0.1
	 GTK: gtk+-1.2.8
	 IM: kinput2 version 3
		 or
		 VJE-Delta 3.0 Trial

And I'd like to suggest a feature: Coloring preediting
texts.  So that we can easily distingish what we are
writing from what we have written.

I wish I could implement by myself, but it's beyond me...

Bram Moolenaar wrote:
>
> Sung-Hyun Nam wrote:
>
> > So, Bram, vim should have a option
> > (such as 'set xim_method=OverTheSpot,StatusArea')
> > to include this patch though the above problem could be fixed.
>
> The option should probably be used to disable input methods that don't work.
> Something like:
>  :set ximdisable=OverTheSpot
>
> Is this what we need?

No, I need also status handle, see below two options.

> I notice GTK takes the command line arguments (gui_gtk_x11.c):
>     "--xim-preedit",
>     "--xim-status",
> Do these interfere somehow?

Ah! I didn't notice vim support these options.
User can use those options to select best method. But he always
add that option (though he can use alias).
Hmm, currently OnTheSpot patch only has a problem for some people
and because gtk gui only support OnTheSpot, we can let user use those
command line options if he has a problem with OnTheSpot.

> > > And I'd like to suggest a feature: Coloring preediting
> > > texts.  So that we can easily distingish what we are
> > > writing from what we have written.
> >
> > I hope also, but how can it be done in vim.
> > I think when we do 'add_to_input_buf()', we also should do
> > 'these_char_has_underline_or_color_attribute()'
> > in preedit_draw_cbproc(). Can we do?
>
> I'll leave this to someone who understans how XIM works...

I believe we need someone who understands how VIM works.
XIM side is simple. Get a character from IM program and add those
characters to input buf. At that time, I also need give a attribute to
those characters (Mozilla has underline attr and I personally prefer
underline).

namsh

Hello,

This gtk gui OnTheSpot patch (made by Chi-Deok Hwang)
is fixed the 'hang' problem (The 1st patch had).

Bram, I hope you include this patch in next vim60.

regards,

namsh

diff -u -u -r1.2 gui_gtk_x11.c
--- ./src/gui_gtk_x11.c 2000/07/17 00:34:31 1.2
+++ ./src/gui_gtk_x11.c 2000/07/18 12:42:52
@@ -566,6 +566,14 @@
      state = event->state;
      g_assert(len <= sizeof(string));

+#ifdef FEAT_XIM
+    {
+ extern int xim_queue_key_press_event(GdkEvent *ev);
+ if (xim_queue_key_press_event((GdkEvent *) event))
+     return TRUE;
+    }
+#endif
+
  #ifdef FEAT_HANGULIN
      if (event->keyval == GDK_space && (state & GDK_SHIFT_MASK))
      {
@@ -1108,6 +1116,14 @@
       */
      if (event->type != GDK_BUTTON_PRESS)
 	 return FALSE;
+
+#ifdef FEAT_XIM
+    {
+ extern void xim_reset(void);
+
+ xim_reset();
+    }
+#endif

      x = event->x;
      y = event->y;
diff -u -u -r1.2 multibyte.c
--- ./src/multibyte.c 2000/07/17 00:34:32 1.2
+++ ./src/multibyte.c 2000/07/19 05:07:08
@@ -1484,6 +1484,8 @@
      GdkIMStyle supported_style = GDK_IM_PREEDIT_NONE |
 				  GDK_IM_PREEDIT_NOTHING |
 				  GDK_IM_PREEDIT_POSITION |
+ 			 GDK_IM_PREEDIT_CALLBACKS |
+ 			 /* GDK_IM_STATUS_CALLBACKS | */
 				  GDK_IM_STATUS_AREA |
 				  GDK_IM_STATUS_NONE |
 				  GDK_IM_STATUS_NOTHING;
@@ -1511,8 +1513,149 @@
      }
  }

+#include <gdk/gdkx.h>
+
+    static void
+preedit_start_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    static void
+xim_back_delete(int n)
+{
+    char str[3];
+
+    str[0] = CSI;
+    str[1] = 'k';
+    str[2] = 'b';
+    while (n-- > 0)
+ add_to_input_buf(str, 3);
+}
+
+static GSList *key_press_event_queue = NULL;
+static int preedit_buf_len = 0;
+static gboolean processing_queued_event = FALSE;
+
+    static void
+preedit_draw_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+    XIMPreeditDrawCallbackStruct *draw_data;
+    XIMText *text;
+    GdkWChar *wstr = NULL;
+    char *src;
+    GSList *event_queue;
+
+    draw_data = (XIMPreeditDrawCallbackStruct *) call_data;
+    text = (XIMText *) draw_data->text;
+
+    if (draw_data->chg_length > 0)
+    {
+ xim_back_delete(draw_data->chg_length);
+ preedit_buf_len -= draw_data->chg_length;
+    }
+    if (text && (src = text->string.multi_byte))
+    {
+ int len = strlen(src);
+
+ wstr = g_new(GdkWChar, len);
+ preedit_buf_len += gdk_mbstowcs(wstr, src, len);
+ g_free(wstr);
+ add_to_input_buf(src, len);
+    }
+    event_queue = key_press_event_queue;
+    processing_queued_event = TRUE;
+    while (event_queue)
+    {
+ GdkEvent *ev = event_queue->data;
+ gboolean *ret;
+ gtk_signal_emit_by_name((GtkObject*)gui.mainwin, "key_press_event",
+ 		 ev, &ret);
+ gdk_event_free(ev);
+ event_queue = event_queue->next;
+    }
+    processing_queued_event = FALSE;
+    if (key_press_event_queue)
+    {
+ g_slist_free(key_press_event_queue);
+ key_press_event_queue = NULL;
+    }
+    if (gtk_main_level() > 0)
+ gtk_main_quit();
+}
+
+    static void
+preedit_caret_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    static void
+preedit_done_cbproc(XIC xic, XPointer client_data, XPointer call_data)
+{
+}
+
+    void
+xim_reset(void)
+{
+    char * text;
+
+    if (xic)
+    {
+ text = XmbResetIC(((GdkICPrivate *)xic)->xic);
+ if (!(xim_input_style & GDK_IM_PREEDIT_CALLBACKS))
+     add_to_input_buf(text, strlen(text));
+ else
+     preedit_buf_len = 0;
+ if (text)
+     XFree(text);
+    }
+}
+
+    int
+xim_queue_key_press_event(GdkEvent *ev)
+{
+    if (preedit_buf_len <= 0 || processing_queued_event)
+ return FALSE;
+
+    key_press_event_queue = g_slist_append(key_press_event_queue,
+                                           gdk_event_copy(ev));
+    return TRUE;
+}
+
+    static void
+preedit_callback_setup(GdkIC *ic)
+{
+    XIC xxic;
+    XVaNestedList preedit_attr;
+    XIMCallback preedit_start_cb;
+    XIMCallback preedit_draw_cb;
+    XIMCallback preedit_caret_cb;
+    XIMCallback preedit_done_cb;
+
+    xxic = ((GdkICPrivate*)xic)->xic;
+    preedit_start_cb.callback = (XIMProc)preedit_start_cbproc;
+    preedit_draw_cb.callback = (XIMProc)preedit_draw_cbproc;
+    preedit_caret_cb.callback = (XIMProc)preedit_caret_cbproc;
+    preedit_done_cb.callback = (XIMProc)preedit_done_cbproc;
+    preedit_attr
+ = XVaCreateNestedList (0,
+ 		       XNPreeditStartCallback, &preedit_start_cb,
+ 		       XNPreeditDrawCallback, &preedit_draw_cb,
+ 		       XNPreeditCaretCallback, &preedit_caret_cb,
+ 		       XNPreeditDoneCallback, &preedit_done_cb,
+ 		       0);
+    XSetICValues (xxic, XNPreeditAttributes, preedit_attr, 0);
+    XFree(preedit_attr);
+}
+
+    static void
+reset_state_setup(GdkIC *ic)
+{
+    /* don't change the input context when we call reset */
+    XSetICValues(((GdkICPrivate*)ic)->xic, XNResetState, XIMPreserveState, 0);
+}
+
      void
-xim_init()
+xim_init(void)
  {
      xic = NULL;
      xic_attr = NULL;
@@ -1584,6 +1727,11 @@
 		 attr->status_fontset = gui.fontset;
 	     }
 	 }
+ else if ((xim_input_style & GDK_IM_STATUS_MASK)
+ 	 == GDK_IM_STATUS_CALLBACKS)
+ {
+     /* FIXME */
+  }
  #endif

 	 xic = gdk_ic_new(attr, attrmask);
@@ -1595,6 +1743,9 @@
 	     mask = gdk_window_get_events(widget->window);
 	     mask |= gdk_ic_get_events(xic);
 	     gdk_window_set_events(widget->window, mask);
+     if (xim_input_style & GDK_IM_PREEDIT_CALLBACKS)
+  preedit_callback_setup(xic);
+     reset_state_setup(xic);
 	 }
      }
  }

Sung-Hyun -

> This gtk gui OnTheSpot patch (made by Chi-Deok Hwang)
> is fixed the 'hang' problem (The 1st patch had).
>
> Bram, I hope you include this patch in next vim60.

I will include this.  I trust you (and others) will fix any problems that are
encountered.

--
Females are strictly forbidden to appear unshaven in public.
		 [real standing law in New Mexico, United States of America]

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Hello,

I doubt it occurs only to me. guifontset does not work.
gvim runs with default font (-adobe-*).
Don't know my patch is correct, but seems work to me.

regards,

namsh

diff -u -u -r1.4 gui.c
--- ./gui.c 2000/08/04 03:23:36 1.4
+++ ./gui.c 2000/08/04 04:52:29
@@ -389,6 +389,10 @@
       */
      if (font_argument != NULL)
 	 set_option_value((char_u *)"gfn", 0L, (char_u *)font_argument, FALSE);
+#ifdef FEAT_XFONTSET
+    if (*p_guifontset == NUL
+ || gui_init_font(p_guifontset, TRUE) == FAIL)
+#endif
      if (gui_init_font(p_guifont, FALSE) == FAIL)
 	 goto error2;
  #ifdef FEAT_MBYTE


Another infos are:
:r!uname
Linux

:ver
VIM - Vi IMproved 6.0d ALPHA (2000 Jul 30, compiled Aug  4 2000 13:53:24)
Compiled by namsh@...
Normal version with GTK GUI.  Features included (+) or not (-):
+autocmd -balloon_eval +browse +builtin_terms +byte_offset +cindent
+cmdline_compl +cmdline_info +comments +cryptv -cscope +dialog_con_gui
+digraphs -ebcdic -emacs_tags +eval +ex_extra +extra_search -farsi
+file_in_path -osfiletype +find_in_path -footer +fork() +gettext -hangul_input
+insert_expand -langmap +libcall -line_highlight +linebreak +lispindent
+localmap +menu +mksession +modify_fname +mouse +mouseshape -mouse_dec
-mouse_gpm -mouse_jsbterm -mouse_netterm +mouse_xterm +multi_byte +multi_lang
+path_extra -perl -python +quickfix -rightleft +scrollbind -signs +smartindent
-sniff +statusline -sun_workshop +syntax +tag_binary +tag_old_static
-tag_any_white -tcl +terminfo +textobjects +title +toolbar +user_commands
+vertsplit +virtualedit +visual +visualextra +viminfo +wildignore +wildmenu
+windows +writebackup +X11 +xfontset +xim +xterm_clipboard -xterm_save
    system vimrc file: "$VIM/vimrc"
      user vimrc file: "$HOME/.vimrc"
       user exrc file: "$HOME/.exrc"
   system gvimrc file: "$VIM/gvimrc"
     user gvimrc file: "$HOME/.gvimrc"
     system menu file: "$VIMRUNTIME/menu.vim"
   fall-back for $VIM: "/usr/local/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H  -DFEAT_GUI_GTK  -I/usr/lib/glib
/include -I/usr/X11R6/include  -O2 -pipe  -Wall -I/usr/X11R6/include
Linking: gcc  -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
  -ldl -lXext -L/usr/X11R6/lib  -o vim    -lXt -lncurses -ldl

Sung-Hyun Nam wrote:

> I doubt it occurs only to me. guifontset does not work.
> gvim runs with default font (-adobe-*).
> Don't know my patch is correct, but seems work to me.

That looks like a good solution.  Fontset must be used when it's set.  I'll
include this.

--
hundred-and-one symptoms of being an internet addict:
102. When filling out your driver's license application, you give
      your IP address.

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Hello,

Sung-Hyun Nam wrote:
> I doubt it occurs only to me. guifontset does not work.
> gvim runs with default font (-adobe-*).

I had the same problem too.  It works well thanks!

--
Takuhiro Nishioka mailto:takuhiro@...

I am using 6.0e
I have absolutely no problem with my unicode (utf8) files as far as
display goes, but
I can't understand how to input. Concretely what I want to do is to
switch in the middle of a document. Say I start a sentence in English,
then insert a quote in Greek, then switch to French, etc.
I'm sure the answer is simple, but I have not been able to find it
anywhere in the doc.


François

François Thunus wrote:

> I am using 6.0e
> I have absolutely no problem with my unicode (utf8) files as far as display
> goes, but I can't understand how to input. Concretely what I want to do is
> to switch in the middle of a document. Say I start a sentence in English,
> then insert a quote in Greek, then switch to French, etc.  I'm sure the
> answer is simple, but I have not been able to find it anywhere in the doc.
> I'm not even sure this question belongs here, but since multicode
> support is new to 6.0, there was little point asking in the regular vim
> mailing list.
> sorry for the inconvenience.

This question certainly does belong in vim-multibyte.  I'll copy this to
vim-dev too, perhaps a few people there are also interested in subscribing to
the vim-multibyte list (it's low volume).

You probably need to use the XIM (X imput method) for this.  On Windows there
is IME, which is similar but different.

The text at ":help multibyte-input" should be helpful.  If that is unclear or
incomplete, I hope someone can improve it.  I don't know enough about this
myself.

An alternative is to use digraphs.  I'm thinking of including the RFC1345
standard for digraphs.  Also including the mnemonics from this table could be
useful (similar to digraphs but use more than two characters).

--
hundred-and-one symptoms of being an internet addict:
200. You really believe in the concept of a "paperless" office.

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Bram Moolenaar wrote:

> > goes, but I can't understand how to input. Concretely what I want to do is
> > to switch in the middle of a document. Say I start a sentence in English,

> You probably need to use the XIM (X imput method) for this.  On Windows there
> is IME, which is similar but different.
I work under linux. The doc already states that I need to use XIM.
Now my question is: what is XIM ? how do I use it ? and alternately,
where do I find the doc about it ? I tried man XIM, man xim, the XF86
website, the X website
and nowhere did I find a clue as to what I need to do.

> The text at ":help multibyte-input" should be helpful.  If that is unclear or
> incomplete, I hope someone can improve it.  I don't know enough about this
> myself.
I have read that, and multibyte.txt too. I still do not have the
slightest idea how to input a greek char in the middle of another text.

> An alternative is to use digraphs.  I'm thinking of including the RFC1345
> standard for digraphs.  Also including the mnemonics from this table could be
> useful (similar to digraphs but use more than two characters).
the digraph method is just not practical for real typing. (that is,
assuming that I redefine all the letters I need). What I am looking for
is something like <esc>:greek
and lo! I can type in greek. Just like I do in Yudit: I select Greek in
the input menu, and I can start typing. the keyboard is remapped to the
closest greek equivalent, ie I get a lambda when pressing l, a phi when
pressing f, an alpha for a, etc. simple and fast. If I need to go back
to something else, I just click on input again and select the language.
for languages like polish, the a with a comma below is generated by a;,
the dashed l by a l', etc. simple enough to remember quickly.
What I am looking for is how to do the same in vim, if that is possible
at all.
I need to be able to change language in the middle of a text.

I hope my question is a bit clearer now ?

Cheers

François

François Thunus wrote:

> > > goes, but I can't understand how to input. Concretely what I want to do
> > > is to switch in the middle of a document. Say I start a sentence in
> > > English,
>
> > You probably need to use the XIM (X imput method) for this.  On Windows
> > there is IME, which is similar but different.
> I work under linux. The doc already states that I need to use XIM.
> Now my question is: what is XIM ? how do I use it ? and alternately,
> where do I find the doc about it ? I tried man XIM, man xim, the XF86
> website, the X website and nowhere did I find a clue as to what I need to
> do.

In Vim:

	 :help xim

It's indeed disappointing to see that documentation about X is hard to find.
I have a CD for Mootif that contains a lot of docs, but you have to pay for
it...

> > The text at ":help multibyte-input" should be helpful.  If that is unclear
> > or incomplete, I hope someone can improve it.  I don't know enough about
> > this myself.
> I have read that, and multibyte.txt too. I still do not have the
> slightest idea how to input a greek char in the middle of another text.

Hmm, hopefully somebody can help here, if XIM doesn't do it I have no other
idea.

> > An alternative is to use digraphs.  I'm thinking of including the RFC1345
> > standard for digraphs.  Also including the mnemonics from this table could
> > be useful (similar to digraphs but use more than two characters).
> the digraph method is just not practical for real typing. (that is,
> assuming that I redefine all the letters I need). What I am looking for
> is something like <esc>:greek
> and lo! I can type in greek. Just like I do in Yudit: I select Greek in
> the input menu, and I can start typing. the keyboard is remapped to the
> closest greek equivalent, ie I get a lambda when pressing l, a phi when
> pressing f, an alpha for a, etc. simple and fast. If I need to go back
> to something else, I just click on input again and select the language.
> for languages like polish, the a with a comma below is generated by a;,
> the dashed l by a l', etc. simple enough to remember quickly.
> What I am looking for is how to do the same in vim, if that is possible
> at all.
> I need to be able to change language in the middle of a text.

Yes, I understand that.  Until now Vim didn't include the translation from
ASCII (or whatever your keyboard produces) to special languages.  I was hoping
that a system function could be used for this.  See the message from/to Ron
Aaron about an alternative.

--
hundred-and-one symptoms of being an internet addict:
206. You religiously respond immediately to e-mail, while ignoring
      your growing pile of snail mail.

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Ron Aaron wrote:

> I'm not familiar with XIM, but the IME on Windows is for Multibyte input
> scripts, e.g. Japanese, Korean, Chinese etc.
>
> Francois' problem is a little different.  He wants vim to interpret his
> keyboard input as now English, now Greek, now French.  In other words, he
> wants to switch his input encoding on the fly.  XIM might do this
> generically, but the Windows IME only does this for Far East languages.

Hmm, I thought that Windows does support Unicode.  At least on NT/2000.  Isn't
there a way to enter Unicode characters, e.g. in Hebrew?

> Moreover, one needs to install 'support' for these languages in Windows in
> order to remap the keyboard at Windows' level.  If you don't have the Windows
> install CD when you decide to e.g. input Spanish, you have to fake it.

I think that Vim has to go two ways:

1. Use the standard way to enter special characters on the system.  This is
    what other programs on the same system use.  And we don't have to build
    much of this into Vim.

2. Add a good way in Vim to enter special characters, which works on any
    system.  This makes it possible to enter the characters in the same way, no
    matter where you are using Vim.

Making a compromise out of these two appears to be impossible.

For both ways there is already some support.  But now that Vim has UTF-8
support, and the multi-byte features are improved, we probably also need to
improve both ways.  Since I don't know much about this stuff, I prefer to
leave this to someone who knows what he's doing.

> that's already in vim (langmap).  However, as far as I can tell, 'langmap'
> doesn't do what the documentation says.  Specifically, it doesn't remap
> INSERT mode at all, only NORMAL mode (5.7 and  6.0e on Linux, 6.0e on
> Win32).

Right, the idea of 'langmap' is that your keyboard is producing characters in
your special language, thus in Insert mode nothing needs to be done.  But in
command mode you need to type keys like "x", which requires translation of
your special language to ASCII.

> This way, one might have a 'language' menu or command that would switch vim
> from English to e.g. Greek input mode.  Similarly, we might define an entire
> set of 'languages' based on the standard keyboards for these.
>
> The problem is vim has to know that an 'alpha' is Unicode 0x03b1  but an 'a'
> is Unicode 0x0061, and an 'alef' is Unicode 0x05d0.  We should be independant
> of the 'input method' used on the OS (for example, on DOS how does one enter
> greek on a us keyboard?).  Therefore, a remapping table is in order, to be
> loaded for each language ("keyboard").  It should specify a translation from a
> raw key ('a') to a translated key ('€') for a particular encoding.
>
> For example, a keymap for iso-8859-8/utf-8 might be something like:
>  a,0xf9,0x5e9  " a on the keyboard maps to the 'shin' character
>  b,0xf0,0x5e0  " b --> 'nun'
>  ...etc...
>
> Similarly for all the encodings.  This means that when the user wants to (in
> this case) enter Hebrew, he would tell vim to use a Hebrew mapping, which
> would enter the characters as above (in utf-8, the wide characters would be
> used, in single-byte mode, the -8 encoding would be used).

This sounds reasonable.  The question is how to handle the situation where
there are more characters needed than you have keys on your keyboard.  Perhaps
digraphs need to be used then?  As I said, I was thinking of adding a whole
list of standard digraphs (and mnemonics).

One problem is the handling of dead keys.  Would we also want to support that?
It's important for languages with accented characters.

> This 'alternate' keyboard would be switched with the 'standard', English
> keyboard via ^_ (or a user mapped key) just like it currently is for Hebrew.
> In this manner, one can switch quickly between English and an alternate
> language.  The keyboard mapping should be able to be swtiched in on the
> command-line as well, so searching for arbitrary text is facilitated  (like
> the current Hebrew support).

Setting an option to the translation table to be used sounds reasonable.
Will this replace the existing 'hkmap' and 'fkmap' options?

More comments?

--
Spam seems to be something useful to novices.  Later you realize that
it's a bunch of indigestable junk that only clogs your system.
Applies to both the food and the e-mail!

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///

Ron Aaron wrote:
> Francois' problem is a little different.  He wants vim to interpret his
> keyboard input as now English, now Greek, now French.  In other words, he
> wants to switch his input encoding on the fly.  XIM might do this generically,
> but the Windows IME only does this for Far East languages.

YES :-)

> Moreover, one needs to install 'support' for these languages in Windows in
> order to remap the keyboard at Windows' level.  If you don't have the Windows
> install CD when you decide to e.g. input Spanish, you have to fake it.

I work under Linux (stock RH 6.2 with some modifications for unicode, ie
gazillions of fonts, patched xterm, etc).

> In my opinion, a much better solution is to use the inherent key remapping
> that's already in vim (langmap).  However, as far as I can tell, 'langmap'
> doesn't do what the documentation says.  Specifically, it doesn't remap INSERT
> mode at all, only NORMAL mode (5.7 and  6.0e on Linux, 6.0e on Win32).
>
> This way, one might have a 'language' menu or command that would switch vim
> from English to e.g. Greek input mode.  Similarly, we might define an entire
> set of 'languages' based on the standard keyboards for these.

that would be brilliant.

> The problem is vim has to know that an 'alpha' is Unicode 0x03b1  but an 'a'
> is Unicode 0x0061, and an 'alef' is Unicode 0x05d0.  We should be independant
> of the 'input method' used on the OS (for example, on DOS how does one enter
> greek on a us keyboard?).  Therefore, a remapping table is in order, to be
> loaded for each language ("keyboard").  It should specify a translation from a
> raw key ('a') to a translated key ('?') for a particular encoding.
>
> For example, a keymap for iso-8859-8/utf-8 might be something like:
>         a,0xf9,0x5e9            " a on the keyboard maps to the 'shin'
character
>         b,0xf0,0x5e0            " b --> 'nun'
>         ...etc...
>
> Similarly for all the encodings.  This means that when the user wants to (in
> this case) enter Hebrew, he would tell vim to use a Hebrew mapping, which
> would enter the characters as above (in utf-8, the wide characters would be
> used, in single-byte mode, the -8 encoding would be used).
>
> This gives an easy way to accomodate all systems, and encodings which are not
> well supported.  The 'rightleft' issues are a separate thing, and are already
> adequately supported in vim I think.

I was not even dreaming of getting that too, but if it is possible to
reverse the direction for Hebrew and Arabic (which rae the only two I am
interested in at the moment), that is even better than I thought.

> This 'alternate' keyboard would be switched with the 'standard', English
> keyboard via ^_ (or a user mapped key) just like it currently is for Hebrew.
> In this manner, one can switch quickly between English and an alternate
> language.  The keyboard mapping should be able to be swtiched in on the
> command-line as well, so searching for arbitrary text is facilitated  (like
> the current Hebrew support).
> Sorry for rambling, but I think it is important to make this work
> independantly of OS support, since it is possible, and will make vim more
> useful to more people.

definitely. This is exactly what I need/want, I am very glad to see that
other people have given it a thought as well. I will see what I can do
with this keyboard mapping option you mention. maybe that is the
beginning of a solution for languages which are not very far from plain
ascii (I'm thinking mostly polish, french, etc). I was not even aware
that Hebrew was already supported by vim. I have been using unix for a
long time, and Linux since 1.2.4, but since I was switching constantly
between Linux, System Vr4 and Solaris, I limited myself to core vi
functions, and did not really care about what vi I was using, since they
were pretty much all the same to me. But now I'll be using Linux only
and I need unicode support, which is why I jumped on vim. Knowing that
there is also a win32 version is of utmost interest because some people
in the company do use windows as well, so if we can standardiuze on vim,
that would be nice.

Thanaks for the help.

Cheers

François

Bram Moolenaar wrote:

> 2. Add a good way in Vim to enter special characters, which works on any
>    system.  This makes it possible to enter the characters in the same way, no
>    matter where you are using Vim.

This seems to be the way to go.

> Right, the idea of 'langmap' is that your keyboard is producing characters in
> your special language, thus in Insert mode nothing needs to be done.  But in
> command mode you need to type keys like "x", which requires translation of
> your special language to ASCII.

make sense
>
> > This way, one might have a 'language' menu or command that would switch vim
> > from English to e.g. Greek input mode.  Similarly, we might define an entire
> > set of 'languages' based on the standard keyboards for these.
>
> This sounds reasonable.  The question is how to handle the situation where
> there are more characters needed than you have keys on your keyboard.  Perhaps
I am not sure this does matter, in the sense that as long as the user
can produce his own keymap, (s)he'll just put on it the characters (s)he
uses most, and figure out some way to enter the rest.
> digraphs need to be used then?
for example, yes.

>  As I said, I was thinking of adding a whole list of standard digraphs (and
mnemonics).
I am  not sure this is needed, but why not.

> One problem is the handling of dead keys.  Would we also want to support that?
> It's important for languages with accented characters.
you bet

> > This 'alternate' keyboard would be switched with the 'standard', English
> > keyboard via ^_ (or a user mapped key) just like it currently is for Hebrew.
> > In this manner, one can switch quickly between English and an alternate
> > language.  The keyboard mapping should be able to be swtiched in on the
> > command-line as well, so searching for arbitrary text is facilitated  (like
> > the current Hebrew support).
>
> Setting an option to the translation table to be used sounds reasonable.
> Will this replace the existing 'hkmap' and 'fkmap' options?

I am not sure how those two work, I need to examine this closer.

> More comments?

I am obviously more than ready to help if I can, now that my problem
seems to be understood :-)

Cheers

François

Ron Aaron wrote:


> One question -- I can see where I might have an English document and a Hebrew
> document.  It would be nice I think if the keyboard were mapped on a
> per-buffer basis.  Thoughts?

user-definable ? :-) set keymapperbuf=0 or set keymapperbuf=true

Cheers

François

Bram Moolenaar wrote:

> > Now my question is: what is XIM ? how do I use it ? and alternately,
> > where do I find the doc about it ? I tried man XIM, man xim, the XF86
> > website, the X website and nowhere did I find a clue as to what I need to
> > do.
>
> In Vim:
>
>         :help xim
I have done that. It does tell me that I can switch to an alternate
kanji input method, but not where to find the doc to configure the one X
is using to allow me to introduce greek char in the middle of an english
text. similarly, man xim or XIM does not exist, and man X does not point
to anything useful. Mind you, I am not bashing, just stating that the
existing information does not allow me to do anything concrete. The
moment I find out what to do, I'm more than willing to write a patch for
the doc and send it to you.

> > I need to be able to change language in the middle of a text.

> Yes, I understand that.  Until now Vim didn't include the translation from
> ASCII (or whatever your keyboard produces) to special languages.  I was hoping
> that a system function could be used for this.  See the message from/to Ron
> Aaron about an alternative.

Yes, Aaron's suggestion is exactly what I am looking for. Obviously, we
have the same preoccupations :-)

Let me know if there is anything I can do to help. While I may not be
able to code much, I can certainly test and check/write docs

Cheers

François

Ron Aaron wrote:
>
> OK, then I'll add an option 'keymap' which is a generic version of 'hkmap'
> et.al.  You would then do something like:
>         set keymap=greek
> and the 'greek.map' would be loaded as an alternative to English.  I would
> probably keep up to three keymaps loaded just to make things faster if memory
> were available.  Pressing the hotkey would toggle between greek and english
> keymaps.  Settting it to empty would unload all alternate keymaps.

I have recompiled vim 6.0e with both multibyte and hebrew support (this
should be default imo, by the way). when I launch vi -H Hebrew.utf8, I
get my test file displayed correctly (good fonts) and from right to
left. when I input, it does work from r2l as well. However, the chars
are not in Hebrew. I guess this is because it is not encoded in utf8.

I have looked at the hkmap to modify it and make it remap to utf8
instead, but I must confess I did not exactly understand how to do that
from the edit.c file. I am willing to code the greek, hebrew and arabic
maps, but maybe i'd better wait until the new map support is implemented
as an external file.

Just let me know what to do when the new release with external file
loading support comes out. bram should have the menues in french, and
I'll be coding the other messages in French as well (just it will take
longer since the file is 20 bigger).

Cheers

François

=?Iso-8859-1?Q?Fran=E7ois?= Thunus <thunus@...> writes:
>
>I have recompiled vim 6.0e with both multibyte and hebrew support (this
>should be default imo, by the way). when I launch vi -H Hebrew.utf8, I
>get my test file displayed correctly (good fonts) and from right to
>left. when I input, it does work from r2l as well. However, the chars
>are not in Hebrew. I guess this is because it is not encoded in utf8.

Francois, look at 'rightleft.txt', it will help you get where you want to go.

Essentially, you can edit iso-8859-8 text but not UTF-8 because vim doesn't
know how to enter the correct codes in UTF-8.  This shouldn't be a big
problem, as you can convert -8 to utf-8 with e.g. 'recode':

	 recode hebrew..utf-8 myfile.txt

Otherwise, you can manually remap the keyboard:

	 imap a  ^V128 (or whatever...)

I have a mapping:

	 map <F6> :set rl! hkmap!<cr>

which toggles between English and Hebrew modes.  You also want 'allowrevins'
turned on, and you need the font to display 8859-8, and you can then edit
iso-8859-8 (or Windows CP1255) text easily (and convert to utf-8 if you need
to, later).

I'll add the keymapping support, but it will not make it into the next
release, sorry!

>
>I have looked at the hkmap to modify it and make it remap to utf8
>instead, but I must confess I did not exactly understand how to do that
>from the edit.c file. I am willing to code the greek, hebrew and arabic
>maps, but maybe i'd better wait until the new map support is implemented
>as an external file.

There is no need to do that, as the new support will supercede the hkmap
stuff.  It will hook into the same part of the code, though.

>
>Just let me know what to do when the new release with external file
>loading support comes out. bram should have the menues in french, and
>I'll be coding the other messages in French as well (just it will take
>longer since the file is 20 bigger).

Let's see how I implement it, then you can write all the menus you like!


Best regards,

Ron

Hi, Bram and All.

This is small fix for mbyte-input.
If typing mbyte on command mode, Vim will crash.

---------------------------------------------------------
*** src.org/charset.c Mon Aug 07 03:11:43 2000
--- src/charset.c Tue Aug 22 14:10:30 2000
***************
*** 354,360 ****
--- 354,364 ----
   #ifdef FEAT_FKMAP
  			 || F_ischar(c)
   #endif
+ #ifdef FEAT_MBYTE
+ 	 )) || (c < 255 && chartab[c] & CHAR_IP))    /* printable character */
+ #else
  		 )) || (chartab[c] & CHAR_IP))     /* printable character */
+ #endif
       {
  	 buf[i] = c;
  	 buf[i + 1] = NUL;
---------------------------------------------------------

Yasuhiro Matsumoto

Hi,

If the width of the font for multi-byte characters is not twice
as much as the width of the font for single-byte characters, the
window gets broken on the cursor move.

I made a quick-hack patch for gui_gtk_x11.c (version 6.0h).
I think It's not complete but useful.

Shugo

--- gui_gtk_x11.c.orig Fri Sep 22 02:44:42 2000
+++ gui_gtk_x11.c Fri Sep 22 14:08:23 2000
@@ -2649,6 +2649,30 @@
      gui.bgcolor->pixel = (Pixel) color;
  }

+#ifdef FEAT_MBYTE
+    void
+draw_mb_text(GdkDrawable *drawable,
+      GdkFont *font,
+      GdkGC *gc,
+      gint x,
+      gint y,
+      char_u *text,
+      int textlen)
+{
+    int len;
+
+    while (textlen > 0)
+    {
+ len = mb_ptr2len_check(text);
+ gdk_draw_text(drawable, font, gc,
+ 	      x, y, (const gchar *) text, len);
+ x += (len * gui.char_width);
+ text += len;
+ textlen -= len;
+    }
+}
+#endif
+
      void
  gui_mch_draw_string(int row, int col, char_u *s, int len, int flags)
  {
@@ -2728,18 +2752,32 @@
      if (flags & DRAW_TRANSP)
      {
 	 gdk_gc_set_foreground(gui.text_gc, gui.fgcolor);
- gdk_draw_text(gui.drawarea->window,
- 	      gui.current_font,
- 	      gui.text_gc,
- 	      TEXT_X(col), TEXT_Y(row),
- 	      (const gchar *)text, textlen);
+#ifdef FEAT_MBYTE
+ if (cc_dbcs && !is_wide)
+     draw_mb_text(gui.drawarea->window,
+ 		 gui.current_font,
+ 		 gui.text_gc,
+ 		 TEXT_X(col), TEXT_Y(row),
+ 		 (char_u *)text, textlen);
+ else
+#endif
+     gdk_draw_text(gui.drawarea->window,
+ 		  gui.current_font,
+ 		  gui.text_gc,
+ 		  TEXT_X(col), TEXT_Y(row),
+ 		  (const gchar *)text, textlen);
      }
      else
      {
 	 int width;
 	 int height;

- width = gdk_text_width(gui.current_font, (const gchar *)text, textlen);
+#ifdef FEAT_MBYTE
+ if (cc_dbcs && !is_wide)
+     width = textlen * gui.char_width;
+ else
+#endif
+     width = gdk_text_width(gui.current_font, (const gchar *)text, textlen);
 	 height = gui.char_height;

 	 gdk_gc_set_foreground(gui.text_gc, gui.bgcolor);
@@ -2748,21 +2786,39 @@
 			    TRUE,
 			    FILL_X(col), FILL_Y(row), width, height);
 	 gdk_gc_set_foreground(gui.text_gc, gui.fgcolor);
- gdk_draw_text(gui.drawarea->window,
- 	      gui.current_font,
- 	      gui.text_gc,
- 	      TEXT_X(col), TEXT_Y(row),
- 	      (const gchar *)text, textlen);
+#ifdef FEAT_MBYTE
+ if (cc_dbcs && !is_wide)
+     draw_mb_text(gui.drawarea->window,
+ 		 gui.current_font,
+ 		 gui.text_gc,
+ 		 TEXT_X(col), TEXT_Y(row),
+ 		 (char_u *)text, textlen);
+ else
+#endif
+     gdk_draw_text(gui.drawarea->window,
+ 		  gui.current_font,
+ 		  gui.text_gc,
+ 		  TEXT_X(col), TEXT_Y(row),
+ 		  (const gchar *)text, textlen);
      }

      /* redraw the contents with an offset of 1 to emulate bold */
      if (flags & DRAW_BOLD)
      {
- gdk_draw_text(gui.drawarea->window,
- 	      gui.current_font,
- 	      gui.text_gc,
- 	      TEXT_X(col) + 1, TEXT_Y(row),
- 	      (const gchar *)text, textlen);
+#ifdef FEAT_MBYTE
+ if (cc_dbcs && !is_wide)
+     draw_mb_text(gui.drawarea->window,
+ 		 gui.current_font,
+ 		 gui.text_gc,
+ 		 TEXT_X(col) + 1, TEXT_Y(row),
+ 		 (char_u *)text, textlen);
+ else
+#endif
+     gdk_draw_text(gui.drawarea->window,
+ 		  gui.current_font,
+ 		  gui.text_gc,
+ 		  TEXT_X(col) + 1, TEXT_Y(row),
+ 		  (const gchar *)text, textlen);
      }

      if (flags & DRAW_UNDERL)

Shugo Maeda wrote:

> If the width of the font for multi-byte characters is not twice
> as much as the width of the font for single-byte characters, the
> window gets broken on the cursor move.

Well, the proper fix is to get a font that's really double-width.

> I made a quick-hack patch for gui_gtk_x11.c (version 6.0h).
> I think It's not complete but useful.

This looks like a patch that goes into the direction of supporting
proportional fonts.  It draws each character separately.  However, I suspect
the background isn't always redrawn correctly.  Also, the same should be done
for other GUI verions.  I rather wait for a better patch.

--
hundred-and-one symptoms of being an internet addict:
87. Everyone you know asks why your phone line is always busy ...and
     you tell them to send an e-mail.

///  Bram Moolenaar     Bram@...     http://www.moolenaar.net  \\\
\\\  Vim: http://www.vim.org      ICCF Holland: http://iccf-holland.org  ///