Re: Interaction between closing bracket, capital letter and full stop at end of sentence
recognized after "HTML." because you need "HTML@." for that, but I'm I went through the manuals at one point and changed a bunch of ML. to ML@., but I guess more have crept in. (Also an occasional @! and @?.) not sure if the cases with closing brackets are correct. Closing parens are irrelevant, as Andreas described, so @. is needed in cases like HTML)@. Foo HTML@.) Foo too. (Test file below.) (This doesn't seem to be the whole story because it doesn't cover the case of "closing punctuation" BEFORE the full stop.) I guess. Will tweak. > We should probably follow what TeX does in such circumstances. Does anyone know? Plain TeX sets \sfcode`\)=0 \sfcode`\'=0 \sfcode`\]=0, which makes these three characters transparent wrt. the spacefactor. texinfo.tex and makeinfo have always implemented the same rule. C makeinfo did so in fewer cases that Perl makeinfo, but the basic idea was there. K \input texinfo @setfilename sentence-end.info @paragraphindent 0 How about TAB@. L With @@.@* How about TAB. L Just letters.@* How about tab. L Lowercase. (How about TAB)@. L With @@.@* (How about TAB). L Just letters.@* (How about tab). L Lowercase. (How about TAB@.) L With @@.@* (How about TAB.) L Just letters.@* (How about tab.) L Lowercase. @bye
Re: Standalone Info reader cannot read Info files with CR-LF EOLs
> Date: Thu, 8 Jan 2015 11:00:40 + > From: Gavin Smith > Cc: Texinfo > > On Sat, Jan 3, 2015 at 3:29 PM, Eli Zaretskii wrote: > > As you see, wcwidth and locale_charset, both from gnulib in my build, > > take 75% of the time. > > > > I thought that perhaps the reason was that your locale is UTF-8, so > > Info doesn't need to convert text using libiconv in your locale. But > > removing the UTF-8 encoding tag from the ELisp Info file didn't have > > any visible effect on the delay, so that's not it. > > > > Suggestions for further digging into this are welcome. > > One way to check would be to comment out the call to wcwidth, and > replace with the value "1", and see if it is still slow. Doing this completely solves the problem. Moreover, if I replace the line that calls wcwidth: *pchars = wcwidth ((*iter).cur.wc); with what constitutes the body of the gnulib implementation, i.e.: *pchars = (*iter).cur.wc ? (iswprint ((*iter).cur.wc) ? 1 : -1) : 0; I don't see any slowdown, either. My conclusion is that the reason for the slowdown is the call to locale_charset inside gnulib's wcwidth is the culprit, because my locale's charset is not UTF-8. Thanks.
Re: Interaction between closing bracket, capital letter and full stop at end of sentence
Gavin Smith writes: > We should probably follow what TeX does in such circumstances. Does anyone > know? Plain TeX sets \sfcode`\)=0 \sfcode`\'=0 \sfcode`\]=0, which makes these three characters transparent wrt. the spacefactor. Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Interaction between closing bracket, capital letter and full stop at end of sentence
I noticed that in some cases in the Info makeinfo output a single space would be output at the end of a sentence. For example, after "HTML)." or "HTML.)". I'm sure that it an end of sentence shouldn't be recognized after "HTML." because you need "HTML@." for that, but I'm not sure if the cases with closing brackets are correct. The Texinfo manual on this behaviour: "As mentioned above, Texinfo normally inserts additional space after the end of a sentence. It uses a simple heuristic for this: a sentence ends with a period, exclamation point, or question mark followed by optional closing punctuation and then whitespace, and _not_ preceded by a capital letter." (This doesn't seem to be the whole story because it doesn't cover the case of "closing punctuation" BEFORE the full stop.) We should probably follow what TeX does in such circumstances. Does anyone know?
