> Actually, I don't think it is correct to preserve invisible
> white-space at end-of-line, even in verbatim modes. A texinfo file
> should be viewed a text file. Distinctions between different kinds
> of line-ending is not part of the "information set" of a text file,
> and neither is white-spa
On Tue, Feb 09, 2021 at 04:01:53PM -0800, Per Bothner wrote:
> On 2/9/21 1:03 PM, Per Bothner wrote:
> > On general principles, I believe any program that reads text files
> > on *any* platforms should handle "\r\n" the same as "\n".
> > Not doing so is IMNSHO a bug.
> Actually, I'd generalize this
On 2/9/21 4:15 PM, Patrice Dumas wrote:
in general, nothing is ignored at the parsing stage. That way the
original document can be more easily regenerated from a format without
information loss such as TexinfoXML, and also because in some situations
(@verbatim, @verb, @html, @example...) we wan
Do we want to mentor a Google Summer of Code student this year?
I'm particularly interested in EPUB3 support:
https://lists.gnu.org/archive/html/bug-texinfo/2021-01/msg8.html
I can mentor but it would be best to have a co-mentor who understand
the makeinfo Perl code, which I don't really.
I'
On 2/9/21 1:03 PM, Per Bothner wrote:
On general principles, I believe any program that reads text files
on *any* platforms should handle "\r\n" the same as "\n".
Not doing so is IMNSHO a bug.
Actually, I'd generalize this: All invisible "horizontal whitespace"
(' ', '\t', '\r') before a line-en
Am 09.02.2021 um 21:55 schrieb Gavin Smith:
> Yes, it is clearly wrong in this case. It's just a question now of
> understanding the changes in the two earlier commits and making
> sure that we don't break anything that those commits were supposed to
> fix.
I'm pretty sure it's 2d03d088d945a9dc
Per Bothner wrote:
On 2/9/21 11:44 AM, Gavin Smith wrote:
Yes, on Posix platforms. texi2any on MS-Windows should process the
line ends properly. I expect that this happens already.
On general principles, I believe any program that reads text files
on *any* platforms should handle "\r\n" the
On 2/9/21 11:44 AM, Gavin Smith wrote:
Yes, on Posix platforms. texi2any on MS-Windows should process the
line ends properly. I expect that this happens already.
On general principles, I believe any program that reads text files
on *any* platforms should handle "\r\n" the same as "\n".
Not do
On 2/9/21 9:55 PM, Gavin Smith wrote:
On Tue, Feb 09, 2021 at 09:10:28PM +0100, Barath Aron wrote:
The code path I wrote is the trace of the program, I didn't made it up. It
first opened a regular, non-compressed file with fopen() [this was in line
700], then it would freopen()ed [line 882, but
On Tue, Feb 09, 2021 at 09:10:28PM +0100, Barath Aron wrote:
> The code path I wrote is the trace of the program, I didn't made it up. It
> first opened a regular, non-compressed file with fopen() [this was in line
> 700], then it would freopen()ed [line 882, but it won't make any
> difference], th
On 2/9/21 6:11 PM, Gavin Smith wrote:
On Fri, Jan 29, 2021 at 01:41:22PM +0100, Barath Aron wrote:
Hello,
I ran into a bug in the "install-info" program, where the "dir" file is
opened with fopen(), and it was closed with pclose(). That's why
"install-info" hangs on the OS I use.
The path in th
On Tue, Feb 09, 2021 at 09:11:02PM +0200, Eli Zaretskii wrote:
> > From: Gavin Smith
> > Date: Tue, 9 Feb 2021 18:39:09 +
> >
> > > Should we try to modify the parsers to handle dos eol on Unix like
> > > platforms? In that case I could have a go at the perl parser maybe this
> > > weekend.
> From: Gavin Smith
> Date: Tue, 9 Feb 2021 18:39:09 +
>
> > Should we try to modify the parsers to handle dos eol on Unix like
> > platforms? In that case I could have a go at the perl parser maybe this
> > weekend.
>
> My inclination is towards not handling them, as it can't be much of a
On Tue, Feb 09, 2021 at 07:17:47PM +0100, Patrice Dumas wrote:
> On Tue, Feb 09, 2021 at 02:54:02PM +, Gavin Smith wrote:
> > On Tue, Feb 09, 2021 at 02:41:46PM +0100, Patrice Dumas wrote:
> > > Hello,
> > >
> > I think the problem is due to the fact that the file I was using ended
> > lines w
On Tue, Feb 09, 2021 at 02:41:46PM +0100, Patrice Dumas wrote:
> I attach the test I actually used (texi2pdf won't show texte in the
> @node Top even if in @top?)
Yes this avoids having to wrap the Top node in @ifnottex.
On Tue, Feb 09, 2021 at 02:54:02PM +, Gavin Smith wrote:
> On Tue, Feb 09, 2021 at 02:41:46PM +0100, Patrice Dumas wrote:
> > Hello,
> >
> I think the problem is due to the fact that the file I was using ended
> lines with \x0d\x0a (MS-DOS style).
Indeed, the problem happen even outside of @d
On Fri, Jan 29, 2021 at 01:41:22PM +0100, Barath Aron wrote:
> Hello,
>
> I ran into a bug in the "install-info" program, where the "dir" file is
> opened with fopen(), and it was closed with pclose(). That's why
> "install-info" hangs on the OS I use.
> The path in the code is clear.
>
> install
On Tue, Feb 09, 2021 at 02:41:46PM +0100, Patrice Dumas wrote:
> Hello,
>
> It looks good both with texi2any and texi2pdf and no message.
>
> I attach the test I actually used (texi2pdf won't show texte in the
> @node Top even if in @top?)
>
> The "unexpected @" message is indeed the message in
Hello,
It looks good both with texi2any and texi2pdf and no message.
I attach the test I actually used (texi2pdf won't show texte in the
@node Top even if in @top?)
The "unexpected @" message is indeed the message in texi2any for an
unexpected @ followed by an end of line.
On Mon, Feb 08, 2021
19 matches
Mail list logo
