From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier 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 11:42:49 -0500 Message-ID: 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 X-Trace: ger.gmane.org 1392309785 4256 80.91.229.3 (13 Feb 2014 16:43:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 13 Feb 2014 16:43:05 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Feb 13 17:43:13 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 1WDzNV-0004Us-Q6 for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 17:43:10 +0100 Original-Received: from localhost ([::1]:47656 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDzNV-0007Za-D4 for ged-emacs-devel@m.gmane.org; Thu, 13 Feb 2014 11:43:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42949) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDzNL-0006jm-KN for emacs-devel@gnu.org; Thu, 13 Feb 2014 11:43:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WDzND-0000BK-8Q for emacs-devel@gnu.org; Thu, 13 Feb 2014 11:42:58 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:5386) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WDzND-0000BC-4a for emacs-devel@gnu.org; Thu, 13 Feb 2014 11:42:51 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABK/CFFLd+mu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDh8HBwsUGA0kLodwBsEtjVWDNQOIYZwZgV6DFQ X-IPAS-Result: Av8EABK/CFFLd+mu/2dsb2JhbABEvw4Xc4IeAQEEAVYjBQsLDh8HBwsUGA0kLodwBsEtjVWDNQOIYZwZgV6DFQ X-IronPort-AV: E=Sophos;i="4.84,565,1355115600"; d="scan'208";a="47554642" Original-Received: from 75-119-233-174.dsl.teksavvy.com (HELO pastel.home) ([75.119.233.174]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 13 Feb 2014 11:42:50 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 0C2F76007C; Thu, 13 Feb 2014 11:42:50 -0500 (EST) In-Reply-To: <52FCD2B4.5080006@yandex.ru> (Dmitry Gutov's message of "Thu, 13 Feb 2014 16:12:04 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:169590 Archived-At: >> 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". Of course, if the code uses switch-to-buffer, then it gets much slower because of the redisplays. 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). 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; ...). > Or do you mean that indirect buffers add their own overhead, just by having > (and somehow coordinating, I guess) the same contents? I wasn't thinking of that, no, although it is true that the presence of an indirect buffer can slow down some operations. >> 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: 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)? IOW I'd expect to start with a loop through the output of (buffer-local-variables), skipping the permanent-local vars. Then add special cases (e.g. current-local-map, syntax-table which aren't variables or syntax-ppss-cache which should probably be treated like a permanent-local). Of course, maybe it wouldn't be faster: (buffer-local-variables) returns a fairly long list (like 100 more than elements), and at every mode-switch we'd have to go through 2 such lists (the "from" and the "to"). If we can make this clean enough, we could implement it in C, which might speed it up significantly. Stefan