From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Nathaniel Flath <flat0103@gmail.com>
Cc: emacs-devel@gnu.org
Subject: Re: Overalays and point-entered
Date: Wed, 16 Sep 2009 21:05:32 -0400 [thread overview]
Message-ID: <jwv7hvyh1qh.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <5e3a506e0909161346w1d5a8bebp84f1d51f0f446f28@mail.gmail.com> (Nathaniel Flath's message of "Wed, 16 Sep 2009 16:46:33 -0400")
> 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
next prev parent reply other threads:[~2009-09-17 1:05 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-09-11 0:09 Overalays and point-entered Nathaniel Flath
2009-09-11 1:57 ` Stefan Monnier
[not found] ` <5e3a506e0909101902h72747299u2e306830ce63b11d@mail.gmail.com>
[not found] ` <jwvmy52p4re.fsf-monnier+emacs@gnu.org>
2009-09-11 4:08 ` Nathaniel Flath
2009-09-13 16:47 ` Nathaniel Flath
2009-09-14 1:16 ` Stefan Monnier
[not found] ` <5e3a506e0909140810r38a83a84l387fb6bafeb962c1@mail.gmail.com>
[not found] ` <jwvzl8x49un.fsf-monnier+emacs@gnu.org>
2009-09-16 20:46 ` Nathaniel Flath
2009-09-17 1:05 ` Stefan Monnier [this message]
2009-09-23 15:41 ` Nathaniel Flath
2009-09-23 20:55 ` Stefan Monnier
2009-09-24 1:07 ` Stephen J. Turnbull
2009-09-24 14:31 ` Overlays " Stefan Monnier
2009-09-24 13:47 ` Overalays " Nathaniel Flath
2009-09-24 14:04 ` Nathaniel Flath
2009-09-24 14:26 ` Stefan Monnier
2009-10-06 18:33 ` Nathaniel Flath
2009-10-17 17:00 ` Nathaniel Flath
2009-10-18 1:09 ` Stefan Monnier
2009-10-22 3:35 ` Nathaniel Flath
2009-10-22 15:37 ` Stefan Monnier
2009-10-23 15:43 ` Nathaniel Flath
2009-10-25 2:30 ` Stefan Monnier
2009-10-27 8:42 ` Nathaniel Flath
2009-10-27 13:28 ` Stefan Monnier
2009-10-28 0:44 ` Miles Bader
2009-10-31 17:03 ` Nathaniel Flath
2009-11-06 14:54 ` Nathaniel Flath
2009-12-09 23:41 ` Nathaniel Flath
2009-12-10 3:37 ` Nathaniel Flath
2009-12-10 8:32 ` Stefan Monnier
2009-12-20 23:39 ` Nathaniel Flath
2010-01-02 3:34 ` Nathaniel Flath
2010-01-08 7:19 ` Nathaniel Flath
2010-01-15 2:38 ` Stefan Monnier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv7hvyh1qh.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=flat0103@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).