Re: [Gnu-arch-users] [OT] Architectural renovation

[Tom Lord]

    > From: "Stephen J. Turnbull" <address@hidden>

    > Or as Jamie Zawinski put it: "Some people see a problem, they say,
    > 'Aha! I'll use regexps.'  Now they have two problems."[1]  

Actually, that joke originated long before JWZ.   The earlier version
that I know of goes:

        Some people, whenever they have a problem, decide to use awk.
        Then they have two problems.

Given the overlap of communities in which JWZ and I travelled, I
suspect he just snarked the version I heard.

    > Radically changing the way we implement font-lock and other syntactic
    > analysis would make a big difference.  Using a one-pass shift-reduce
    > parser instead of the ad-hoc methods we now use would make localizing
    > any problems much easier.  And I suspect that it would "magically"
    > make the font-lock and context-sensitive indenting, etc, go away.

You simply haven't thought that through.

    > And there are lots of hacks that would be trivial _if_ there were a
    > parse tree available.  But there isn't.

Nor is there a grammar for C or C++ source pre-CPP.  Poke around
googlishly or, if you _really_ get stuck, I'm willing to have a stab
at some not-unpacked boxes of books -- there's research on
syntax-directed editors, some of which even uses emacs.  It's hard,
and a real mixed-bag of results -- if you design a language with it in
mind, it gets easier (but good luck with macros).

The emacs regexp engine is fast at a very simple subset of its
language.  Beyond that, it's a dog, partly by virtue of the language,
partly by virtue of the implementation.  Changing it is not easy
either -- plenty of tricky performance tuning.

And, oh yeah, gap buffers are lame.


-t