[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Overalays and point-entered

From: Nathaniel Flath
Subject: Re: Overalays and point-entered
Date: Fri, 23 Oct 2009 11:43:10 -0400

On Thu, Oct 22, 2009 at 11:37 AM, Stefan Monnier <address@hidden> 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]