From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: html, css, and js modes working together Date: Sun, 12 Feb 2017 12:14:28 -0500 Message-ID: References: <87o9ynarz3.fsf@tromey.com> <877f4z6i8n.fsf@tromey.com> <87poipzr0l.fsf@tromey.com> <87inog4oga.fsf@tromey.com> <87k28w2hm4.fsf@tromey.com> <58A043A3.6060206@gmx.at> <83fujj2yau.fsf@gnu.org> <87vasf1i9z.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1486919684 13481 195.159.176.226 (12 Feb 2017 17:14:44 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 12 Feb 2017 17:14:44 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: martin rudalics , Eli Zaretskii , emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 12 18:14:36 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ccxjQ-00037O-Iq for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 18:14:36 +0100 Original-Received: from localhost ([::1]:52824 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccxjW-0002pT-9H for ged-emacs-devel@m.gmane.org; Sun, 12 Feb 2017 12:14:42 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33380) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ccxjP-0002oR-Q6 for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:14:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ccxjO-00064t-LY for emacs-devel@gnu.org; Sun, 12 Feb 2017 12:14:35 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:12322) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1ccxjK-00064C-Qx; Sun, 12 Feb 2017 12:14:30 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLNBIUGA0kiHoIrRSLRAEBAQcCJYsZiikFj3yKapMJiBGGOodgii82IHgTDoVzIIktAQEB X-IPAS-Result: A0AbKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLNBIUGA0kiHoIrRSLRAEBAQcCJYsZiikFj3yKapMJiBGGOodgii82IHgTDoVzIIktAQEB X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="292710310" Original-Received: from 45-72-235-254.cpe.teksavvy.com (HELO ceviche.home) ([45.72.235.254]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Feb 2017 12:14:30 -0500 Original-Received: by ceviche.home (Postfix, from userid 20848) id 40D756629F; Sun, 12 Feb 2017 12:14:28 -0500 (EST) In-Reply-To: <87vasf1i9z.fsf@tromey.com> (Tom Tromey's message of "Sun, 12 Feb 2017 09:32:56 -0700") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:212294 Archived-At: > If that's the case, then it seems to me that cursor-sensor-functions > should be run in the scenario I described -- because in that scenario, > point does change. I think what you want is to run commands in a context that depends on point. In that case I think that pre-command-hook sounds like the better option (and no, it's definitely not particularly expensive: it's run less often than the cursor-sensor--detect used internally by cursor-sensor-mode). As to whether cursor-sensor-functions would be more or less useful if it were defined to react on movement of the "buffer cursor" rather than the "window cursor". You might be right. I truly don't know. Many uses of such "position sensitivity" should ideally be "per window", IMO, which is why I implemented it this way, but at the same time, many users of that feature then go on and change buffer state (often with not much other choice) rather than window state. E.g. table.el uses cursor-sensor-functions to detect when we're inside a table and update the mode-line lighter accordingly. But that currently breaks when we have several windows showing the same buffer because its lighter's state is define per-buffer rather than per-window. Stefan