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: Fri, 1 Jan 2010 22:34:51 -0500 Message-ID: <5e3a506e1001011934n445eaf82ya478f51709ae11f5@mail.gmail.com> References: <5e3a506e0909101709u2259d56h25f3ef1ec67326aa@mail.gmail.com> <5e3a506e0910270142y799d80dm7c4ebda24e31556@mail.gmail.com> <87aazcfiud.fsf@catnip.gol.com> <5e3a506e0910311003g1a16874em8e51baed60099a48@mail.gmail.com> <5e3a506e0911060654w6220a69j9e2af2b6988a4c5f@mail.gmail.com> <5e3a506e0912091541v71f7c4ebq6daf0bcac2ddccd2@mail.gmail.com> <5e3a506e0912091937v4a6ab81egee0529bb9603dfc8@mail.gmail.com> <5e3a506e0912201539p42b7a889v7986f9824df7fbf1@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd0eaeac47414047c262b10 X-Trace: ger.gmane.org 1262403327 13337 80.91.229.12 (2 Jan 2010 03:35:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 2 Jan 2010 03:35:27 +0000 (UTC) Cc: emacs-devel@gnu.org, Miles Bader To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jan 02 04:35:21 2010 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 1NQuls-0001Cq-Fk for ged-emacs-devel@m.gmane.org; Sat, 02 Jan 2010 04:35:20 +0100 Original-Received: from localhost ([127.0.0.1]:46315 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQuls-0001PC-D6 for ged-emacs-devel@m.gmane.org; Fri, 01 Jan 2010 22:35:20 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NQull-0001MG-Me for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:35:13 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NQulh-0001JP-5e for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:35:13 -0500 Original-Received: from [199.232.76.173] (port=43483 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NQulg-0001J1-T6 for emacs-devel@gnu.org; Fri, 01 Jan 2010 22:35:08 -0500 Original-Received: from mail-pw0-f47.google.com ([209.85.160.47]:39973) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NQulf-00070X-2x; Fri, 01 Jan 2010 22:35:07 -0500 Original-Received: by pwj10 with SMTP id 10so1778138pwj.26 for ; Fri, 01 Jan 2010 19:34:51 -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=v313C6rfKKxQ6kyXv3h6G38SQuH28fe7AyypLfMVaE8=; b=lqd0kRRPZxCXXCF054HIhJoBiXLVLDk+XMdV+a+8av6AqfS0dc6fOVDYjPq9f3Fem2 OkMh+BsvZkLa6iGQuRMl0r9u78brEqvPu2a/NmrFYCjjt4ti3AajTtCp/yEHbcVb/tTp aDvesrJJ6rQtenhy3dZsiNb2FzhkRPMFdAQdc= 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=EJJtF1Mq6zJMz6spvGJdg7Tg6gr+/lfPYWDFCokKvQ4dV3Z9803gZNCUjCSxNUgPOo peepPjim2jc2dkd6CFfrl7y95HcM+9PQW8pKJAZN5RHOIR0i5Ezv518wLBqSE8JeAAFa Oh1A81dFvO0ntCh3dxtff6XANYCp6p5SF+qMw= Original-Received: by 10.141.4.9 with SMTP id g9mr14341622rvi.157.1262403291738; Fri, 01 Jan 2010 19:34:51 -0800 (PST) In-Reply-To: <5e3a506e0912201539p42b7a889v7986f9824df7fbf1@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:119248 Archived-At: --000e0cd0eaeac47414047c262b10 Content-Type: text/plain; charset=ISO-8859-1 What is happening with this? Thanks, Nathaniel Flath On Sun, Dec 20, 2009 at 6:39 PM, Nathaniel Flath wrote: > > > On Thu, Dec 10, 2009 at 3:32 AM, Stefan Monnier wrote: > >> > The patch is attached - please let me know if you have any comments. >> >> I'm wondering whether it should be described as complete or complex. >> Especially for a feature which hsan't yet found a user. >> >> > Yes, I didn't think it would be nearly as complex when I started. The > latest revision removes the argument for whether it was called due to a > buffer change; this doesn't seem as necessary when the overlay is only run > once instead of multiple times. > > > > run_point_motion_hooks (prev_c_buffer) > >> >> This seems to run the hooks for all overlays at the starting position >> and all overlays at the ending position. If you add to that the fact >> that it runs them for windows and for the buffer, you get that under the >> usual circumstance of a command within the same buffer displayed in >> a single window, moving within the same overlay we run the hook 4 times? >> >> I think we need to be more careful and only run the hook when crossing >> the boundary, i.e. when moving out of or into an overlay with that >> property. But even if we decide to run it for all movements, we should >> be careful to run it a bit less liberally. It's probably OK to >> occasionally have a few spurious extra runs of the hook, but your >> current code needs to be a lot more careful. >> > > The code has been fixed so that the same overlay or text property should > only run once, and only if a boundary has been crossed. I'm not really sure > whether it should run on all motion; either way would be fairly easy to > implement. > > One more thing: I think the buffer and window object should only store >> the few overlays that do have a point-motion property. Maybe they could >> even limit themselves to storing "the" overlay with a point-motion >> property (if there are several, it should take the one with highest >> priority). >> >> >> > It seemed to be more consistent with the priority mechanism to only store > and run one, so that's what it currently does. The patch with these fixes > is attached; please let me know if there are any other comments. > > Thanks, > Nathaniel Flath > --000e0cd0eaeac47414047c262b10 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable What is happening with this?

Thanks,
Nathaniel Flath

On Sun, Dec 20, 2009 at 6:39 PM, Nathaniel Flath <flat0103@gmail.com<= /a>> wrote:


On Thu, Dec 10, 2009 at 3:32 AM, Stefan= Monnier <monnier@iro.umontreal.ca> wrote:
> The patch is attached - please let me know if you have any commen= ts.

I'm wondering whether it should be described as complete or compl= ex.
Especially for a feature which hsan't yet found a user.


Yes, I didn't think it would be nearly = as complex when I started.=A0=A0 The latest revision removes the argument f= or whether it was called due to a buffer change; this doesn't seem as n= ecessary when the overlay is only run once instead of multiple times.


> run_point_motion_hooks (prev_c_buffer)

This seems to run the hooks for all overlays at the starting position
and all overlays at the ending position. =A0If you add to that the fact
that it runs them for windows and for the buffer, you get that under the usual circumstance of a command within the same buffer displayed in
a single window, moving within the same overlay we run the hook 4 times?
I think we need to be more careful and only run the hook when crossing
the boundary, i.e. when moving out of or into an overlay with that
property. =A0But even if we decide to run it for all movements, we should be careful to run it a bit less liberally. =A0It's probably OK to
occasionally have a few spurious extra runs of the hook, but your
current code needs to be a lot more careful.

=A0The code has been fixed so that the same overlay or text pro= perty should only run once, and only if a boundary has been crossed.=A0 I&#= 39;m not really sure whether it should run on all motion; either way would = be fairly easy to implement.

One more thing: I think the buffer and window object should only= store
the few overlays that do have a point-motion property. =A0Maybe they could<= br> even limit themselves to storing "the" overlay with a point-motio= n
property (if there are several, it should take the one with highest
priority).



It seemed to be more consistent with= the priority mechanism to only store and run one, so that's what it cu= rrently does.=A0=A0 The patch with these fixes is attached; please let me k= now if there are any other comments.

Thanks,
Nathaniel Flath

--000e0cd0eaeac47414047c262b10--