Hello, Yasushi SHOJI <ya...@atmark-techno.com> 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
