From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: immerrr again Newsgroups: gmane.emacs.devel Subject: Re: Bug in font-lock-syntactic-keywords handling? Date: Mon, 6 Oct 2014 18:21:35 +0400 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1412605307 10286 80.91.229.3 (6 Oct 2014 14:21:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Oct 2014 14:21:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 06 16:21:42 2014 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 1Xb9AU-0003p7-Ke for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 16:21:42 +0200 Original-Received: from localhost ([::1]:52187 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb9AU-0002p3-6K for ged-emacs-devel@m.gmane.org; Mon, 06 Oct 2014 10:21:42 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47632) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb9AR-0002oy-Fm for emacs-devel@gnu.org; Mon, 06 Oct 2014 10:21:40 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Xb9AQ-0008LM-CR for emacs-devel@gnu.org; Mon, 06 Oct 2014 10:21:39 -0400 Original-Received: from mail-qc0-x22e.google.com ([2607:f8b0:400d:c01::22e]:55267) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Xb9AQ-0008Kq-8q for emacs-devel@gnu.org; Mon, 06 Oct 2014 10:21:38 -0400 Original-Received: by mail-qc0-f174.google.com with SMTP id m20so3931421qcx.5 for ; Mon, 06 Oct 2014 07:21:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=hp7o/Cn1FZVXv9fUe8MbP22h7xwGhxGvWI8q28kgXEM=; b=h27Fi4+xm2b1zkP69uRdrDgnQ41r2Yx5iH7c/k4NbxcXNOGwfeDViUrmMP3eXVcPkJ 31xN6zq6Ox5S/jCLjo9XMKFJsm/Lo8Gz3WTsEu58y1Ty7PKDmJALSubZq/I/80sXAuOU H1D/uSo3cSKB+lR1nfypq1ylq8vGhLXKEYY0IYF1u6bVEe2i5eihcSOON8y7tDSth9eg wcG4QTEUCSGk1hK6IIpei0iURm4vqK+7LvJWdI67xf7ldW+wLBTemwLjtOZqLK7EpqsA Y57z5x2F732f+PFdLgkL0cz/tpatnpuoE8BHntFlirJmKL46Kl2p2gfNUgiBiZmcwzb4 gwbw== X-Received: by 10.224.138.8 with SMTP id y8mr30863273qat.37.1412605295363; Mon, 06 Oct 2014 07:21:35 -0700 (PDT) Original-Received: by 10.140.98.148 with HTTP; Mon, 6 Oct 2014 07:21:35 -0700 (PDT) In-Reply-To: X-Google-Sender-Auth: eAVwb7WZcIs6sc7yTCpHmJjeid0 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400d:c01::22e 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:175014 Archived-At: On Mon, Oct 6, 2014 at 5:14 PM, Stefan Monnier wrote: > > That seems like a performance bug (it re-fontifies something that's > already been fontified), indeed, but I don't see why that would cause > something to "fail". > > If it really causes a failure, I suspect that the failure is really > caused by an underlying bug in the specific syntactic-keywords rules, > which merely gets triggered by this performance bug. > > > Stefan The problem is that it doesn't unfontify the already processed chunk beforehand. It this particular situation, when I encounter a "--[[" comment starter I need to be sure that there are no dashes before ("---[[...\n" is a single-line comment by design) and that this starter is not inside another comment. I did this the "smart" way: I checked (elt ppss 4) of the *second* dash, so that when there's something like "--X-[[" with X being the point, the point is already inside a single-line comment. That single check covers both cases, yet, as most "smart" things do, it breaks unexpectedly. This one breaks when "--[[" is already propertized as a comment opener and the second dash is already a part of that comment. This causes comment-open matcher to fail and simple two-step propertize function [1], (lambda (limit) (or (try-close-comment limit) (try-open-comment limit))) doesn't work, since there is no comment to be closed at the beginning of the chunk, the opener is already propertized and thus skipped and the closer is never invoked again. Cheers, immerrr 1. This lambda is a simplified version of https://github.com/immerrr/lua-mode/blob/master/lua-mode.el#L868-L872