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: /srv/bzr/emacs/trunk r101338: * lisp/emacs-lisp/syntax.el (syntax-ppss): More sanity check to catch Date: Fri, 14 Feb 2014 06:44:13 +0200 Message-ID: <52FD9F1D.50205@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1392353072 3536 80.91.229.3 (14 Feb 2014 04:44:32 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 04:44:32 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 05:44:40 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 1WEAdi-0008KA-MX for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 05:44:38 +0100 Original-Received: from localhost ([::1]:49782 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEAdi-0000qf-8s for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 23:44:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37048) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEAdY-0000qW-7C for emacs-devel@gnu.org; Thu, 13 Feb 2014 23:44:36 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEAdP-0003bl-Po for emacs-devel@gnu.org; Thu, 13 Feb 2014 23:44:28 -0500 Original-Received: from mail-ee0-x22e.google.com ([2a00:1450:4013:c00::22e]:56250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEAdP-0003bU-Ig for emacs-devel@gnu.org; Thu, 13 Feb 2014 23:44:19 -0500 Original-Received: by mail-ee0-f46.google.com with SMTP id c13so5415881eek.33 for ; Thu, 13 Feb 2014 20:44:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=3+RZZahsEZrrtjBN40U/4MUV7T3/7hEul2ZCoDMSRYY=; b=RANR+O1qIn4XW5cp27zmnQ43oaI2i8coSR6PKhJTsQ+qJejJkqStI2THBbJF77bsn3 u8gxebtOByk9ECLj3XbEizMVUoR6/e8tDuqgF5b4N+edMB4nJUQJyR/Zff1ZgMgclLIp opJN5LcTnBef7Mqx6trvWLqr/imsFjnSmEs79secrxErUy57BuCtZ5FHVlYr97OwXXO9 P/GuLC5C6I+clDPAclmKP3FLdnsYFmHg7yKJ97Jx6KpdG8Oa6rRNl1GGzETwch0yx68J MyFEb73190W2Sjbf4qRO0/iiBJEJFk3HjDkHF7Z1Oq3A+dDjqT6x0osgTRDw1K8RJNEB Uhhg== X-Received: by 10.15.22.65 with SMTP id e41mr6386996eeu.5.1392353058339; Thu, 13 Feb 2014 20:44:18 -0800 (PST) Original-Received: from [192.168.10.2] ([93.109.195.252]) by mx.google.com with ESMTPSA id j42sm14913601eep.21.2014.02.13.20.44.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 20:44:17 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4013:c00::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:169596 Archived-At: On 13.02.2014 18:42, Stefan Monnier wrote: > Just `set-buffer' might be faster, indeed, but mostly because it's > written in C (e.g. it also has to iterate through the local variables to > save the old value and reload the new value for some of them). Not the 100+ of them, though? > But then you have to add things like the need to handle variables that > are buffer-local but should be shared among the indirect buffers, and > I doubt the end result will be faster. Plus handle all the bugs that > indirect buffers introduce (e.g. a modification in one of the indirect > buffers only runs its own after-change-functions, not the one of the > base buffer or any of the other indirect buffers; overlays added by > a major/minor mode in its indirect buffer won't affect the display of > the base buffer; ...). This clearly calls for introduction of base-buffer-local variables! Half-kidding aside, yeah, it sounds like indirect buffers might need some bugfixing to be usable as a building block for mmm-mode. > Hmm... I wonder why mmm-save-local-variables is defined the way it is. > It doesn't seem to make use of `buffer-local-variables', even though it's > the most natural starting point. E.g. there shouldn't be a need to list > explicitly all the c-* variables. Maybe the author didn't know about > buffer-local-variables (or it didn't exist back then)? I'm not quite sure, but this way we only save the variables that are known to be safe in the multiple-mode context. And also don't touch anything mmm-mode itself introduced. For non-cc-engine modes, the lists of variables to save are quite short, on the order of ~30 items. Apparently I was even wrong about saving and restoring being the slow part: `mmm-update-submode-region', which includes the calls to `mmm-save-changed-local-variables' and `mmm-set-local-variables', is faster than simply calling `buffer-local-variables'. In a mixed-mode test file: (js2-time (dotimes (_ 1000) (buffer-local-variables))) => 0.098 (js2-time (dotimes (_ 1000) (mmm-update-submode-region))) => 0.055 ^- the latter was without the check "if mode unchanged, do nothing". Now that I've checked, parsing the buffer into regions is definitely the slowest part (followed by fontification, which takes about 40% of the time in the current test example): (js2-time (dotimes (_ 1000) (mmm-parse-buffer))) => 7.97 ^- includes both `mmm-apply-classes' and `mmm-refontify-maybe'. And it's a 30-line file.