|
From: | Nathaniel Flath |
Subject: | Re: Overalays and point-entered |
Date: | Wed, 9 Dec 2009 22:37:35 -0500 |
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 FlathOn Fri, Nov 6, 2009 at 9:54 AM, Nathaniel Flath <address@hidden> 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 FlathOn Sat, Oct 31, 2009 at 12:03 PM, Nathaniel Flath <address@hidden> wrote:
This may be a good solution. What are your thoughts, Stefan?
NathanielOn Tue, Oct 27, 2009 at 8:44 PM, Miles Bader <address@hidden> wrote:
Stefan Monnier <address@hidden> writes:It seems like it would be easier to handle the subtle variations among a
> 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.
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."
pointmotion.patch
Description: Text Data
[Prev in Thread] | Current Thread | [Next in Thread] |