Re: yet another XEmacs fork;-)

Sunday, 16 November 2008

 Ar an dara lá déag de mí na Samhain, scríobh Julian Bradfield: 

...
 [Aidan wrote:]

 Thanks for those comments and incisive questions. I think I've already
 thought about most of them, though one did point out to me that I
 haven't checked everything I should have checked! 
...
 [...] I don't know why you think the [Mule] coding systems
won't know
 about Unicode. 
You didn’t say anything at all about them knowing about Unicode!

...
 They don't right now, but I have lots of comments of the form
 /* ##### need to convert from Unicode here */ !
 This is just a generalization of the charset precedence lists already
 used in dealing with Unicode the mule-ucs and 21.5 way; or maybe it's
 just a generalization of Latin Unity. (I don't know, latin-unity is
 something I've never felt the need for - I usually know which European
 language I'm writing in, and otherwise I'm using utf-8 anyway.) 
I don’t know what you mean by “generalisation” there. 

...
 >We don’t have robust checks for whether a region is encodable or
 >not--see http://mid.gmane.org/18509.34907.513276.700290＠parhasard.net
 >for some work in that direction, and for me severely underestimating the
 >amount of work I have to do this year--but I can’t see that your
 >approach makes it easier. 

 Thanks, interesting. I don't think I'd do it in lisp. 
I would have been happy with it in Lisp, but the speed sucks, it needs to be
in C. 

...
 >How are you encoding your Unicode characters in the escape-quoted
external
 >encoding? Since this encoding is used for auto-saves and for byte-compiled
 >ELC files, it needs to be capable of encoding every possible XEmacs
 >character.

 Escape-quoted is an ISO2022 variant, and it can (and does) use the
 UTF-8 escape sequence. 
You’ll need to implement that with the 21.4 code base. I’m sure it’ll be
easy to port stuff from 21.5, of course. 

...
 [...]
 >Given that the Mule code points in 21.4 are 19 bits wide, with only #x80000
 >possible code points, and that Unicode’s code points go up to #x10FFFF,
 >how do you encode the excess of #x8FFFF code points?

 They're not 19 bits wide any more ;-) 
OK; you hadn’t said that. 

...
 >exception of the ISO IR 196 sequences that we use in
escape-quoted
 >byte-compiled files in 21.5). We can’t easily do that on 21.5 given the
 >need for Windows support, something SXEmacs has dropped. Had you seen
 >that idea?

 Yes. But my preference at present is just to call out to libiconv
 internally for conversion, rather than actually doing encoding through
 iconv. Surely iconv conversion can be done in lisp, anyway? 
Umm, well, the library was written in C, I don’t think anyone wants to port
it to Lisp! But bindings would be great, and implementing coding systems in
terms of iconv seems more or less ideal to me. 

...
 My take on Windows is that I'm not actively hostile, so I
don't want
 to do anything to make Windows support impossible, but I don't have,
 and am unlikely to make the effort to get, convenient access to a
 Windows development environment. (Maybe if my next laptop runs
 VMware...) 
It might be reasonable to require
http://gnuwin32.sourceforge.net/packages/libiconv.htm for Mule support on
Win32, come to think of it.

-- 
¿Dónde estará ahora mi sobrino Yoghurtu Nghé, que tuvo que huir
precipitadamente de la aldea por culpa de la escasez de rinocerontes?

_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://calypso.tux.org/cgi-bin/mailman/listinfo/xemacs-beta

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998