The patch is attached - please let me know if you have any comments. Thanks, Nathaniel Flath On Wed, Dec 9, 2009 at 6:41 PM, Nathaniel Flath wrote: > So after having my motherboard fried and having to finish projects, I > finally had enough time to look at this again. I've bene paying attention > to this list, so I realize that the feature freeze is in effect, but if it's > possible to discuss this now so that the next time trunk is unfrozen it can > be put in I'd like to do that. > > The current solution I have for the problem we were discussing is to have > both buffers and windows have a list of overlays that had text properties > with 'point-motion at the last point position. The value of 'point-motion > is a function that takes prev-pt-position, current-pt-position, the > overlay/text property the function belongs to, the buffer that was active > last time run_point_motion_hooks was called, the previous window, and > whether the hook 'belongs' to a buffer or a window. This is getting a bit > cumbersome, but also lets the writer of the hook specify exactly the > behavior they want. The hooks for the current buffer, previous buffer, > current window, and previous window are all run. I'm working on the patch > for this - I'll send it on when I'm finished, which will probably be later > today. Does this sound like a good approach, or do you have some other > suggestion? > > Thanks, > Nathaniel Flath > > > On Fri, Nov 6, 2009 at 9:54 AM, Nathaniel Flath wrote: > >> I started working on this - attached is a patch that will run hooks in >> point-motion only when movement occurs inside the same buffer and window. >> I'll work on buffer-change-motion-hook a bit later. Let me know if there's >> any issues. >> >> Thanks, >> Nathaniel Flath >> >> >> On Sat, Oct 31, 2009 at 12:03 PM, Nathaniel Flath wrote: >> >>> This may be a good solution. What are your thoughts, Stefan? >>> >>> Nathaniel >>> >>> >>> On Tue, Oct 27, 2009 at 8:44 PM, Miles Bader wrote: >>> >>>> Stefan Monnier writes: >>>> > Now, what the behavior should be upon C-x o or C-x b is again somewhat >>>> > unclear: for C-x b, actually I think it's pretty clear that it should >>>> > run the hook (which is a vote in favor of per-window data), but for >>>> "C-x >>>> > o" it's less clear: running the hook would often be a good idea, but >>>> > would mean that it's somewhere between difficult and impossible to let >>>> > the user go to the *Completions* buffer to select an entry with >>>> > choose-completion. >>>> >>>> It seems like it would be easier to handle the subtle variations among a >>>> variety of cases if there were simply hooks for each type of movement -- >>>> one which is per-buffer, and only cares about point position, one which >>>> runs when a window becomes selected/deselected (C-x o case), and one >>>> which runs when a buffer is attached/detached from a window (C-x b >>>> case). >>>> >>>> Then the programmer could add hooks to handle which things he cared >>>> about, without having them be inadvertently triggered in cases he >>>> doesn't care about. >>>> >>>> -miles >>>> >>>> -- >>>> "Though they may have different meanings, the cries of 'Yeeeee-haw!' and >>>> 'Allahu akbar!' are, in spirit, not actually all that different." >>>> >>> >>> >> >