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: Tue, 07 Feb 2017 09:33:43 -0500 Message-ID: References: <87o9ynarz3.fsf@tromey.com> <87mvdy7f2g.fsf@tromey.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1486478100 24446 195.159.176.226 (7 Feb 2017 14:35:00 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 7 Feb 2017 14:35:00 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 07 15:34:55 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 1cb6r8-00066b-LP for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 15:34:54 +0100 Original-Received: from localhost ([::1]:54381 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cb6rE-0001Xw-7t for ged-emacs-devel@m.gmane.org; Tue, 07 Feb 2017 09:35:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45995) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cb6q7-0001WF-5l for emacs-devel@gnu.org; Tue, 07 Feb 2017 09:33:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cb6q2-0006SD-6y for emacs-devel@gnu.org; Tue, 07 Feb 2017 09:33:51 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:58073) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1cb6q2-0006R1-0b for emacs-devel@gnu.org; Tue, 07 Feb 2017 09:33:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AbKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLNBIUGA0kiHoIrRSLRAEBCAIlixmKKQWPfIpqmxqGOpIPNiB4Ew4jhVAgiS0BAQE X-IPAS-Result: A0AbKQAu3EVY//7rSC1dGgEBAQECAQEBAQgBAQEBgzgBAQEBAR+EW4VUnAImAZZehhwEAgKCEUQQAQIBAQEBAQEBYiiEaQEEAVYjBQsLNBIUGA0kiHoIrRSLRAEBCAIlixmKKQWPfIpqmxqGOpIPNiB4Ew4jhVAgiS0BAQE X-IronPort-AV: E=Sophos;i="5.33,749,1477972800"; d="scan'208";a="292259950" Original-Received: from 45-72-235-254.cpe.teksavvy.com (HELO pastel.home) ([45.72.235.254]) by smtp.teksavvy.com with ESMTP; 07 Feb 2017 09:33:43 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 21761657D7; Tue, 7 Feb 2017 09:33:43 -0500 (EST) In-Reply-To: <87mvdy7f2g.fsf@tromey.com> (Tom Tromey's message of "Mon, 06 Feb 2017 22:19:51 -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:212091 Archived-At: Stefan> As pointed out by Cl=E9ment, these regexps are a bad idea. Stefan> Better do something like: > This seems reasonable but I don't understand where to check for the end > of the element. Don't I still need a search forward in the > html-syntax-propertize function? Or in your example were you supposing > that this would be done by "html--syntax-propertize-submode"? Yes, html--syntax-propertize-submode would search for the end of the sub-region (only up to `end`, of course), mark the found area with a text-property, and then call the sub-mode's syntax-propertize-function on that area. Stefan> (defun html--get-mode-vars (mode) Stefan> (with-temp-buffer Stefan> (funcall mode) Stefan> (buffer-local-variables))) > Tricky! I looked at the buffer-local-variables here though and there is > a lot of stuff that I think either isn't relevant or is potentially > harmful. So I think for the time being I will stick to a more explicit > approach. Yes, you need to filter out the elements you don't want, or pick the few elements you do want. But I think you're better off manually maintaining a list of relevant variables, than manually maintaining not only which variables are relevant but also the values used by each of the sub-modes (which in turns causes circular dependencies between the packages). Stefan