> I think that the cleanest thing to do, in loops that don't need to be
> as fast as possible, is avoid saving addresses of string data at all.
I agree. But, I think display_mode_element is the place
that have to be as fast as possible.
I would think that it doesn't take up very much of Emacs cpu time,
and that a small slowdown there would be insignificant. That function
calls subroutines that do a lot of work.
Looking at the new code, I think it is correct. It is correct because
the code consists of many alternatives, and each one does only a
single nontrivial thing and then gets to the end, where lisp_string
and this are updated. But it seems a bit fragile to me.
What if some branch is later changed to do two things that could
relocate? Then it would have a bug again.
So I think I will still put in the change I made.
The reason I worry about the patch you made is that it depends
on knowing exactly where the relocation might occur.
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
