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, 23 Oct 2009 11:43:10 -0400 Message-ID: <5e3a506e0910230843r3fb837e7v9aa9cf5e57a7aed@mail.gmail.com> References: <5e3a506e0909101709u2259d56h25f3ef1ec67326aa@mail.gmail.com> <5e3a506e0909240647k18368e10o6e5391a70a79e8@mail.gmail.com> <5e3a506e0909240704t5e716634k86b21e1604ee1912@mail.gmail.com> <5e3a506e0910061133r3e9b6146l637c84bee7b0d136@mail.gmail.com> <5e3a506e0910171000n79e9c992n6c243fc0f42a919a@mail.gmail.com> <5e3a506e0910212035y7d5eca50w7ae1005896ef1bdd@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd22950a86d4b04769c117b X-Trace: ger.gmane.org 1256312612 29171 80.91.229.12 (23 Oct 2009 15:43:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 23 Oct 2009 15:43:32 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Oct 23 17:43:25 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 1N1MIU-0002JX-Gc for ged-emacs-devel@m.gmane.org; Fri, 23 Oct 2009 17:43:22 +0200 Original-Received: from localhost ([127.0.0.1]:51316 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N1MIU-0007Nu-0r for ged-emacs-devel@m.gmane.org; Fri, 23 Oct 2009 11:43:22 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N1MIP-0007Nm-8W for emacs-devel@gnu.org; Fri, 23 Oct 2009 11:43:17 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N1MIK-0007LW-7P for emacs-devel@gnu.org; Fri, 23 Oct 2009 11:43:16 -0400 Original-Received: from [199.232.76.173] (port=35381 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N1MIK-0007LS-4M for emacs-devel@gnu.org; Fri, 23 Oct 2009 11:43:12 -0400 Original-Received: from mail-px0-f192.google.com ([209.85.216.192]:61962) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N1MIJ-0003Z4-El for emacs-devel@gnu.org; Fri, 23 Oct 2009 11:43:11 -0400 Original-Received: by pxi30 with SMTP id 30so2062193pxi.14 for ; Fri, 23 Oct 2009 08:43:10 -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:content-type; bh=3AYHieuoOKe/QjR8pphQmZrzfF2ZfDz95p9aA+reuLI=; b=PD+TNMWR1wfKwxRxw2/+kbNCWMs7NrH3mlHmOqtWRLTZVRy7b6rdECcojS8vUYyLjK KO9UPJMB6O31EqyO9HKS04xwZyfp5TcHHhXVjx5fJC30iPtQhY79q7sjqgONok/7BB4o tKOmbCgJD1FOazhEg+TFLpRy2UJW3F/kVzfWo= 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 :content-type; b=niSANl1S3glbD0wschGo7zvwQXuKqbENWs4LT4rVEDpDnmBm+QKQgxAFZeuVVI4hoL 7HE3XodWxFiZ1wF7uWEV6eUXyLEZGHUPmGjLLbNgn22EoXX22McB4c+FRdPO0q6gk4dC m4cMiNsc8FB15P93vkx+oiqM0lNKb4+iKPoHo= Original-Received: by 10.140.143.19 with SMTP id q19mr1849813rvd.17.1256312590068; Fri, 23 Oct 2009 08:43:10 -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:116332 Archived-At: --000e0cd22950a86d4b04769c117b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Oct 22, 2009 at 11:37 AM, Stefan Monnier wrote: > > 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". > > I believe this is correct. > 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). > The use case I was looking at, as I mentioned earlier, was for flymake-like modes to display the actual error messages when point is on an error line. This currently looks like it's usually implemented( or is in js2.el, at least ) by having both an overlay and a text property and keeping the two in sync. In this case, I think that doing C-x o to the same buffer should run the hooks, and that C-x b should not, which would imply that maybe the buffer is the best place to put them. > > > 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 > --000e0cd22950a86d4b04769c117b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Thu, Oct 22, 2009 at 11:37 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
> 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<= br> > necessary properties( overlay_prev_vec, noverlays_prev,
> prev_point_motion_hook ) in the structure caused the 'make' pr= ocess to
> return a segfault.

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

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

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


I believe this is correct.
=A0
Whenm thinking about it, it's best to try and think of concrete example= s
which would use this feature. =A0And keep in mind that it's usually bet= ter
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).


The use case I was looking at= , as I mentioned earlier, was for flymake-like modes to display the actual = error messages when point is on an error line.=A0 This currently looks like= it's usually implemented( or is in js2.el, at least ) by having both a= n overlay and a text property and keeping the two in sync.=A0 In this case,= I think that doing C-x o to the same buffer should run the hooks, and that= C-x b should not, which would imply that maybe the buffer is the best plac= e to put them.
=A0

> 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 implementati= on
> strategy that wouldn't run into this problem? =A0I followed the in= structions
> about placing non-Lisp_Objects above the 'name' variable, so t= hat is most
> likely not the issue.

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


=A0 =A0 =A0 =A0Stefan

--000e0cd22950a86d4b04769c117b--