From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords: evaluating arbitrary elisp inside matchers? Date: Fri, 28 Sep 2012 08:28:07 -0400 Message-ID: References: <505CD2A0.1090906@gmail.com> <5061960C.7050106@gmail.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1348835302 14306 80.91.229.3 (28 Sep 2012 12:28:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Sep 2012 12:28:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: immerrr again Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 28 14:28:27 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1THZgB-00060c-MX for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 14:28:27 +0200 Original-Received: from localhost ([::1]:42840 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THZg6-00039I-Ft for ged-emacs-devel@m.gmane.org; Fri, 28 Sep 2012 08:28:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:52747) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THZfz-00038u-QR for emacs-devel@gnu.org; Fri, 28 Sep 2012 08:28:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1THZft-0003zV-Jm for emacs-devel@gnu.org; Fri, 28 Sep 2012 08:28:15 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:2885) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1THZft-0003zH-Fx for emacs-devel@gnu.org; Fri, 28 Sep 2012 08:28:09 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09FxLT4/2dsb2JhbABEtBGBCIIVAQEEAVYjBQsLNBIUGA0kiBwFugmQRAOjM4FYgwU X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="200202390" Original-Received: from 69-196-180-248.dsl.teksavvy.com (HELO pastel.home) ([69.196.180.248]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 28 Sep 2012 08:28:08 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id F22A759468; Fri, 28 Sep 2012 08:28:07 -0400 (EDT) In-Reply-To: (immerrr again's message of "Fri, 28 Sep 2012 12:19:56 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:153672 Archived-At: > Hold on, do I understand procedure correctly in the following > situation: suppose, we're propertizing an arbitrary buffer region, big > enough not to be matched in single attempt; suppose, first match region - > from `begin1' to `end1' - contains exactly one opening long bracket and its > long bracket of the same level is located beyond `end1' point, and there's > no other opening long bracket in between. Am I right that the next match > invocation will operate on region starting from `end1 + 1'? Yes. > If yes, then unless there's a rule that can match closing long > brackets, the closing long bracket won't be found and thus won't be > propertized, or will it? There is such a rule: the definition of lua-syntax-propertize begins by calling lua-syntax-propertize-string-or-comment-end which: and then in lua-syntax-propertize-string-or-comment I'd use syntax-ppss to check the parser state (i.e. determine if I'm in a type-b comment or delimited-string corresponding to a long-bracket construct as opposed to some type-a comment or standard string, or plain old code), and if I'm in one of those long-bracket-constructs, use (nth 8 ppss) to find the beginning, count the number of = used there, then search for the matching ]==] pattern and place the matching "> b" or "|" syntax on the second closing bracket. so while the second call is for "end1+1 ... end2", your code will go back to the beginning of the long bracket to figure out its end and then look for that end again (which might show up before end2 this time, tho maybe not). -- Stefan