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: Bug #25608 and the comment-cache branch Date: Thu, 23 Feb 2017 09:48:03 -0500 Message-ID: References: <20170202202418.GA2505@acm> <83lgtouxpf.fsf@gnu.org> <20170202215154.GB2505@acm> <83h94bvhzw.fsf@gnu.org> <20170203172952.GC2250@acm> <0a40d539-b7bc-2655-5429-6280022106ee@yandex.ru> <20170204102410.GA2047@acm> <8f9e68fc-4314-625d-b4bf-796c71c91798@yandex.ru> <20170206192423.GB3568@acm> <4f0fabf3-be9c-7492-379b-59dc93e72b4f@yandex.ru> <20170207192119.GA2490@acm> <424e6409-029c-d15d-421c-4fb90594329c@yandex.ru> <195629e9-11d6-2fb6-4c9d-39c8a244e2ec@yandex.ru> <9f4ac18b-6453-bee8-83d8-f452392adbb9@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1487861363 14938 195.159.176.226 (23 Feb 2017 14:49:23 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 23 Feb 2017 14:49:23 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 23 15:49:20 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 1cguhr-0003Rl-Ka for ged-emacs-devel@m.gmane.org; Thu, 23 Feb 2017 15:49:19 +0100 Original-Received: from localhost ([::1]:59108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cguhv-00051u-UY for ged-emacs-devel@m.gmane.org; Thu, 23 Feb 2017 09:49:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38673) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cgugx-0004wJ-A7 for emacs-devel@gnu.org; Thu, 23 Feb 2017 09:48:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cgugs-0004rU-Bh for emacs-devel@gnu.org; Thu, 23 Feb 2017 09:48:23 -0500 Original-Received: from [195.159.176.226] (port=34495 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cgugs-0004r6-4p for emacs-devel@gnu.org; Thu, 23 Feb 2017 09:48:18 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1cguge-0005F3-3v for emacs-devel@gnu.org; Thu, 23 Feb 2017 15:48:04 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 43 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:J8CXVUM1j5phbcFNSt7B68eKi6M= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:212546 Archived-At: > Naturally, we'd need to save more information to be able to do > that. E.g. propertize the end of a complex comment with the position of its > beginning. Since the first time we go through a buffer is in the forward > direction, getting that info would be inexpensive. Actually, back_comment may very well parse backward "the first time", since it doesn't use any cache (currently). >> Maybe. Obviously, my syntax-ppss hammer makes me think that such >> alternate solutions aren't needed: syntax-ppss solves this case without >> having to try and come out with a clever way to detect which comments >> are tricky nor how to mark them. > The alternative tweak I had in mind would be applied somewhere around > syntax-propertize. But you still have to decide what info to save and when. I.e. there's a design problem, with non-trivial tradeoffs. Using syntax-ppss saves me the trouble. > Another thing to consider is that we would probably want to fontify the > contents of all subregions normally, even when inside comments belonging to > the outer mode. So the primitives used in > font-lock-fontify-syntactically-region would need to be able to stop at > those boundaries instead of automatically skipping over. That's right. > Just having those hooks won't be enough, we still don't have enough info how > to syntax-propertize the subregion contents, for instance. So I'm not sure > what the flexibility of using the functions here would buy us. Me neither. Maybe the real issue is that starting from syntax-table + syntax-propertize + font-lock is a losing proposition, and instead we should first come up with a completely different design (from scratch) that would be able to parse and highlight code and to accommodate multiple major modes. Then we can maybe see if there's a way to evolve the current design of syntax-table + syntax-propertize + font-lock to that new design. Stefan