>>>>> "AM" == Adrian Mariano <rad...@cox.net> writes:
AM> The date in units.man reflects, I believe, the last date I made AM> nontrivial changes to the manual. Is there some reason it should be AM> some other date? Well otherwise the package will look "dead". Just my opinion. AM> It appears that emacs is inserting a single space sometimes when AM> I use autofill to write comments. Is this the white space you're AM> suggesting that I remove? (I don't see that it presents a problem.) AM> Or is there something more troublesome somewhere? (setq-default show-trailing-whitespace t) Let's reduce our whitespace carbon footprint together. I'm one of those neurotic anti-trailing-whitespace types. AM> Do you find that the utf8 support in the new version is working AM> properly? One thing I don't understand is how chinese characters are AM> supposed to interact with western characters. It seems like when they AM> are mixed, columns don't line up properly. (An example would be when AM> you type "?" at the "You have" prompt to get a list of conformable AM> units.) You have: Display all 2452 possibilities? (y or n) ... Looked OK for me but of course over the years I have tuned xterm, etc. AM> I took a look at your patch and have two concerns. One is that I have AM> utf8 stuff placed inside !utf8 / !endutf8 pairs so that the non-ASCII AM> definitions can be ignored when utf8 support is not available. See AM> the large block of utf8 definitions at the end of the file included in AM> the alpha distribution of the code. (It's fine to use extended chars AM> in comments outside of these blocks.) Either we can wrap each of the AM> three new sections with this, or we can group the new sections into AM> one section where the taiwanese character appear. I don't know which AM> makes more sense. Better wrap each section separately... or better yet, assume the whole file is uft-8 and remove any !utf8 markers. Indeed I see some confusion with locales vs. character sets in your implementation...!! You have the same syntax for "I like use utf-8" and "I like using British gallons". And, you can't have more than one character set in the file itself, so just demand that it be utf-8. As far as if the user's computer supports utf8 output, that is a different story. Looks like it is getting over my head here. AM> The other things was here: >> +# http://en.wikipedia.org/wiki/Taiwanese_units_of_measurement >> +坪 tsubo # http://zh.wikipedia.org/wiki/坪 >> +甲 2934 坪 # http://zh.wikipedia.org/wiki/甲_(单位) >> +分地 1|10 甲 # http://zh.wikipedia.org/wiki/分 #+地 to >> disambiguate >> + AM> I format units.dat so that it displays in an 80 (western) character AM> wide window. This last line is too long, and I don't understand AM> what's being disambiguated, so I'm not sure of the best fix. Sorry, just shorten the " " between column 1 and 2 perhaps for that paragraph. 分 is so common like "part", so I changed it to "part_land" so as to not claim the word for the whole world, as surely the Japanese have more uses for it... Actually I was considering 台坪，台甲，台分 vs. 坪地，甲地，分地 But the Japanese also use the same 坪 etc. etc. Let's see what the other nerds on the Cc: list say. AM> Also, do you have any idea where 2934 came from? It's a strange number and AM> for the most part, units definitions don't include strange numbers AM> like that. (In other words, can this unit be defined in a way that is AM> less strange?) Just one of the larger http://en.wikipedia.org/wiki/Morgen 's apparently. Google finds lots about it, but no one says how the odd $ factor 2934 2934: 2 3 3 163 actually came about. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
