Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
On 04/03/15 00:44, Will Miles wrote: Hi Allan, Gnulib has solutions for patches 3, 4, and 5 (wcwidth/wcswidth, asprintf/vasprintf, and mkdtemp) - basically everything QNX is missing. A solution to embed gnulib would be very practical. I tried a simple build by following the gnulib instructions, but had some trouble getting it to build PIC for including mkdtemp in libalpm; unfortunately I got called away to another project before I could investigate further. If you have any specific tips for how best to perform the integration, I'd be very interested. I have only looked at using it once very long ago, so I can not help much here. I'm sure I could find someone in the wider Arch community to help us out if needed. Cheers, Allan
Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
Hi Allan, Gnulib has solutions for patches 3, 4, and 5 (wcwidth/wcswidth, asprintf/vasprintf, and mkdtemp) - basically everything QNX is missing. A solution to embed gnulib would be very practical. I tried a simple build by following the gnulib instructions, but had some trouble getting it to build PIC for including mkdtemp in libalpm; unfortunately I got called away to another project before I could investigate further. If you have any specific tips for how best to perform the integration, I'd be very interested. Thanks, -Will On 2015-03-02 11:50 PM, Allan McRae wrote: From what I understand, if gnulib does work then we should add it as a git submodule and adjust our configure to use functions from there when necessary. We can look into that further if you gnulib does lots of what you need. Thanks, Allan On 28/02/15 07:20, Will Miles wrote: Gnulib does indeed have the necessary bits for patches 3, 4, and 5. Consider them withdrawn, then, and I'll update my QNX build environment accordingly. -Will On 2/27/2015 3:27 PM, Allan McRae wrote: On 28/02/15 06:24, Allan McRae wrote: On 28/02/15 05:43, Will Miles wrote: The specific implementation has been copied from Markus Kuhn at http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Signed-off-by: Will Miles wmi...@sgl.com I don't intend to accept reimplementations of POSIX functions into pacman. I'm not even sure what system we supported that did not have strndup... Cygwin maybe? Answering my own question - OSX. Check if gnulib provides all the needed functions. If so, that might be the root to take. Allan
Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
From what I understand, if gnulib does work then we should add it as a git submodule and adjust our configure to use functions from there when necessary. We can look into that further if you gnulib does lots of what you need. Thanks, Allan On 28/02/15 07:20, Will Miles wrote: Gnulib does indeed have the necessary bits for patches 3, 4, and 5. Consider them withdrawn, then, and I'll update my QNX build environment accordingly. -Will On 2/27/2015 3:27 PM, Allan McRae wrote: On 28/02/15 06:24, Allan McRae wrote: On 28/02/15 05:43, Will Miles wrote: The specific implementation has been copied from Markus Kuhn at http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Signed-off-by: Will Miles wmi...@sgl.com I don't intend to accept reimplementations of POSIX functions into pacman. I'm not even sure what system we supported that did not have strndup... Cygwin maybe? Answering my own question - OSX. Check if gnulib provides all the needed functions. If so, that might be the root to take. Allan
Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
On 28/02/15 06:24, Allan McRae wrote: On 28/02/15 05:43, Will Miles wrote: The specific implementation has been copied from Markus Kuhn at http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Signed-off-by: Will Miles wmi...@sgl.com I don't intend to accept reimplementations of POSIX functions into pacman. I'm not even sure what system we supported that did not have strndup... Cygwin maybe? Answering my own question - OSX. Check if gnulib provides all the needed functions. If so, that might be the root to take. Allan
[pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
The specific implementation has been copied from Markus Kuhn at
http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
Signed-off-by: Will Miles wmi...@sgl.com
---
src/common/util-common.c | 225 +++
src/common/util-common.h | 6 ++
2 files changed, 231 insertions(+)
diff --git a/src/common/util-common.c b/src/common/util-common.c
index e834168..6c9b263 100644
--- a/src/common/util-common.c
+++ b/src/common/util-common.c
@@ -163,4 +163,229 @@ char *strndup(const char *s, size_t n)
}
#endif
+
+#ifndef HAVE_WCWIDTH
+/*
+ * This is an implementation of wcwidth() and wcswidth() (defined in
+ * IEEE Std 1002.1-2001) for Unicode.
+ *
+ * http://www.opengroup.org/onlinepubs/007904975/functions/wcwidth.html
+ * http://www.opengroup.org/onlinepubs/007904975/functions/wcswidth.html
+ *
+ * In fixed-width output devices, Latin characters all occupy a single
+ * cell position of equal width, whereas ideographic CJK characters
+ * occupy two such cells. Interoperability between terminal-line
+ * applications and (teletype-style) character terminals using the
+ * UTF-8 encoding requires agreement on which character should advance
+ * the cursor by how many cell positions. No established formal
+ * standards exist at present on which Unicode character shall occupy
+ * how many cell positions on character terminals. These routines are
+ * a first attempt of defining such behavior based on simple rules
+ * applied to data provided by the Unicode Consortium.
+ *
+ * For some graphical characters, the Unicode standard explicitly
+ * defines a character-cell width via the definition of the East Asian
+ * FullWidth (F), Wide (W), Half-width (H), and Narrow (Na) classes.
+ * In all these cases, there is no ambiguity about which width a
+ * terminal shall use. For characters in the East Asian Ambiguous (A)
+ * class, the width choice depends purely on a preference of backward
+ * compatibility with either historic CJK or Western practice.
+ * Choosing single-width for these characters is easy to justify as
+ * the appropriate long-term solution, as the CJK practice of
+ * displaying these characters as double-width comes from historic
+ * implementation simplicity (8-bit encoded characters were displayed
+ * single-width and 16-bit ones double-width, even for Greek,
+ * Cyrillic, etc.) and not any typographic considerations.
+ *
+ * Much less clear is the choice of width for the Not East Asian
+ * (Neutral) class. Existing practice does not dictate a width for any
+ * of these characters. It would nevertheless make sense
+ * typographically to allocate two character cells to characters such
+ * as for instance EM SPACE or VOLUME INTEGRAL, which cannot be
+ * represented adequately with a single-width glyph. The following
+ * routines at present merely assign a single-cell width to all
+ * neutral characters, in the interest of simplicity. This is not
+ * entirely satisfactory and should be reconsidered before
+ * establishing a formal standard in this area. At the moment, the
+ * decision which Not East Asian (Neutral) characters should be
+ * represented by double-width glyphs cannot yet be answered by
+ * applying a simple rule from the Unicode database content. Setting
+ * up a proper standard for the behavior of UTF-8 character terminals
+ * will require a careful analysis not only of each Unicode character,
+ * but also of each presentation form, something the author of these
+ * routines has avoided to do so far.
+ *
+ * http://www.unicode.org/unicode/reports/tr11/
+ *
+ * Markus Kuhn -- 2007-05-26 (Unicode 5.0)
+ *
+ * Permission to use, copy, modify, and distribute this software
+ * for any purpose and without fee is hereby granted. The author
+ * disclaims all warranties with regard to this software.
+ *
+ * Latest version: http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c
+ */
+
+#include wchar.h
+
+struct interval
+{
+ int first;
+ int last;
+};
+
+/* auxiliary function for binary search in interval table */
+static int bisearch(wchar_t ucs, const struct interval *table, int max)
+{
+ int min = 0;
+ int mid;
+
+ if(ucs table[0].first || ucs table[max].last)
+ return 0;
+ while(max = min) {
+ mid = (min + max) / 2;
+ if(ucs table[mid].last)
+ min = mid + 1;
+ else if(ucs table[mid].first)
+ max = mid - 1;
+ else
+ return 1;
+ }
+
+ return 0;
+}
+
+
+/* The following two functions define the column width of an ISO 10646
+ * character as follows:
+ *
+ *- The null character (U+) has a column width of 0.
+ *
+ *- Other C0/C1 control characters and DEL will lead to a return
+ * value of -1.
+ *
+ *- Non-spacing and enclosing combining characters (general
+ * category code Mn or Me in the Unicode database) have a
+ * column width of 0.
+ *
+ *- SOFT
Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
On 28/02/15 05:43, Will Miles wrote: The specific implementation has been copied from Markus Kuhn at http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Signed-off-by: Will Miles wmi...@sgl.com I don't intend to accept reimplementations of POSIX functions into pacman. I'm not even sure what system we supported that did not have strndup... Cygwin maybe? Check if gnulib provides all the needed functions. If so, that might be the root to take. Allan
Re: [pacman-dev] [PATCH 3/6] common: Add support for wcwidth and wcswidth for systems without.
Gnulib does indeed have the necessary bits for patches 3, 4, and 5. Consider them withdrawn, then, and I'll update my QNX build environment accordingly. -Will On 2/27/2015 3:27 PM, Allan McRae wrote: On 28/02/15 06:24, Allan McRae wrote: On 28/02/15 05:43, Will Miles wrote: The specific implementation has been copied from Markus Kuhn at http://www.cl.cam.ac.uk/~mgk25/ucs/wcwidth.c Signed-off-by: Will Miles wmi...@sgl.com I don't intend to accept reimplementations of POSIX functions into pacman. I'm not even sure what system we supported that did not have strndup... Cygwin maybe? Answering my own question - OSX. Check if gnulib provides all the needed functions. If so, that might be the root to take. Allan
