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 16:12:04 +0200 Message-ID: <52FCD2B4.5080006@yandex.ru> References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@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 1392300744 14693 80.91.229.3 (13 Feb 2014 14:12:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Feb 2014 14:12:24 +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 15:12:32 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 1WDx1i-0006zA-EH for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 15:12:30 +0100 Original-Received: from localhost ([::1]:46605 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDx1h-0005Ym-VB for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 09:12:29 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37555) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDx1Z-0005WJ-OL for emacs-devel@gnu.org; Thu, 13 Feb 2014 09:12:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDx1U-0008JF-2p for emacs-devel@gnu.org; Thu, 13 Feb 2014 09:12:21 -0500 Original-Received: from mail-ee0-x22a.google.com ([2a00:1450:4013:c00::22a]:51891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDx1T-0008JB-Rq for emacs-devel@gnu.org; Thu, 13 Feb 2014 09:12:16 -0500 Original-Received: by mail-ee0-f42.google.com with SMTP id b15so5015870eek.15 for ; Thu, 13 Feb 2014 06:12:15 -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=H9mx9oLPZHazXI66KjlrWZ/1uVjLMlK0QOBJ6jJY2+w=; b=p5eXYanh4sni/eBM+gPeZ+4EiFjogfl0OgZDfb5hBsFdTDd6Q6fCC15sYn44Y62gHt LznsXA7bFzpyyGTsGfc0YKv6p35CAF7AQWuIhMLW+oZZJhBhxwHalPkRUBVkS9sRc+er D/lAFHA2frPRuEIxLeO/nNwtQZeYHLmCZuJOM0i6WIMES5U2umlswBoYsz+il0mZKuUb hgm8YNkIrGaMV8s3x32ylmB7Q6V9J/sty1D4ta1cYTNJBuvqxB19qhc6oV74s5wLEnJO zwqIDDnHHEM7dMHcghDnjUl8jVOiiHACX1Lra+WEMtb1kZ/dQ5kKdWXfC3583BPb/6PX RQGQ== X-Received: by 10.15.76.1 with SMTP id m1mr2240415eey.36.1392300735015; Thu, 13 Feb 2014 06:12:15 -0800 (PST) Original-Received: from [192.168.10.2] ([93.109.195.252]) by mx.google.com with ESMTPSA id x6sm7377259eew.20.2014.02.13.06.12.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 06:12:13 -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::22a 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:169584 Archived-At: On 13.02.2014 15:28, Stefan Monnier wrote: > Indeed, I don't think using an indirect buffer is a good solution. > I'm not even sure it's faster than mmm's "manual" variable switch. Why not? `switch-buffer' has to be faster than "iterate these lists, save values of symbols, set them to values from those alists". Or do you mean that indirect buffers add their own overhead, just by having (and somehow coordinating, I guess) the same contents? > Not sure how best to speed it up. We could of course reduce the > interpretation overhead by providing a kind of "context-switch" > primitive written in C. This would probably speed it up significantly. > > But making it do really less work is difficult: there's the > "local-variables" alist in the "struct buffer" which we could switch in > one step, but: > - it doesn't account for all local variables (doesn't account for those > local-vars held directly in the "struct buffer" such as tab-width). > - it would switch some vars which should not be switched. This, together with a blacklist and a small "additional variables" list would still probably be a lot neater than mmm-vars.el: https://github.com/purcell/mmm-mode/blob/master/mmm-vars.el#L111-L302