Re: patch to avoid huge buffer in scan-skel.l

[Akim Demaille]

 >> Fetching char per char is quite known to cost in Lex scanners.  This
 >> is taken from the documentation of Flex (but I agree anyway that M4
 >> dominates the costs today):

 Paul> Perhaps when we fix the m4 problem we can revisit the issue.  Frankly
 Paul> I have grown somewhat disillusioned with m4 for this application,
 Paul> given all the quoting problems I've had to deal with in the last
 Paul> couple of months.

Please, don't!

I _agree_ there are many problems, but I am still fairly convinced
that the framework is good.  It just lacks some features.  If you find
some spare time, spend it reading the documentation of M5: there are a
few simple ideas in there that we just need to steal and implement in
GNU M4 to suddenly vastly simplify, improve and immensely speed up all
our M4 based tools.  The last significant effort will be making M4 be
a library.

The effort is much more significant than that for a simple Bison ad
hoc solution, I very much agree.  But the longer road also has many
more consequence, with, in the full picture (not just Bison, but Free
Software), globally more benefits.

Of course, one needs time to achieve this :(

       http://sunsite.berkeley.edu/TechRepPages/CSD-91-621