On Thu, Oct 22, 2009 at 11:37 AM, Stefan Monnier
<monnier@iro.umontreal.ca>wrote:

> > I was working to implement your proposed solution - it seemed most
> logical
> > 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.
>
> That was what I expected, yes.  But the more I think about it, the more
> 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.


>
> > 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.
>
> The slot placement would have been my first thought, otherwise,
> I can't think of anything particularly likely.
>
>
>        Stefan
>