> I was working to implement your proposed solution - it seemed most logicalThat was what I expected, yes. But the more I think about it, the more
> to place overlay_prev_vec in the buffer struct, but placing the three
> necessary properties( overlay_prev_vec, noverlays_prev,
> prev_point_motion_hook ) in the structure caused the 'make' process to
> return a segfault.
it seems it should be a property linked to a window rather than to
a buffer. I think this deserves thought first.
- What should happen if the same buffer is shown in the windows and the
user switches from one to the other? Should the hooks be run at every
window-switch, even though no cursor moves?
- What should happen if a buffer is display in a window and then the
user does C-x b: should the hooks be run?
IIUC, if the data is per-window, then the answers will be "no; yes", if
it's per-buffer, then the answers will be "yes; no".
I believe this is correct.
Whenm thinking about it, it's best to try and think of concrete examples
which would use this feature. And keep in mind that it's usually better
for a hook to be run too many times than too few times (the code that's
run too many times, can try and detect the extra times and do nothing
in those cases).
The use case I was looking at, as I mentioned earlier, was for flymake-like modes to display the actual error messages when point is on an error line. This currently looks like it's usually implemented( or is in js2.el, at least ) by having both an overlay and a text property and keeping the two in sync. In this case, I think that doing C-x o to the same buffer should run the hooks, and that C-x b should not, which would imply that maybe the buffer is the best place to put them.
The slot placement would have been my first thought, otherwise,
> I'm going to look into this more in a few days, but do
> you have any idea why this would be happening, or another implementation
> strategy that wouldn't run into this problem? I followed the instructions
> about placing non-Lisp_Objects above the 'name' variable, so that is most
> likely not the issue.
I can't think of anything particularly likely.