[Pyparsing] SEVERE BUG probably because overwriting of WhitespaceChars

[Stephan Sahm]

Dear all,
(I just asked the question "How to use ~ / NotAny() combined with
LineStart() ?" - I think the problem there might be related to the BUG I
just tracked down)

I experienced several problems with using LineStart(). Now I tracked down a
minimal failing example which shows (at least for me) that this is in fact
a BUG, probably within updating WhitespaceChars.

Example Code:
```
from pyparsing import *

string = "\nstart\nend"

SOL = LineStart()
start = SOL + Literal("start")
end = SOL + Literal("end")

parser = start.setDebug() + end # same for OneOrMore, ZeroOrMore and
certainly more...
print parser.parseString(string)
# Match {LineStart "start"} at loc 0(1,1)
# Matched {LineStart "start"} -> ['start']
# ['start', 'end']

parser2 = start.setDebug() + end.setDebug()
print parser2.parseString(string)
# Match {LineStart "start"} at loc 0(1,1)
# Matched {LineStart "start"} -> ['start']
# Match {LineStart "end"} at loc 6(2,1)
# Exception raised:Expected start of line (at char 6), (line:2, col:1)

​```


so the extra of parser2 is just middle.setDebug() (while start.setDebug()
did nothing bad!)
Similar behaviours accur with
OneOrMore, ZeroOrMore and certainly more...

(Of course, one would expect start.setDebug() to break the system as well,
however as asked in my previous question
"How to use ~ / NotAny() combined with LineStart() ?"
​ the start seems to have its special rules)​


After reading some online Q/A it seems that the correct WhitespaceChars are
really essential for LineStart to work.


Any help is appreci
ated!
I really like pyparsings idea, however not be able to work with lines is a
major drawback which I haven't expected.
Hopefully, the bug can be fixed soon

thanks in advance,
best,
Stephan