Re: PATCH: (large) initial support for combining characters in ZLE.

[Peter Stephenson <pws@csr.com>]

Bart Schaefer wrote:
> On Apr 13,  5:54pm, Peter Stephenson wrote:
> } To get combining characters to do anything useful, you will need to
> } set the option COMBINING_CHARS. There's no "ZLE" there because it
> } already has a minimal effect on the main shell in the [[:WORD:]]
> } test: arguably zero-width punctuation characters should be considered
> } part of the word regardless of the option, i.e. even if displayed
> } specially, and I might change this.
> 
> Pardon if I'm just not thinking this through far enough, but what if
> any affect does this have on completion of strings that contain zero-
> width characters?
> 
> Mainly I'm wondering whether NO_combiningchars needs to be added to
> _comp_options, or something of that ilk.

It shouldn't have a major effect.  The completion system inserts
multibyte strings that get converted to wide characters later on; when
this is redisplayed it goes into the same logic in zrefresh() that is
already basically working.

The only issue I can see is if the cursor ends up on a combining
character at that point; for example, when completing characters that
only differ by the subsequent combining characters.  Actually, I can't
think of a case where that can happen.  Either we insert the unique part
to the left of the cursor, or we insert one of the choices completely.
As long as we don't put anything under the cursor, things will work.
There's the slightly odd effect that characters differing by combining
characters will appear treated as if the base character matches:  that's
a bug, but no worse than the current situation.

Hence the only effects I'm expecting are minor edge effects which can
probably be fixed up with a suitably placed alignmultiwordright().
I wonder, in fact, if it might be worth putting that in
unmetafy_line(), as below...

In any case I'd like to keep the option turned on and see what happens,
since I'm not expecting anything catastrophic and I need to know if
there is.

> } - As always, completion is so complicated it could do pretty much
> }   anything
> 
> Well, yeah.  So perhaps I should refine my question:  What effect is
> this eventually intended to have on completion when all of the details
> have been worked out?  (Something which may, conceivably, never come
> entirely to pass, I admit).

I don't think it should have any, for the reasons given above.  Anything
that looks different, other than having the characters displayed
more correctly, is probably a bug.

For example, I've made no attempt to do anything clever when displaying
completion lists.  They need to be fixed up along the same lines as the
command line.

Index: Src/Zle/zle_tricky.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/Zle/zle_tricky.c,v
retrieving revision 1.91
diff -u -r1.91 zle_tricky.c
--- Src/Zle/zle_tricky.c	13 Apr 2008 16:58:43 -0000	1.91
+++ Src/Zle/zle_tricky.c	14 Apr 2008 08:59:11 -0000
@@ -978,6 +978,14 @@
     zlemetaline[zlemetall] = '\0';
     zleline = stringaszleline(zlemetaline, zlemetacs, &zlell, &linesz, &zlecs);
 
+#ifdef MULTIBYTE_SUPPORT
+    /*
+     * If we inserted combining characters under the cursor we
+     * won't have tested the effect yet.  So fix it up now.
+     */
+    alignmultiwordright(1);
+#endif
+
     free(zlemetaline);
     zlemetaline = NULL;
 }

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070