From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Nathaniel Flath Newsgroups: gmane.emacs.devel Subject: Re: Overalays and point-entered Date: Wed, 9 Dec 2009 18:41:17 -0500 Message-ID: <5e3a506e0912091541v71f7c4ebq6daf0bcac2ddccd2@mail.gmail.com> References: <5e3a506e0909101709u2259d56h25f3ef1ec67326aa@mail.gmail.com> <5e3a506e0910212035y7d5eca50w7ae1005896ef1bdd@mail.gmail.com> <5e3a506e0910230843r3fb837e7v9aa9cf5e57a7aed@mail.gmail.com> <5e3a506e0910270142y799d80dm7c4ebda24e31556@mail.gmail.com> <87aazcfiud.fsf@catnip.gol.com> <5e3a506e0910311003g1a16874em8e51baed60099a48@mail.gmail.com> <5e3a506e0911060654w6220a69j9e2af2b6988a4c5f@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd509c619bb33047a543a88 X-Trace: ger.gmane.org 1260402102 13377 80.91.229.12 (9 Dec 2009 23:41:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 9 Dec 2009 23:41:42 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Miles Bader Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 10 00:41:35 2009 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1NIWA2-0003ZX-Im for ged-emacs-devel@m.gmane.org; Thu, 10 Dec 2009 00:41:35 +0100 Original-Received: from localhost ([127.0.0.1]:32796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIWA1-0003pU-VI for ged-emacs-devel@m.gmane.org; Wed, 09 Dec 2009 18:41:33 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NIW9u-0003nz-KI for emacs-devel@gnu.org; Wed, 09 Dec 2009 18:41:26 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NIW9p-0003jg-9U for emacs-devel@gnu.org; Wed, 09 Dec 2009 18:41:25 -0500 Original-Received: from [199.232.76.173] (port=32993 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NIW9p-0003jX-3X for emacs-devel@gnu.org; Wed, 09 Dec 2009 18:41:21 -0500 Original-Received: from mail-px0-f183.google.com ([209.85.216.183]:41351) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NIW9n-0004rd-2K; Wed, 09 Dec 2009 18:41:19 -0500 Original-Received: by pxi13 with SMTP id 13so4149252pxi.24 for ; Wed, 09 Dec 2009 15:41:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=AvugX3y/FlbNnaGWRNI47n+zbZebp9A6B7t0Ua2mZGs=; b=oZP6nh4FRJtQ2fnGXgXaTXu6Ml2y8PMOzQc0XR8RlJKdpT0ZpoUIbAINphwwX3GJwT zZ+LuoOg3OTkd9c3iqdRIXuO8VE5DPlLF1YkAIs5iVPbkcXbxlj45O902lsyrelEuSYq TS9gpJ9neZqO5yk+DkP8dKCRiw89EfZKEakWM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=pesq0QDfCo4ODwNdp4b0Z9PHjNRh+wTxz6oUmNHseGTLrN8mQPLwXoYEvggtc2e8jI LixTCU+paXfPKQe7UDGIwKQxppOHx1Hhx6UqkXA32nCj1kfFlHIMK5N6TKCPJeDp3xcr /1LzQEJvs/si045DSSSkRUWpbY9xmSAU/wt5U= Original-Received: by 10.141.91.10 with SMTP id t10mr657451rvl.3.1260402077448; Wed, 09 Dec 2009 15:41:17 -0800 (PST) In-Reply-To: <5e3a506e0911060654w6220a69j9e2af2b6988a4c5f@mail.gmail.com> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:118501 Archived-At: --000e0cd509c619bb33047a543a88 Content-Type: text/plain; charset=ISO-8859-1 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." >>> >> >> > --000e0cd509c619bb33047a543a88 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable So after having my motherboard fried and having to finish projects, I final= ly had enough time to look at this again.=A0 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=A0 solution I have for the problem we were discussing is to= have both buffers and windows have a list of overlays that had text proper= ties with 'point-motion at the last point position.=A0 The value of = 9;point-motion is a function that takes prev-pt-position, current-pt-positi= on,=A0 the overlay/text property the function belongs to, the buffer that w= as active last time run_point_motion_hooks was called, the previous window,= and whether the hook 'belongs' to a buffer or a window.=A0 This is= getting a bit cumbersome, but also lets the writer of the hook specify exa= ctly the behavior they want.=A0 The hooks for the current buffer, previous = buffer, current window, and previous window are all run.=A0 I'm working= on the patch for this - I'll send it on when I'm finished, which w= ill probably be later today.=A0 Does this sound like a good approach, or do= you have some other suggestion?

Thanks,
Nathaniel Flath

On Fri, No= v 6, 2009 at 9:54 AM, Nathaniel Flath <flat0103@gmail.com> wrote:
I started working on this - attached is a patch that will run hooks in poin= t-motion only when movement occurs inside the same buffer and window.=A0 I&= #39;ll work on buffer-change-motion-hook a bit later.=A0 Let me know if the= re's any issues.

Thanks,
Nathaniel Flath


On Sat, Oct 31, 2009= at 12:03 PM, Nathaniel Flath <flat0103@gmail.com> wrote:
This may be a good solution.=A0 What are your thoughts, Stefan?

Nathaniel


On Tue, Oct 27, 2009 at 8:44 PM, Miles Bader <miles@gnu.org> wrote:
Stefan Monni= er <monnie= r@iro.umontreal.ca> 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 sho= uld
> run the hook (which is a vote in favor of per-window data), but for &q= uot;C-x
> o" it's less clear: running the hook would often be a good id= ea, 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 amon= g 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
=A0'Allahu akbar!' are, in spirit, not actually all that different.= "



--000e0cd509c619bb33047a543a88--