"Stephen J. Turnbull" <turnbull(a)sk.tsukuba.ac.jp> writes:
No. The particular one I mentioned would most likely simply show up
as "bad HTML" in the W3 mode line. It's not my job to debug someone
else's bad HTML, and I don't. Even if I went after it, the symptom
would be bogus characters left in the file; only Bill Perry would be
able to notice that and maybe figure out what was going on. The
Ebola warning gets my attention, and localizes the problem.
Then it should be made a standard warning, not just a print to stderr
or whatever. Otherwise, I could make a case to debug just about
anything that way.
I want them; I don't see why you should have to suffer them. I
would be happy with an additional debug option to configure. (I
don't know configure magic, so I can't do this myself.) I suspect
that they're more likely to show up in Mule-using environments
(since we're still at the stage of tracking FSF development); maybe
the warnings could be turned on by default only in --with-mule
builds.
I think there should be a `--with-ebola-warnings', off by default.
Even so, implementing them as standard warnings is hard.
A better alternative yet would be to see if we can figure out what
"spurious" Ebola warnings look like and trap them.
Impossible. I can write this perfectly legal Lisp code:
(eq ?a 98)
...and you have no way of knowing whether I really meant to compare ?a
to 98 or to compare ?a to ?b.