From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: CC Mode in MMM Mode(s). Date: Thu, 7 Dec 2017 02:21:25 +0200 Message-ID: References: <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> <643908a3-bec8-3ac1-38f7-4e73611478ef@yandex.ru> <20171203185946.GC5531@ACM> <20171204155238.GA5101@ACM> <9beb1b6c-7c37-da28-3451-3c2a440f309b@yandex.ru> <20171205190141.GA4745@ACM> <20171206181948.GA4098@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512606135 29069 195.159.176.226 (7 Dec 2017 00:22:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Thu, 7 Dec 2017 00:22:15 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:58.0) Gecko/20100101 Thunderbird/58.0 Cc: Eli Zaretskii , tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Dec 07 01:22:06 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eMjx0-0007Mt-C9 for ged-emacs-devel@m.gmane.org; Thu, 07 Dec 2017 01:22:06 +0100 Original-Received: from localhost ([::1]:58399 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMjx7-0003GU-KR for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 19:22:13 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52962) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMjwX-0003FR-8U for emacs-devel@gnu.org; Wed, 06 Dec 2017 19:21:38 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMjwS-0002pF-6t for emacs-devel@gnu.org; Wed, 06 Dec 2017 19:21:37 -0500 Original-Received: from mail-wr0-x22e.google.com ([2a00:1450:400c:c0c::22e]:40532) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eMjwR-0002nP-Un; Wed, 06 Dec 2017 19:21:32 -0500 Original-Received: by mail-wr0-x22e.google.com with SMTP id q9so5688730wre.7; Wed, 06 Dec 2017 16:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=79eMCd2Td74BhpB6hOwG+TBqDkpWmYe9ol+w6OQZ0x4=; b=lJT0+wbbsL1lYt1vxDR2cRmIAUok2nistjrwdtaqIZ7phxFyDnWcUy3xmUrc+dv0I5 VhogvZg4SOp30CoSeHldG9oRNRxdxRb00oiPlUgiqrtxS+iRFxFMzvPWq0gOsfMHs2jq jR+alNvotEBpcctHbFGgIKMNUjUOF3dpVky/ot+Epr2Tonc7evA/7EpzpD5kIgi12KMc kxIUTdjeytej/TJ1RnwZO4Y1uOigKxxWYb3NjSwjtWcYJpunR3fZjn/lDw9EqdjgArr7 KkQQjv0SymT0qPQ6BdrjQIYtE2KNSZMsSTP0xUqdmtMx8YxnoP+bzJZmgyD9+Y1VGzbR fomg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=79eMCd2Td74BhpB6hOwG+TBqDkpWmYe9ol+w6OQZ0x4=; b=jPNEVobvBaeup32sol0M2hMO4Q0MvwLvP8iB24L5b1vStJGak5BsnJDqeuDy0gpHOZ /QB1rSs3FoTdrfCaF2jqp/DWSqxLkuX9RtQoR39o26m/iavCIwL3rX0Lv87dc486jotW mNhmQWj9TXApLTbbpdEAC+fm3/FD3K28DCe9enTrC/KnLQ1SW4eSRz5pTh2/EO4yaFHd AEFafbeF5IwkmdjhBvBxbabDaO5m80ODLEKAfLaiZGXTs/MuvHtLTSwcxM2xeBnucbYh cT6WAeTFf9z0MNpbAXHVr8mrsB+vSQxxcnhNTUsxgaNGuAJvyceHjq95O0TfFtbeJ9rD IjTw== X-Gm-Message-State: AJaThX5vE+92Yf7gqwLKmwRXr6hak/5AD1ED/M6JXhXmLRYSzcR/irLj AoEYdbelRhiJGpE62/1d32KLXghp X-Google-Smtp-Source: AGs4zMa9hec0cxEv/T6RYG63bWktMimHOsXXgYz/oOpJIGuNzFJJzBWBV6t3PDyJq5XkX8UGquSOBw== X-Received: by 10.223.201.10 with SMTP id m10mr20858566wrh.68.1512606090334; Wed, 06 Dec 2017 16:21:30 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id g99sm4502817wrd.72.2017.12.06.16.21.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Dec 2017 16:21:29 -0800 (PST) In-Reply-To: <20171206181948.GA4098@ACM> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c0c::22e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:220773 Archived-At: On 12/6/17 8:19 PM, Alan Mackenzie wrote: > I think I now understand. Each chunk is a separate overlay, and each > overlay maintains its own list of local variables. Pretty much. With the exception that overlays can nest, and so hunk can be only a part of an overlay. For font-lock, that is (because it's usually the least context-dependent, so that seems the least error-prone). For indentation, however, we might narrow to the bounds of the current overlay, even if there are some nested ones inside it. We don't actually do that in the general case (random combination of modes), though. I've only really worked on custom indentation for html-erb-mode (defined in mmm-erb.el). > As a matter of interest, how does MMM mode handle its chunks for > commands which aren't indentation (such as beginning-of-defun)? It doesn't. For beginning-of-defun, it should likewise define its own beginning-of-defun-function which narrows and delegates (like usual), but that never actually came up in user requests so far. The other, non-customizable commands (for example major mode specific ones) work on best effort basis. It's not an exact science. :-) More importantly, mmm-mode also applies font-lock-keywords also by narrowing, like mentioned above. IIRC, some code called in font-lock-keywords in CC Mode widens, so that would have to be taken care of. And it's even more important than indentation, I'd say. >> And as for point-min set by the user, why do you want to know? > > Because CC Mode's "state cache" (bad name, I know), which records open > parens/braces/brackets preceding point, records those things only in the > accessible portion of the buffer. If that portion started within a CC > Mode chunk, things might/would go wrong if adjustments weren't made. That's, um, why? Sounds like a very niche optimization. Still, that cache might also be keyed on point-min, can't it? >> indent-for-tab-command should have taken care of widening by that time. > > Perhaps a function to return (user-point-min . user-point-max) might be > useful. I... don't really want to do that, but we might add that to the next version of the multi-mode API. Can you do without it in the meantime? >> That sounds like a plan. Maybe also avoid using some of the caches when >> the length of a chunk is smaller than a predefined value. > > That's an idea, but it would add (a little) complexity. It might not be helpful at all anyway. syntax-ppss derives some benefit from it, but that's because parse-partial-sexp is faster than running a bunch of Lisp code, for smaller chunks of text. >>> Maybe I could use some >>> mechanism to avoid invalidating them when a buffer change before the CC >>> Mode chunk changes this "cache-min" position. > >> The overhead of such solution would probably be N(number of chunks), >> wouldn't it? > > Yes. But it would be less than the overhead of recalculating the caches > after a buffer change within the CC Mode chunk, since it would just need > to add a constant offset onto each buffer position in the caches. Tradeoffs. I've worked on files with *lots* of Ruby chunks, but the situations where CC Mode will be used for inner chunks might be sufficiently different that it becomes less of a problem. Another approach might be to put the caches into chunk-local variables, but I'm not sure if we handle before/after-change-function correctly when a change crosses chunk boundaries. Not sure how to implement this properly either. Anyway, I'd devote as little time as possible to performance optimization right now, and see if we can get it working at all.