From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: CC Mode in MMM Mode(s). Date: Wed, 6 Dec 2017 18:19:48 +0000 Message-ID: <20171206181948.GA4098@ACM> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: blaine.gmane.org 1512584817 30674 195.159.176.226 (6 Dec 2017 18:26:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2017 18:26:57 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: Eli Zaretskii , tom@tromey.com, monnier@iro.umontreal.ca, spinuvit@gmail.com, emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Dec 06 19:26:53 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 1eMePE-0007s8-F9 for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 19:26:52 +0100 Original-Received: from localhost ([::1]:56968 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMePL-0003fI-KW for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 13:26:59 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMeOp-0003Q9-PB for emacs-devel@gnu.org; Wed, 06 Dec 2017 13:26:28 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMeOk-0005pu-OY for emacs-devel@gnu.org; Wed, 06 Dec 2017 13:26:27 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:50809 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eMeOk-0005ng-GX for emacs-devel@gnu.org; Wed, 06 Dec 2017 13:26:22 -0500 Original-Received: (qmail 9774 invoked by uid 3782); 6 Dec 2017 18:26:21 -0000 Original-Received: from acm.muc.de (p548C6AE3.dip0.t-ipconnect.de [84.140.106.227]) by colin.muc.de (tmda-ofmipd) with ESMTP; Wed, 06 Dec 2017 19:26:19 +0100 Original-Received: (qmail 4147 invoked by uid 1000); 6 Dec 2017 18:19:48 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:220767 Archived-At: Hello, Dmitry. On Wed, Dec 06, 2017 at 01:34:40 +0200, Dmitry Gutov wrote: > On 12/5/17 9:01 PM, Alan Mackenzie wrote: > > As a first approximation, dealing with CC Mode's need to widen might > > help. (I don't yet know how that will work for when several CC Mode > > chunks are embedded in a single main buffer (?local variables), but that > > should become clearer as time goes by.) > As far as I'm conncerned, CC Mode can consider every chunk a separate > buffer. It might be suboptimal for some features, but let's take one > step at a time. I think I now understand. Each chunk is a separate overlay, and each overlay maintains its own list of local variables. > > In my quick skim of MMM Mode's code, I didn't see any way of accessing > > all the various pertinent "point-min"s: there's the point-min set by the > > user, the point-min set by MMM Mode to restrict operations to the > > current chunk, and there's the point-min set by (e.g.) CC Mode for its > > own purposes. The same applies (perhaps a bit less so) to all the > > "point-max"es. > You use the current restriction as set when indent-line-function is > called. Or font-lock-keywords are applied. You can stash those point-min > and point-max dynamically for your convenience, too. As a matter of interest, how does MMM mode handle its chunks for commands which aren't indentation (such as beginning-of-defun)? > > Wasn't `prog-widen' supposed to get the MMM Mode's chunk boundaries? > Kind of. It only returned those boundaries when inside > indent-line-function, too. OK. > > What are the recognised ways in MMM Mode of getting these three pairs of > > (point-min point-max)? > For the ones "set by MMM Mode", you can call point-min and point-max at > the beginning of indent-line-function. Again, you can stash it for later. > Of restrictions set by CC Mode I know nothing about. > 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. > 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. > >> If you manage to do it at all, that would be an achievement. But just > >> figuring out the biggest problems should help us to design the feature. > > I'm thinking about first adapting all the various CC Mode caches which > > implicitly or explicitly start at 1, each to have a "cache-min" position > > which would coincide with the chunk-start. > 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. > > 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. -- Alan Mackenzie (Nuremberg, Germany).