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

[Stephen J. Turnbull]

>>>>> "Andrew" == Andrew Suffield <address@hidden> writes:

    Andrew> On Thu, Aug 28, 2003 at 10:04:51PM +0900, Stephen
    Andrew> J. Turnbull wrote:

    >> File a bug report.  Shouldn't be that way.

    Andrew> Easy to say, but I can't file a _useful_ bug report

All bug reports are useful, at least at the current rate they come in,
as long as you use M-x report-xemacs-bug.

As far as I knew, the only annoying latencies in XEmacs 21.4.13 were
GC (which will take a lot of effort to fix), the various X latency
bugs (but those only manifest if there's a network between your client
and the X server), the Motif clipboard insanity, and the XmPrimitive
breakage in Motif.

So simply M-x report-xemacs-bug RET and cut/paste what you've already
told me would be useful.

    Andrew> because I don't know where the latency comes from, most of
    Andrew> the time (font-lock-mode is an extreme case; there's also
    Andrew> something fishy with mule, or at least japanese
    Andrew> input/display, but I still haven't been able to identify
    Andrew> whether that's even xemacs at fault).

File a bug report.  だって、日本語が得意だから、分かっているだろう。
Correlating your report with the experience of other Japanese users
may tell us something.

    Andrew> Or, more succinctly: what use is there in worrying about
    Andrew> the architecture if it can't solve the real-world
    Andrew> problems?

"It's the architecture, stupid."  Let me take that back.  "It's the
stupid architecture."

Or as Jamie Zawinski put it: "Some people see a problem, they say,
'Aha! I'll use regexps.'  Now they have two problems."[1]  XEmacs (GNU
Emacs) claims to be a text-processing program par excellance.  So why
does it force you to have a second problem?  Regexps are robust
solutions to only half the requirement.

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.

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

Take mmm-mode, which is really critical to handling embedded snippets
of foreign languages (Javascript in HTML in Perl here documents, for
example).  Works, but....  I haven't tried implementing it yet, but I
really think that it's time to abandon the notion that modes attach to
buffers.  They should attach to extents (overlays) in buffers.  Making
this robust, it would be nice if there were a parse tree in the
back-ground to sanity check Emacs's assessment about where the
Javascript ends and the HTML begins.

Footnotes: 
[1]  Nothing against regexps.  Jeff Friedl is a (real-space, if you
consider Japan part of reality) hero of mine, regexps were involved.
But there is a time and a place for everything.


-- 
Institute of Policy and Planning Sciences     http://turnbull.sk.tsukuba.ac.jp
University of Tsukuba                    Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
               Ask not how you can "do" free software business;
              ask what your business can "do for" free software.