scratch/accurate-warning-pos: next steps.

[Alan Mackenzie]

Hello, Emacs.

Here's my scheme for making further progress on the
scratch/accurate-warning-pos branch.

At the moment, it appears to display the requisite accurate source
positions in warning messages, but it slows Emacs down a little.  Hence
it has not been accepted in its current form.

Following an idea from Paul, I propose to build an alternative byte-code
interpreter alongside the primary one.  This second interpreter would
regard symbols with position as being EQ to the corresponding bare
symbols, just as the branch currently does when symbols-with-pos-enabled
is bound to non-nil.

C symbols in components of the second interpreter would be those of the
main one, prefixed by "BC_".

lisp.h would be modified to define alternative versions of EQ, NILP,
SYMBOLP, and XSYMBOL, and alternative versions of the INLINE functions
which call them.  These would be called BC_EQ, BC_NILP, BC_SYMBOLP, and
BC_XSYMBOL.

Most of the C sources would, at build time, be fed to a preprocessor
which would analyse (almost every) C function, and write a temporary file
containing the functions foo and BC_foo next to eachother.  foo would be
unchanged from the C source, BC_foo would have calls to bar modified to
BC_bar, and invocations of EQ etc., modified to BC_EQ, etc.  These
preprocessor outputs would be compiled into temacs in place of the
primary C sources.  The resulting temacs would, of course, be bigger than
the current temacs.

In particular, the byte code interpreter exec_byte_code in bytecode.c
would have its alternative BC_exec_byte_code.

The struct Lisp_Subr would be amended to hold three Lisp_Functions - the
currently live one, the normal one, and the BC_... one.  Also a next
pointer would be introduced, chaining all the subrs together.

The .el and .elc files would not require amendment (apart from
bytecomp.el, and so on, of course).

When a byte compilation is initiated, the compiler would replace the
current live function field with the corresponding BC_ function in every
Lisp_Subr, thus switching over to the BC_... interpreter.  At termination
of the compiler, an unwind-protect would restore the Lisp_Subrs to their
standard settings.

There remains the question, which C functions would get a BC_... version?
To begin with, I propose almost every C function.  Only those for which a
second version would be damaging (for example, the command loop) would
remain unique.  Once the mechanism is working, we could steadily reduce
the number of BC_... functions from "as many as possible" to "what is
needed ".  For example, surely xdisp.c, and xterm.c would not need
duplication.

This scheme would allow accurate warning line numbers to be output,
whilst not slowing down the normal operation of Emacs.  It would likely
slow down the operation of the byte compiler by several per cent, as has
been measured in the current scratch/accurate-warning-pos branch.

Comments?

-- 
Alan Mackenzie (Nuremberg, Germany).