unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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: Thu, 22 Oct 2009 11:37:58 -0400	[thread overview]
Message-ID: <jwveiovo39y.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <5e3a506e0910212035y7d5eca50w7ae1005896ef1bdd@mail.gmail.com> (Nathaniel Flath's message of "Wed, 21 Oct 2009 23:35:09 -0400")

> I was working to implement your proposed solution - it seemed most logical
> to place overlay_prev_vec in the buffer struct, but placing the three
> necessary properties( overlay_prev_vec, noverlays_prev,
> prev_point_motion_hook ) in the structure caused the 'make' process to
> return a segfault.

That was what I expected, yes.  But the more I think about it, the more
it seems it should be a property linked to a window rather than to
a buffer.  I think this deserves thought first.

- What should happen if the same buffer is shown in the windows and the
  user switches from one to the other?  Should the hooks be run at every
  window-switch, even though no cursor moves?
- What should happen if a buffer is display in a window and then the
  user does C-x b: should the hooks be run?

IIUC, if the data is per-window, then the answers will be "no; yes", if
it's per-buffer, then the answers will be "yes; no".

Whenm thinking about it, it's best to try and think of concrete examples
which would use this feature.  And keep in mind that it's usually better
for a hook to be run too many times than too few times (the code that's
run too many times, can try and detect the extra times and do nothing
in those cases).

> I'm going to look into this more in a few days, but do
> you have any idea why this would be happening, or another implementation
> strategy that wouldn't run into this problem?  I followed the instructions
> about placing non-Lisp_Objects above the 'name' variable, so that is most
> likely not the issue.

The slot placement would have been my first thought, otherwise,
I can't think of anything particularly likely.


        Stefan




  reply	other threads:[~2009-10-22 15:37 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
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 [this message]
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=jwveiovo39y.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).