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, 21 Oct 2009 23:35:09 -0400 Message-ID: <5e3a506e0910212035y7d5eca50w7ae1005896ef1bdd@mail.gmail.com> References: <5e3a506e0909101709u2259d56h25f3ef1ec67326aa@mail.gmail.com> <5e3a506e0909230841i1d87b7ep397f2809e2cbdef9@mail.gmail.com> <5e3a506e0909240647k18368e10o6e5391a70a79e8@mail.gmail.com> <5e3a506e0909240704t5e716634k86b21e1604ee1912@mail.gmail.com> <5e3a506e0910061133r3e9b6146l637c84bee7b0d136@mail.gmail.com> <5e3a506e0910171000n79e9c992n6c243fc0f42a919a@mail.gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=000e0cd299983f17af04767dc8ce X-Trace: ger.gmane.org 1256182542 8983 80.91.229.12 (22 Oct 2009 03:35:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 22 Oct 2009 03:35:42 +0000 (UTC) To: Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Oct 22 05:35:31 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 1N0oSY-0007OB-On for ged-emacs-devel@m.gmane.org; Thu, 22 Oct 2009 05:35:31 +0200 Original-Received: from localhost ([127.0.0.1]:47944 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0oSY-0006vW-3x for ged-emacs-devel@m.gmane.org; Wed, 21 Oct 2009 23:35:30 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1N0oSM-0006oc-AV for emacs-devel@gnu.org; Wed, 21 Oct 2009 23:35:18 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1N0oSH-0006ks-Bg for emacs-devel@gnu.org; Wed, 21 Oct 2009 23:35:17 -0400 Original-Received: from [199.232.76.173] (port=33656 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1N0oSH-0006kj-6P for emacs-devel@gnu.org; Wed, 21 Oct 2009 23:35:13 -0400 Original-Received: from mail-pz0-f181.google.com ([209.85.222.181]:37233) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1N0oSG-0007xS-MQ for emacs-devel@gnu.org; Wed, 21 Oct 2009 23:35:12 -0400 Original-Received: by pzk11 with SMTP id 11so5213623pzk.14 for ; Wed, 21 Oct 2009 20:35:11 -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=2RkG00xoKWqAOU8J+icBpMGex84bLCl6Xy/rlG5IrMw=; b=RLyOPKCUwDyNCNOSXJKof/9s63yA0b4pclXAWyD1L+FQ2OUuB4cXxG4yzpp5104V5a xqhok43IEJ+trasRFiNwVy+UhvaQF+MGxVd3fQ6P9MkJ19wnpeuY/pnohZmaNi/fa2Id wXGh45qPeSKjDtmqaWIwlSBWYE3lDtNtvIbF0= 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=n4TDiL8cGtcO16sf5f0lAN9mMr+5IHNdzKLl8gpCa46QSRjCSy2zqzreIZY2OWIMXZ a21b+ls39fU0BQZ0KZiPAbVP4wE2JhZbB9lZL95EimJv/BOhGQvkmS3i0GQpaUJFaniC 0nldxwWw2uxb07+mO0p6cXxjFPZ3shfLMtFyM= Original-Received: by 10.140.202.9 with SMTP id z9mr1682984rvf.30.1256182509409; Wed, 21 Oct 2009 20:35:09 -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:116302 Archived-At: --000e0cd299983f17af04767dc8ce Content-Type: text/plain; charset=ISO-8859-1 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. 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 last few lines produced by running make were: LC_ALL=C `/bin/pwd`/temacs -batch -l loadup dump Segmentation fault make: *** [emacs] Error 139 Thanks, Nathaniel Flath On Sat, Oct 17, 2009 at 9:09 PM, Stefan Monnier wrote: > > Any comments ont his? > > I haven't had much time to look into it, but I wonder: what happens when > you switch buffer? > > I get the impression that your code currently will consider > a buffer-switch as a kind of cursor movement to "very far away" (so it > will run the leave&enter hooks). I think it would be better to keep > track of overlay_prev_vec as a per-buffer (or probably better > per-window, tho that again introduces some questions when > a window-buffer is changed) information. > > > Stefan > --000e0cd299983f17af04767dc8ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 neces= sary properties( overlay_prev_vec, noverlays_prev, prev_point_motion_hook )= in the structure caused the 'make' process to return a segfault.= =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 implementation strategy that = wouldn't run into this problem?=A0 I followed the instructions about pl= acing non-Lisp_Objects above the 'name' variable, so that is most l= ikely not the issue.

The last few lines produced by running make were:

LC_ALL=3DC `/b= in/pwd`/temacs -batch -l loadup dump
Segmentation fault
make: *** [em= acs] Error 139

Thanks,
Nathaniel Flath

On Sat, Oct 17, 2009 at 9:09 PM, Stefan Monnier <monnier@iro.umontr= eal.ca> wrote:
> Any comments ont his?

I haven't had much time to look into it, but I wonder: what happens whe= n
you switch buffer?

I get the impression that your code currently will consider
a buffer-switch as a kind of cursor movement to "very far away" (= so it
will run the leave&enter hooks). =A0I think it would be better to keep<= br> track of overlay_prev_vec as a per-buffer (or probably better
per-window, tho that again introduces some questions when
a window-buffer is changed) information.


=A0 =A0 =A0 =A0Stefan

--000e0cd299983f17af04767dc8ce--