PATCH: make unicode support configurable

PATCH: make unicode support configurable

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 820 bytes --]

Here's a first pass at turning the ZLE_UNICODE_SUPPORT define into a
configure item.  The attached patch allows the user to specify either
--with-unicode-support or --without-unicode-support (to force the
decision), otherwise it runs a test to see if it thinks unicode can
be supported (which consists of the current checks from system.h
transplanted into configure).  The code in system.h was also modified
to check the value of ZLE_UNICODE_SUPPORT instead of set it.

Some questions that should be answered:

  o Do we like the above name for the --with/--without option?
  o Is including locale.h (if it exists) the right include file for
    the new configure test for __STDC_ISO_10646__?  (It works on my
    Linux system.)
  o Do we need the old unicode "subset" logic that I removed from
    system.h?

..wayne..

[-- Attachment #2: unicode.patch --]
[-- Type: text/plain, Size: 2032 bytes --]

--- configure.ac	1 Aug 2005 09:54:56 -0000	1.37
+++ configure.ac	15 Aug 2005 16:56:54 -0000
@@ -2063,6 +2063,43 @@ int ptsname();], ,
    fi
 fi
 
+dnl ---------------
+dnl unicode support
+dnl ---------------
+AC_ARG_WITH(unicode-support,
+[  --with-unicode-support     support unicode characters in the line editor])
+
+echo $with_unicode_support >/tmp/uni
+case x"$with_unicode_support" in
+  xyes) zsh_cv_c_zle_unicode_support=yes ;;
+  xno) zsh_cv_c_zle_unicode_support=no ;;
+  *)
+    AC_CACHE_CHECK(if the compiler supports wide characters,
+     zsh_cv_c_zle_unicode_support,
+    [AC_TRY_COMPILE([
+#ifdef HAVE_LOCALE_H
+# include <locale.h>
+#endif
+     ], [
+int main() {
+#if defined(HAVE_WCHAR_H) && defined(HAVE_WCTOMB) \
+ && defined(HAVE_MBRTOWC) && defined(HAVE_WCRTOMB) \
+ && defined (__STDC_ISO_10646__)
+    return 0;
+#else
+#error Not supported.
+#endif
+}
+    ],
+      zsh_cv_c_zle_unicode_support=yes,
+      zsh_cv_c_zle_unicode_support=no)])
+    ;;
+esac
+AH_TEMPLATE([ZLE_UNICODE_SUPPORT],
+[Define to 1 if you want unicode support in the line editor.])
+if test $zsh_cv_c_zle_unicode_support = yes; then
+  AC_DEFINE(ZLE_UNICODE_SUPPORT)
+fi
 
 dnl ---------------
 dnl dynamic loading
--- Src/system.h	15 Aug 2005 10:01:48 -0000	1.33
+++ Src/system.h	15 Aug 2005 16:56:54 -0000
@@ -691,22 +691,9 @@ extern short ospeed;
 #define UNUSED(x) x
 #endif
 
-/*
- * This is a subset of ZLE_UNICODE_SUPPORT.  It is not all that likely
- * that only the subset is supported, however it's easy to make the
- * \u and \U escape sequences work with just the following.
- */
-#if defined(HAVE_WCHAR_H) && defined(HAVE_WCTOMB) && defined (__STDC_ISO_10646__)
+#ifdef ZLE_UNICODE_SUPPORT
 # include <wchar.h>
 # include <wctype.h>
-
-/*
- * More stringent requirements to enable complete Unicode conversion
- * between wide characters and multibyte strings.
- */
-#if defined(HAVE_MBRTOWC) && defined(HAVE_WCRTOMB)
-#define ZLE_UNICODE_SUPPORT	1
-#endif
 #else
 # ifdef HAVE_LANGINFO_H
 #   include <langinfo.h>

Re: PATCH: make unicode support configurable

[Peter Stephenson]

Wayne Davison wrote:
>   o Do we like the above name for the --with/--without option?

Probably something more general is appropriate (indeed, it would
be for the name ZLE_UNICODE_SUPPORT if the definition doesn't depend on
ISO 10646).  --enable-multibyte-zle is about the best I can think of.

>   o Is including locale.h (if it exists) the right include file for
>     the new configure test for __STDC_ISO_10646__?  (It works on my
>     Linux system.)

No idea about this.

>   o Do we need the old unicode "subset" logic that I removed from
>     system.h?

It's possible we might: it controls whether printf understands Unicode.
That depends on rather less support being present than for zle.  It's
quite useful to be able to print Unicode characters even without the
support in zle.  Eventually, we might decide that there's a high enough
level of support for zle in any system where we can print Unicode characters,
but we haven't got there yet.

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


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************

Re: PATCH: make unicode support configurable

[Wayne Davison]

[-- Attachment #1: Type: text/plain, Size: 1163 bytes --]

On Mon, Aug 15, 2005 at 06:27:37PM +0100, Peter Stephenson wrote:
> Probably something more general is appropriate [...]
> --enable-multibyte-zle is about the best I can think of.

OK.  I also like Oliver's logic that we will want to tie-in any future
multibyte support into the same option, so my newest patch changes the
option name to just --enable-multibyte.  If we decide the -zle suffix
is better, it will be easy to add.

> (indeed, [something more general] would be [appropriate] for the name
> ZLE_UNICODE_SUPPORT if the definition doesn't depend on ISO 10646). 

I'll leave any possible renaming of the ZLE_UNICODE_SUPPORT define for
later.

> It's possible we might: it controls whether printf understands Unicode.

Oh, I didn't realize that.  I've restored that logic in this new patch
and enhanced the comment to mention printf.  The code in system.h still
checks for __STDC_ISO_10646__ for this, though I don't know if the
subset actually needs this test or not.

My new patch also removes some debug code that got left in the previous
patch (it echoed a var to /tmp/uni).

Let me know if there are any objections to my checking this in.

..wayne..

[-- Attachment #2: multibyte.patch --]
[-- Type: text/plain, Size: 2327 bytes --]

--- configure.ac	1 Aug 2005 09:54:56 -0000	1.37
+++ configure.ac	15 Aug 2005 18:22:36 -0000
@@ -2063,6 +2063,37 @@ int ptsname();], ,
    fi
 fi
 
+dnl ---------------------
+dnl multibyte ZLE support
+dnl ---------------------
+AC_ARG_ENABLE(multibyte,
+[  --enable-multibyte         support multibyte chars in the zsh line editor],
+[zsh_cv_c_zle_unicode_support=$enableval],
+[AC_CACHE_CHECK(if the system adequately supports multibyte chars,
+ zsh_cv_c_zle_unicode_support,
+  [AC_TRY_COMPILE([
+#ifdef HAVE_LOCALE_H
+# include <locale.h>
+#endif
+   ], [
+int main() {
+#if defined(HAVE_WCHAR_H) && defined(HAVE_WCTOMB) \
+ && defined(HAVE_MBRTOWC) && defined(HAVE_WCRTOMB) \
+ && defined (__STDC_ISO_10646__)
+    return 0;
+#else
+# error Not supported.
+#endif
+}
+  ],
+    zsh_cv_c_zle_unicode_support=yes,
+    zsh_cv_c_zle_unicode_support=no)])
+])
+AH_TEMPLATE([ZLE_UNICODE_SUPPORT],
+[Define to 1 if you want unicode support in the line editor.])
+if test $zsh_cv_c_zle_unicode_support = yes; then
+  AC_DEFINE(ZLE_UNICODE_SUPPORT)
+fi
 
 dnl ---------------
 dnl dynamic loading
--- Src/system.h	15 Aug 2005 10:01:48 -0000	1.33
+++ Src/system.h	15 Aug 2005 18:22:36 -0000
@@ -692,21 +692,17 @@ extern short ospeed;
 #endif
 
 /*
- * This is a subset of ZLE_UNICODE_SUPPORT.  It is not all that likely
- * that only the subset is supported, however it's easy to make the
- * \u and \U escape sequences work with just the following.
+ * The ZLE_UNICODE_SUPPORT configure-define specifies that we want to enable
+ * complete Unicode conversion between wide characters and multibyte strings.
  */
-#if defined(HAVE_WCHAR_H) && defined(HAVE_WCTOMB) && defined (__STDC_ISO_10646__)
-# include <wchar.h>
-# include <wctype.h>
-
+#if defined ZLE_UNICODE_SUPPORT \
+ || (defined HAVE_WCHAR_H && defined HAVE_WCTOMB && defined __STDC_ISO_10646__)
 /*
- * More stringent requirements to enable complete Unicode conversion
- * between wide characters and multibyte strings.
+ * If ZLE_UNICODE_SUPPORT is not defined, these includes provide a subset of
+ * Unicode support that makes the \u and \U printf escape sequences work.
  */
-#if defined(HAVE_MBRTOWC) && defined(HAVE_WCRTOMB)
-#define ZLE_UNICODE_SUPPORT	1
-#endif
+# include <wchar.h>
+# include <wctype.h>
 #else
 # ifdef HAVE_LANGINFO_H
 #   include <langinfo.h>

Re: PATCH: make unicode support configurable

[Oliver Kiddle]

Wayne Davison wrote:
> 
> Some questions that should be answered:
> 
>   o Do we like the above name for the --with/--without option?

--enable-multibyte is more conventional. "with" options are meant for
enabling support for things that use external components.

Although including zle in the name as Peter suggests is accurate at the
moment, I assume that we'd not want multiple options once multibyte
support is added to other parts of the shell.

>   o Is including locale.h (if it exists) the right include file for
>     the new configure test for __STDC_ISO_10646__?  (It works on my
>     Linux system.)

Seems right for my system too.

>   o Do we need the old unicode "subset" logic that I removed from
>     system.h?

I think so. Unless you want --disable-multibyte to disable \u and \U.
Note that \u and \U could be useful even in a non-multibyte locale.

Oliver


This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

Re: PATCH: make unicode support configurable

[Peter Stephenson]

Oliver Kiddle wrote:
> --enable-multibyte is more conventional.

Yes, that would be fine.

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


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

**********************************************************************