From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] ox-ascii.el: fixing variable width character handling Date: Sun, 10 Nov 2013 14:09:48 +0100 Message-ID: <87vc00768z.fsf@gmail.com> References: <87zjpcsfoq.wl@dns1.atmark-techno.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51655) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfUlp-0002Gg-9g for emacs-orgmode@gnu.org; Sun, 10 Nov 2013 08:09:46 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VfUlf-00023Y-Tw for emacs-orgmode@gnu.org; Sun, 10 Nov 2013 08:09:41 -0500 Received: from mail-ea0-x22a.google.com ([2a00:1450:4013:c01::22a]:48506) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VfUlf-00020j-Mk for emacs-orgmode@gnu.org; Sun, 10 Nov 2013 08:09:31 -0500 Received: by mail-ea0-f170.google.com with SMTP id q10so1724817eaj.15 for ; Sun, 10 Nov 2013 05:09:30 -0800 (PST) In-Reply-To: <87zjpcsfoq.wl@dns1.atmark-techno.com> (Yasushi SHOJI's message of "Sun, 10 Nov 2013 19:40:21 +0900") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Yasushi SHOJI Cc: emacs-orgmode@gnu.org Hello, Yasushi SHOJI writes: > I've been trying to fix ASCII export back-end for variable width > chars. It is basically replacing `length' with `string-width', but the > behavior of those two functions differ when you give nil as an > argument; `length' returns 0, `string-width' yields a type error: > "eval: Wrong type argument: stringp, nil" Thank you for your patch. > While I came up with the following experimental patch, I have a few > questions: > > - What is the lisp idiom to handle type error? In the following > patch, I've created a new wrapper function > `org-ascii--string-width', it's a thin wrapper with if-then-else. > I thought placing if-then-else clause in the original place clutter > the code. You only use `org-ascii--string-width' in two places. You can write (string-width (or contents "")) instead, it will be less intrusive. BTW, what about `org-ascii--current-text-width'? This function also uses `length' instead of `string-width'. > - If wrapped string-width is good idea, would it be also a good idea > to merge it with `org-string-width' in org.el? Because it is not > ox-ascii specific. The current `org-string-width' does not handle > nil, neither. That would be a good idea, but in a distinct patch. > - The width of the underline for headlines should be checked with > string-width. > > As defined in Unicode Standard Annex #41[1], character width is > environment dependent. So, the calculation of character width at > export time might not be sufficient enough. We can check to see > the exported document contains cjk chars more than some thresholds > or not, I haven't gone that far. I don't think there's much to do about it. Hopefully one can always re-export the Org file in its own environment. > - Does anyone using ox-ascii.el depends on the clipped marker `=>' > for fixed width columns? I thought `...' would be much readable. I have no opinion about it. Though, if we switch to "...", we also need to provide the utf-8 equivalent when using this charset. > - BTW, while looking at table handling, I noticed fixed column width > doesn't work with the code at the current git HEAD. That's because > width calculation is mixed with `length' and `string-width', and > pass out-of-range arguments to `add-text-properties'. I guess your patch also fixed that. Regards, -- Nicolas Goaziou