[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [O] [RFC] ox-ascii.el: fixing variable width character handling
From: |
Nicolas Goaziou |
Subject: |
Re: [O] [RFC] ox-ascii.el: fixing variable width character handling |
Date: |
Sun, 10 Nov 2013 14:09:48 +0100 |
Hello,
Yasushi SHOJI <address@hidden> 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