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: Thu, 13 Feb 2014 05:28:46 +0200 Message-ID: <52FC3BEE.60604@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@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 1392262143 4764 80.91.229.3 (13 Feb 2014 03:29:03 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Feb 2014 03:29:03 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 13 04:29:11 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 1WDmz8-0007fM-Ly for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 04:29:10 +0100 Original-Received: from localhost ([::1]:43918 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDmz8-0000fR-8S for ged-emacs-devel@m.gmane.org; Wed, 12 Feb 2014 22:29:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40064) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDmyx-0000ey-H2 for emacs-devel@gnu.org; Wed, 12 Feb 2014 22:29:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDmyp-00032J-2j for emacs-devel@gnu.org; Wed, 12 Feb 2014 22:28:59 -0500 Original-Received: from mail-ee0-x232.google.com ([2a00:1450:4013:c00::232]:37064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDmyo-00032F-Rl for emacs-devel@gnu.org; Wed, 12 Feb 2014 22:28:51 -0500 Original-Received: by mail-ee0-f50.google.com with SMTP id d17so4670162eek.37 for ; Wed, 12 Feb 2014 19:28:49 -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=Ok8JdoUBL01Lqyxn/nZrtzW03AO2C6nE2i6T+qMmbpY=; b=MDJ+OHaNKrpYezAQGMNsOggWAEheIYuNLsp0QCC3rLZ76liKGagS3qilNlpGIcupwg +rgg3pkp94exdaMZ+6Jt/khsnjhzgOu1Qnms7xbkOH+lwHqUJohh0OPSdb0JTZX4OT2J spkwEI2bnUoWSYDTUV+JPdKFW323dtFl5xlwxx9ZBhqqWGL6KXk7s/yHdNzwD1swiRjX mLyKsG9xwV20Yt/K0CteFMPQpD2McxK+CjQdFND50PesxXX1JkMvpCUvtatLyIf3031r f6uCbGtZrXJtB3xE7LFnx3yaVMX9a3NM3dNapH4UFk0pMdKOR6R0vKU3tOlCGoPcST/G Eh9g== X-Received: by 10.14.198.132 with SMTP id v4mr7931868een.43.1392262129794; Wed, 12 Feb 2014 19:28:49 -0800 (PST) Original-Received: from [192.168.10.2] (62-36-157.netrun.cytanet.com.cy. [62.228.36.157]) by mx.google.com with ESMTPSA id q44sm1585692eez.1.2014.02.12.19.28.47 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 12 Feb 2014 19:28:49 -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::232 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:169575 Archived-At: On 12.02.2014 16:23, Stefan Monnier wrote: > In 99% of the cases, syntax-ppss is only called once during font-lock. > So, while in theory, yes, we might still get some benefits, in practice > we don't. `syntax-propertize' can call it multiple times, though (at least in the case of ruby-mode), and that's called as often as font-lock. > Of course, another issue is "which syntax-table and syntax-propertize > function to use". How does mmm-mode handle that currently? It has a function called `mmm-update-submode-region', which restores the saved buffer-local values, syntax table, etc, for the mode at point. It's called: * From post-command-hook. * From `mmm-syntax-propertize-function', which iterates over regions, calls the aforementioned function and then the submode's syntax-propertize-function. * From `mmm-fontify-region', which is similar, but for font-lock. * From `mmm-indent-line' and the specialized `mmm-indent-line', because we usually want to indent by the rules of the submode at indentation, and it might be different in the middle of the line. IOW, various stuff works, as long as mmm-mode is aware of the respective facility. Each has to be supported explicitly, though. By the way, AFAICT, the juggling of local variables between modes (save, restore, rinse, repeat) is one of the major factors in mmm-mode performance. There was an old `multi-mode' by Dave Love that used indirect buffers to keep the buffer-local values around, and switched between them in post-command-hook (which might or might not have been a good idea) and in `multi-fontify-region', taking advantage of the fact that fontification in an indirect buffer translates into the base buffer. Now I hear that we shouldn't use indirect buffers. Would there be a fast way to save and restore all local variables in a buffer? This would cut down on both mmm-mode overhead and complexity.