Re: advice needed for multi-threading patch

[Tom Tromey]

>>>>> "Ken" == Ken Raeburn <address@hidden> writes:

Ken> I hope you and Daniel and I aren't doing redundant work.

Unless your changes apply to Emacs I don't think they are really
redundant.  I think the key thing is agree how it ought to work, so we
end up with the same model, but I don't anticipate any problems there.

Ken> I've written similar elisp code for doing transformations of patterns
Ken> within the Emacs code -- mostly more localized things like "XCONS
Ken> (expr)->car" to "XCAR (expr)", but with support for somewhat complex
Ken> values of "expr" that have to have balanced parens, etc.

If you still have these, I would appreciate a copy, so that I don't have
to reinvent them.  Are they in your git repository?

Ken> I wonder if anyone's looking at collecting elisp tools for C
Ken> refactoring somewhere.

There may be some on the CEDET site.  I don't remember seeing any on the
wiki or elsewhere.

Ken> Should I take this to mean you've already dealt with the buffer-local
Ken> variables created by make-variable-buffer-local, which don't live in
Ken> the buffer structure?

Well... nominally.  It is still a buggy mess.

Ken> If so, I wonder if you can make use of those
Ken> changes, by replacing XBUFFER(b)->thing with SYMBOL_VALUE(Qthing)
Ken> where Qthing holds a symbol that's marked as buffer-local; then all
Ken> the changes for the interaction between thread-local and buffer-local
Ken> bindings would be localized in indirect_variable and friends, which
Ken> would then have to deal with both Lisp_Misc_Buffer_Objfwd and
Ken> Lisp_Misc_Buffer_Local_Value.

I will have to think about this.  This would imply removing all those
slots from struct buffer; I suppose my concern would be that the result
would be too inefficient.

I've also been considering a similar thing for the Vfoo globals: remove
them and have the C code always refer to them via SYMBOL_VALUE.

Tom