Re: [O] [RFC] ox-ascii.el: fixing variable width character handling

[Nicolas Goaziou]

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