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, 23 Sep 2009 11:41:27 -0400 Message-ID: <5e3a506e0909230841i1d87b7ep397f2809e2cbdef9@mail.gmail.com> References: <5e3a506e0909101709u2259d56h25f3ef1ec67326aa@mail.gmail.com> <5e3a506e0909101902h72747299u2e306830ce63b11d@mail.gmail.com> <5e3a506e0909102108h381957cahfcaa681baa4abf@mail.gmail.com> <5e3a506e0909130947m1669cda0y25d13a5e8dcd85df@mail.gmail.com> <5e3a506e0909140810r38a83a84l387fb6bafeb962c1@mail.gmail.com> <5e3a506e0909161346w1d5a8bebp84f1d51f0f446f28@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd296de4cd85d0474408cbb X-Trace: ger.gmane.org 1253720667 25606 80.91.229.12 (23 Sep 2009 15:44:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Sep 2009 15:44:27 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Sep 23 17:44:19 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 1MqU0j-00025n-9T for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2009 17:44:05 +0200 Original-Received: from localhost ([127.0.0.1]:41784 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqU0i-0006YM-NY for ged-emacs-devel@m.gmane.org; Wed, 23 Sep 2009 11:44:04 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MqTyJ-0004vS-9n for emacs-devel@gnu.org; Wed, 23 Sep 2009 11:41:35 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MqTyE-0004tA-GM for emacs-devel@gnu.org; Wed, 23 Sep 2009 11:41:34 -0400 Original-Received: from [199.232.76.173] (port=51662 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MqTyE-0004t5-7Y for emacs-devel@gnu.org; Wed, 23 Sep 2009 11:41:30 -0400 Original-Received: from mail-px0-f202.google.com ([209.85.216.202]:52448) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MqTyD-0002Is-KH for emacs-devel@gnu.org; Wed, 23 Sep 2009 11:41:29 -0400 Original-Received: by pxi40 with SMTP id 40so678104pxi.24 for ; Wed, 23 Sep 2009 08:41:27 -0700 (PDT) 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=aLgDRiXHl8OZqrO0K/H+BTIiC4dwRK4lTgXzPALQfIU=; b=SCOEimWk446rXZ99o4fpP+ZT7dhUKna7rObQiO/52SpkoDfO/nS0bRn4/JXnJEmb3k zY/iXZnNp6dxcZNlIsY2i7mWypFowxHov1nAq+2FclkoXSR098oJvWsTCJpSu/Yj1ts0 efzKlh4tlMp0niTyEA3pmGLGg7fNICGkp3WPI= 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=w0y6u4pU8dAx1HiE+yy+JJ7HB+sa7+c2A8xd2Pz1OBQSHkwb/EI16fLhfhNvrKdGA0 LKfr78kk/GTJDN7leflAkxDjdiS2Cbz6tBXMtCG8Ew4wNcFaG8cCyUbgAzbmD63CdiSY YZTXhxT0lkE5ycth55CR34riM1eBATlVbmZ9Q= Original-Received: by 10.140.170.5 with SMTP id s5mr147398rve.6.1253720487417; Wed, 23 Sep 2009 08:41:27 -0700 (PDT) In-Reply-To: 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:115550 Archived-At: --000e0cd296de4cd85d0474408cbb Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 16, 2009 at 9:05 PM, Stefan Monnier 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 --000e0cd296de4cd85d0474408cbb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Sep 16, 2009 at 9:05 PM, Stefan = Monnier <m= onnier@iro.umontreal.ca> wrote:
> I wrote a patch to add point-left and point-entered = to overlays. =A0I ended up
> adding the implementation in command_loop_1. =A0The patch is attached = - let me
> know if anything needs to be fixed.

It looks like a good starting point. =A0Here are some comments, based= on
a cursory examination of your patch:
- since the semantics are fundamentally very different from the ones of
=A0the point-left and point-entered text properties, this new feature
=A0should use other property names. =A0I also expect it's simpler to u= se
=A0a single property, which is called both when entering and
=A0when leaving (like the modification-hooks property).
- a corollary is that this new feature should also be implemented for
=A0text properties.
- the function you patch is already overly long, so better move the new
=A0code in a new function.
- you use last_point_position without checking whether it applied to the =A0same buffer as the current one (i.e. you don't pay attention to
=A0prev_buffer).
- you don't take into account the fact that the buffer may have been =A0changed since the beginning of the command, so last_point_position
=A0(which is an int rather than a marker) may not point to the right
=A0place any more.
- similarly overlays may have been added/moved/deleted, so your check
=A0for "overlays at last_point_position" may find overlays which= in
=A0reality were not there when last_point_position was recorded (or may =A0fail to find the overlay(s) that were there).
- it doesn't seem easy/possible for the user to control whether a given=
=A0overlay boundary is considered to be "inside" or "outsid= e".

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'. =A0This property is called whene= ver
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). =A0The 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). =A0The 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. =A0IOW, this would work well for text properties, but not so
well for overlays.


=A0 =A0 =A0 =A0Stefan
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.=A0 Would it be better to store overlays at point at the end of this loop, and use this instead of looking up old points?=A0 This would also require storing the new propertu of the text at the current-location.=A0 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
--000e0cd296de4cd85d0474408cbb--