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: Fri, 14 Feb 2014 12:08:07 -0500 Message-ID: References: <87r47bi1e5.fsf@yandex.ru> <52F96284.50507@yandex.ru> <52FAE12B.6060101@yandex.ru> <52FC3BEE.60604@yandex.ru> <52FCD2B4.5080006@yandex.ru> <52FD9F1D.50205@yandex.ru> <52FE315B.5010909@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1392397729 30428 80.91.229.3 (14 Feb 2014 17:08:49 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 14 Feb 2014 17:08:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 14 18:08:56 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 1WEMFx-0004Vz-RY for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 18:08:53 +0100 Original-Received: from localhost ([::1]:52954 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEMFx-0006bJ-CZ for ged-emacs-devel@m.gmane.org; Fri, 14 Feb 2014 12:08:53 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57250) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEMFm-0006Pk-DX for emacs-devel@gnu.org; Fri, 14 Feb 2014 12:08:50 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WEMFe-0005Dw-0y for emacs-devel@gnu.org; Fri, 14 Feb 2014 12:08:42 -0500 Original-Received: from mercure.iro.umontreal.ca ([132.204.24.67]:34734) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WEMFd-0005Dh-Qk for emacs-devel@gnu.org; Fri, 14 Feb 2014 12:08:33 -0500 Original-Received: from hidalgo.iro.umontreal.ca (hidalgo.iro.umontreal.ca [132.204.27.50]) by mercure.iro.umontreal.ca (Postfix) with ESMTP id D3FC984DC7; Fri, 14 Feb 2014 12:08:32 -0500 (EST) Original-Received: from lechon.iro.umontreal.ca (lechon.iro.umontreal.ca [132.204.27.242]) by hidalgo.iro.umontreal.ca (Postfix) with ESMTP id 07B161E5B74; Fri, 14 Feb 2014 12:08:08 -0500 (EST) Original-Received: by lechon.iro.umontreal.ca (Postfix, from userid 20848) id DFA2AB40FE; Fri, 14 Feb 2014 12:08:07 -0500 (EST) In-Reply-To: <52FE315B.5010909@yandex.ru> (Dmitry Gutov's message of "Fri, 14 Feb 2014 17:08:11 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-DIRO-MailScanner-Information: Please contact the ISP for more information X-DIRO-MailScanner: Found to be clean X-DIRO-MailScanner-SpamCheck: n'est pas un polluriel, SpamAssassin (score=-2.82, requis 5, autolearn=not spam, ALL_TRUSTED -2.82, MC_TSTLAST 0.00) X-DIRO-MailScanner-From: monnier@iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 132.204.24.67 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:169623 Archived-At: >> The way I see it, it's rather "this way we can only work for those major >> modes we've been taught to handle". > Yes and no. An mmm-mode aware package can modify > mmm-save-local-variables', too. Right. In my experience, this doesn't work nearly as well as adding symbol properties. > Last time I checked, web-mode wasn't in this category: it's a major mode > with explicit support for some templating languages. That's right, it doesn't try to handle major modes generically, but it does have to solve similar problems, just with the benefit of being able to custom-make its major modes. > mmm-mode would require a hunt for CA signatures, but it's not outside the > realm of possibility. The way I see it rather is to start over from scratch, based on the experience gained with mmm-mode, but with a different view: instead of trying to make it work without changing existing modes, assume that the major modes will be changed to fit the framework. The result should be much simpler/cleaner/shorter. >>> And also don't touch anything mmm-mode itself introduced. >> This is the list that we can trivially know, so it's OK if we have to >> handle these specially. > I haven't measured it, but wouldn't adding an (unless (memq var (list with > 20 elements))) around processing each variable be, like, slow? Could be. (unless (get var 'mmm-foo) may be faster (mostly because the plist is usually less than 20 elements), if needed. I tend to assume that mode switches shouldn't be that super frequent to be a real performance problem, and that if they need to be sped up, there are ways to do that, e.g. by providing a few "subr", so I'm not too worried about it. Stefan