Re: "special" spaces in Texinfo parsing and output

[Karl Berry]

    It seems that that the makeinfo in C
    considered explicitly spaces to be something along [\r\n\t ].

Yes.

    something sensible and consistent with TeX/LaTeX, having something
    sensible coming first.

Agreed, but fortunately, there's no conflict.  (La)TeX does something
sensible, namely the same as C makeinfo.

    So, what should be done?  

Consider [\r\n\t ] to be space characters?  That's what seems like the
simplest and most expected result to me.

    Do something different for parsing or is it ok to have all the space
    like characters be considered as spaces?  

No, it's not ok.  That's what occasioned the report in the first place
-- we don't want to lose form feeds.

    And for the output?  Break words only at [\r\n\t ]?  

Sounds right to me.  As Eli said, it seems reasonable to have a conf
variable to allow people to make their own.  Maybe.

    Keep the first space character only if it is not [\r\n]?

I'm not sure what you mean.

    ascii "\xA0" does not map to Unicode at Texinfo/Parser.pm line 1909

Ironically, A0 is one of the few Unicode space characters which can be
reasonably mapped to ASCII, namely just a simple space (at which a line
break cannot occur).

However, we don't really want to implement the semantics of the Unicode
space characters, let alone the full Unicode line-breaking algorithm, I
feel sure.  At least not right now.  That's another whole major project.
Just for example, there are other characters which end a sentence in
Unicode too ... http://www.fileformat.info/info/unicode/char/3002/
etc.  It's endless.

Meanwhile, if someone declares us-ascii but then uses non-ascii
characters, that's not our problem.  It would be nice to output them
as-is instead of losing them (that's what C makeinfo did, I believe),
but I wouldn't say even that is 100% mandatory.

Wdyt?

k