simon-git: halibut (master): Simon Tatham

[Commits to Tartarus hosted VCS]

TL;DR:
  140d8f1 Ignore leading whitespace in an input file.

Repository:     https://git.tartarus.org/simon/halibut.git
On the web:     https://git.tartarus.org/?p=simon/halibut.git
Branch updated: master
Committer:      Simon Tatham <anakin at pobox.com>
Date:           2018-05-17 15:47:03

commit 140d8f13ad91b246a05e033ceeb305d586681fe7
web diff https://git.tartarus.org/?p=simon/halibut.git;a=commitdiff;h=140d8f13ad91b246a05e033ceeb305d586681fe7;hp=4b457fd6fb8121c75e7d748648d2599ee902f848
Author: Simon Tatham <anakin at pobox.com>
Date:   Thu May 17 15:42:04 2018 +0100

    Ignore leading whitespace in an input file.
    
    A user points out (Debian bug #898923) that Halibut copes fine if an
    input file starts with two or more blank lines, or zero, followed by a
    paragraph-initial keyword such as \cfg, but gives a parse error if it
    starts with exactly one. The same failure happens if the file starts
    with a space and then \cfg.
    
    That's because a sequence of leading whitespace containing at least
    two \n is returned as a tok_eop (with an empty paragraph preceding it
    which the parser discards), and no whitespace characters at all don't
    lex as any token, but if there's a sequence of leading whitespace that
    is non-empty and contains fewer than two \n, then it lexes as
    tok_white which the parser wasn't expecting. This only causes trouble
    in the first paragraph of the file, because after that, leading
    whitespace in any subsequent paragraph is folded into the previous
    tok_eop.

 input.c | 22 +++++++++++++++++++---
 1 file changed, 19 insertions(+), 3 deletions(-)