From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [ELPA] New package proposal: visual-path-abbrev.el Date: Fri, 08 Mar 2019 14:01:56 -0500 Message-ID: References: <87tvglpmcx.fsf@gnu.org> <83k1hhh5mb.fsf@gnu.org> <874l8k47fi.fsf@gnu.org> <83imx0f0x0.fsf@gnu.org> <87k1hg6jl3.fsf@gnu.org> <83h8ciecub.fsf@gnu.org> <8736o1iqsf.fsf@gnu.org> <87zhq51n1q.fsf@gnu.org> <875zstz2wc.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="214200"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Mar 08 20:02:05 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1h2Kku-000td6-O5 for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 20:02:04 +0100 Original-Received: from localhost ([127.0.0.1]:48618 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Kkt-00034k-Lj for ged-emacs-devel@m.gmane.org; Fri, 08 Mar 2019 14:02:03 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:57704) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Kko-00034f-VY for emacs-devel@gnu.org; Fri, 08 Mar 2019 14:01:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h2Kko-0003wU-6I for emacs-devel@gnu.org; Fri, 08 Mar 2019 14:01:58 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:39688) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h2Kkn-0003vr-WD for emacs-devel@gnu.org; Fri, 08 Mar 2019 14:01:58 -0500 Original-Received: from pastel.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id x28J1uWj029800; Fri, 8 Mar 2019 14:01:56 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 699CC6A478; Fri, 8 Mar 2019 14:01:56 -0500 (EST) In-Reply-To: <875zstz2wc.fsf@gnu.org> (Tassilo Horn's message of "Fri, 08 Mar 2019 18:34:11 +0100") X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 2 Rules triggered EDT_SA_DN_PASS=0, RV6499=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6499> : inlines <7030> : streams <1815134> : uri <2809122> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233937 Archived-At: > Ok, now after the hymn of praise, here's the caveat which I couldn't > solve so far: When point leaves one of my overlays and immediately > appears in another one, the `cursor-sensor-functions' are NOT CALLED. > Of course, I expected to get a one call with 'left followed by a call > with 'entered. IIRC you should indeed get 2 calls (one for leave and one for enter), unless the overlays are adjacent I think (the code looks at char-properties so doesn't pay much attention to overlay boundaries themselves). > Can we consider that a bug in cursor-sensor or is that the expected > behavior? And more importantly, can I influence it so that it works for > my use-case? Not sure if it's a bug, but if the problem is that your overlays are adjacent (so that all the chars between the old and the new positions have the same `cursor-sensor-functions` property), then you can fix it in one of two ways: - change your overlay's boundaries so as to leave some chars between the overlays. - use artificially non-eql values of the functions placed on `cursor-sensor-functions` (e.g. using closures that close over the overlay itself). > An easy recipe for reproduction is to run M-x rgrep, then activate my > mode in the *grep* buffer, and then move up and down using C-p / C-n. Haven't tried it yet, but it sounds like maybe it's just a plain bug in cursor-sensor. Stefan