On Wed, Sep 16, 2009 at 9:05 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > I wrote a patch to add point-left and point-entered to overlays.  I ended
> up
> > adding the implementation in command_loop_1.  The patch is attached - let
> me
> > know if anything needs to be fixed.
>
> It looks like a good starting point.  Here are some comments, based on
> a cursory examination of your patch:
> - since the semantics are fundamentally very different from the ones of
>  the point-left and point-entered text properties, this new feature
>  should use other property names.  I also expect it's simpler to use
>  a single property, which is called both when entering and
>  when leaving (like the modification-hooks property).
> - a corollary is that this new feature should also be implemented for
>  text properties.
> - the function you patch is already overly long, so better move the new
>  code in a new function.
> - you use last_point_position without checking whether it applied to the
>  same buffer as the current one (i.e. you don't pay attention to
>  prev_buffer).
> - you don't take into account the fact that the buffer may have been
>  changed since the beginning of the command, so last_point_position
>  (which is an int rather than a marker) may not point to the right
>  place any more.
> - similarly overlays may have been added/moved/deleted, so your check
>  for "overlays at last_point_position" may find overlays which in
>  reality were not there when last_point_position was recorded (or may
>  fail to find the overlay(s) that were there).
> - it doesn't seem easy/possible for the user to control whether a given
>  overlay boundary is considered to be "inside" or "outside".
>
> I think an approach that may solve most of the above problems and yet be
> somewhat simple to implement could be the following:
> use a new property `motion-functions'.  This property is called whenever
> a command ends with point at a place where the property is different
> (i.e. you compare the value of the property before the command to the
> value of the property after the command).  The comparison is made with
> `eq' (since the property contains a list, is should be easy for elisp
> authors to make it do the right thing by simply avoiding reusing the
> same list, and constructing a new one instead).  The property is looked
> up with get_pos_property, so it automatically works for overlays as well
> as text properties, and also provides ways to control what happens at
> the boundaries (whether the position at the end/beginning of an
> overlays is "inside" or "outside"
>
> One problem with this approach is that if you have several overlays at
> the same place with a `motion-functions' property, they'll end up
> fighting each other and only one of them will work, which is kind of
> a bummer.  IOW, this would work well for text properties, but not so
> well for overlays.
>
>
>        Stefan
>
Since the main point I was implementing this was so I could add these
properties to overlay, I'd prefer a solution that works better with them.
Would it be better to store overlays at point at the end of this loop, and
use this instead of looking up old points?  This would also require storing
the new propertu of the text at the current-location.  To solve the
boundary-control issue, I could look at get-pos-property and use the same
mechanism it does for controlling boundary behaviour.

Thanks for the feedback, and sorry it took me so long to respond- I just got
back to school and had a few reports I needed to write.

Thanks,
Nathaniel Flath