From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: font-lock-syntactic-keywords obsolet? Date: Wed, 22 Jun 2016 00:06:45 +0300 Message-ID: <660ec8d0-0fdb-189b-6e82-9143b47722eb@yandex.ru> References: <20160619171531.GH5875@acm.fritz.box> <751427e7-f305-7790-99f5-dea230d8e6c4@yandex.ru> <20160620105850.GB3166@acm.fritz.box> <23d7473e-50da-b6dc-17a7-1fec4aad6bfa@yandex.ru> <20160620152535.GB2192@acm.fritz.box> <076b7311-ad16-4913-b0ec-fc73ea4550a1@yandex.ru> <20160620181218.GC2192@acm.fritz.box> <20160620200830.GE2192@acm.fritz.box> <18697155-06d3-2191-6a6b-3ea58e8d17cb@yandex.ru> <20160621144047.GB3177@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1466543485 6712 80.91.229.3 (21 Jun 2016 21:11:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 21 Jun 2016 21:11:25 +0000 (UTC) Cc: Noam Postavsky , emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Jun 21 23:11:25 2016 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 1bFSx3-0003J8-FZ for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2016 23:11:17 +0200 Original-Received: from localhost ([::1]:54281 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFSwx-000590-FF for ged-emacs-devel@m.gmane.org; Tue, 21 Jun 2016 17:11:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFSsn-0000J5-MK for emacs-devel@gnu.org; Tue, 21 Jun 2016 17:06:54 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bFSsj-0000te-LU for emacs-devel@gnu.org; Tue, 21 Jun 2016 17:06:53 -0400 Original-Received: from mail-lf0-x22f.google.com ([2a00:1450:4010:c07::22f]:33759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bFSsj-0000tP-DK for emacs-devel@gnu.org; Tue, 21 Jun 2016 17:06:49 -0400 Original-Received: by mail-lf0-x22f.google.com with SMTP id f6so43419786lfg.0 for ; Tue, 21 Jun 2016 14:06:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=DbWWusOtNwOxuA8dYHw0GBUUF/bDMWuStsXSDT7Rn20=; b=stZqH3zUu0K5Na8j6JTwo48ZS+AWYch+Bxy2Z2450WYlktZ9+wdkR2EB0cxJzc/6HL WGm5GseXvWN65QYHcs1Ejn7WOd7YmBg0dB/fqWoSybls/qjktB0hUEa9AbtzJOcFWZ0Z nc5LKlGze2wKGKwSPEFNsBO+oa/MHL4o72yaGxaDoXT+BZ0weo6Ba2QdRG91YWBcw+3u wHaYfSgHEsTrS72Xg0opNYP+sJ4IEtVyAeoxuLf+RLQTwLX8BhdzF3x/k3ihXTEP2NEh KZJDgU/lum3o7tkFbDERQ3HVQQs6ajJ912neh7SGLeaBj9IdVT+SDc9g+0jLFfR6LGus Hl5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=DbWWusOtNwOxuA8dYHw0GBUUF/bDMWuStsXSDT7Rn20=; b=NZOf3IFXHKzVMPpEiWEuuKPNTb+j9mn7OMTbIzBAOZV6jKNHkfBVjrioH+JT34Noi+ a/A86piXoT3ypj3XfOqlXMpAajF9lD9Ux+B/N5ldqH3Jc14KFDczaxp9/v6Uc1sxMWJi CaylxK9W2tBXXUWKpKEQ2U+ofRySVQxUzxx5Ny0Div2WhZCpiA8F9feX1T9nRNZkJ4Xw 1ilQLUhzkkYIiTvurPdmoIvZpahG2UzaE6+gK7RxwXCj3tdLDEyrFEpPouquWC8QkRMK /55SHTZID1Hy51m0eGqbGvCccgi2U1705fB9jB3du1FEIdAGK5iKnU/5vE39XOmNSGrQ 2C5Q== X-Gm-Message-State: ALyK8tKRnoLD4P5BwJUkD1Hs3YQNLNyGpZV0pjazU2YOyYBCD4UYwdpNiUB/jmRzxxJLmQ== X-Received: by 10.194.246.129 with SMTP id xw1mr21618734wjc.142.1466543208369; Tue, 21 Jun 2016 14:06:48 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.173.135]) by smtp.googlemail.com with ESMTPSA id u6sm70184392wjy.17.2016.06.21.14.06.47 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 21 Jun 2016 14:06:47 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 In-Reply-To: <20160621144047.GB3177@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:4010:c07::22f 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:204656 Archived-At: On 06/21/2016 05:40 PM, Alan Mackenzie wrote: >> Does C++ mode in master support raw strings already? Is there a limit on >> how far you look for the end of the raw string, and if yes, how much is it? > > Yes, no, and N/A, respectively. Try out this raw string support, > sometime. I will. > At the risk of reigniting arguments, the current mechanism pays no > attention to the buffer text before a change. So, if this is relevant > to the bounds of the region wanting syntax-table props applied/deleted, > the s-p-extend-r-f mechanism will need to be supplemented by a > before-change function. The sort of situation you'd need it is where a > buffer change consists of deleting an escaped EOL. If you only look at > the buffer in a-c, you'll have no idea how far back the original C Macro > extended, for example. This makes a certain amount of sense, but I disagree with the conclusion: the fact that you *can* do this additional stuff in before-change-function, then save and use the resulting information later inside syntax-propertize-extend-region-functions, means the latter is general enough. But if you were willing to change how CC Mode works further, maybe you won't need this. Instead, you need two things: - A way to get back to a "safe" position. (syntax-ppss) provides this, as long as the only types of contexts one has to worry about are comments and strings (maybe different kinds), but with C/C++ you may have to first (goto-char (car (nth 9 (syntax-ppss)))) and then parse locally from that. Failing that, you could keep your own cache of safe positions, similar to syntax-ppss cache. - Know how to syntax-propertize buffer contents going forward from a safe position. You must know this already because you can syntax-propertize a newly opened buffer. So when the user edits something inside a macro, cc-mode-syntax-propertize, when called on that position, will go back and re-propertize the whole macro, along with all buffer contents between the safe position and here. There's a certain overhead associated with this approach, but it's been working rather well in many cases, and it's conceptually simple. Maybe you should try that and see how big the overhead is.