scratch/accurate-warning-pos: First tentative successes.

[Alan Mackenzie <acm@muc.de>]

Hello, Eli and Stefan.

I have just committed another commit to scratch/accurate-warning-pos.  It
now "works"!

To see this, create one or both of these test files:

(i) winkler.el, from bug #9109:

    (unwind-protect
        (let ((foo "foo"))
          (insert foo))
      (setq foo "bar"))

(ii) pit-claudel.el, from bug #22288:

    (defun test ()
      (let (a))
        a)

Then build the SW, start it (with or without -Q) and run the byte
compiler with the current mechanism for warnings:

    M-: (byte-compile-file "~/winkler.el")

.  Then run the byte compiler again, with the new mechanism:

    M-: (let ((symbols-with-pos-enabled t)) (byte-compile-file "~/winkler.el"))

.  Note the positions in the warning messages.

Eli, in bug #24128, you complained that in compiling progmodes/gud-mi.el
and progmodes/gud.el, you got warning message positions which were
clearly wrong.  Would it be possible to reconstruct the versions of those
files which gave these errors?  It would be great to be able to try them
out on this new software.

However...

This approach to fixing the bug has disadvantages, namely:
(i) The meanings of `eq' and `symbolp' have been modified.
(ii) It has slowed Emacs down somewhat.  (By about 8% in an unoptimised
build; I haven't yet timed an optimsed build).

On the other hand...

Given the difficulty of the problem, there is probably no way of solving
it without such disadvantages.  We've searched for and explored several
alternatives, and none of them were good.  And the approach in
scratch/accurate-warning-pos DOES solve all these bugs, not being in any
sense a workaround.  There might well be optimisations which could reduce
the slowdown.

So....

Are we going to carry on developing this thing, with a view to
integrating it into Emacs, or are we not?  It would be good to decide
this before spending much more time on it.

-- 
Alan Mackenzie (Nuremberg, Germany).