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). [Was: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls] Date: Wed, 6 Dec 2017 01:34:40 +0200 Message-ID: References: <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <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=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512577168 21741 195.159.176.226 (6 Dec 2017 16:19:28 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 6 Dec 2017 16:19:28 +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 Wed Dec 06 17:19:24 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 1eMcPO-0001Nn-Id for ged-emacs-devel@m.gmane.org; Wed, 06 Dec 2017 17:18:54 +0100 Original-Received: from localhost ([::1]:52458 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMMkS-0003b3-5R for ged-emacs-devel@m.gmane.org; Tue, 05 Dec 2017 18:35:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eMMjj-0003am-1P for emacs-devel@gnu.org; Tue, 05 Dec 2017 18:34:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eMMjf-0006ti-UP for emacs-devel@gnu.org; Tue, 05 Dec 2017 18:34:51 -0500 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:37819) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eMMjf-0006sR-Lp; Tue, 05 Dec 2017 18:34:47 -0500 Original-Received: by mail-wm0-x22b.google.com with SMTP id f140so4168564wmd.2; Tue, 05 Dec 2017 15:34:47 -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=Wg5H2YDHoXdazfu/2vF3amemK0yPB13jQVMo2Ah93+w=; b=da4vZ4ezyRk2JlcSzTed8eh5D+Znk9BsAVNkqcNnn1Z+vSkEQLY2ckHjVPBc+qbTGE 6j/uj1XIYwPIfvK8Tl0PVMJCd31958iFxcvZ5S0dQE0yWIPxcJcBpLVE97Xzq0KsRE9C U6q3Is5LmlyKK+zqzBmWeKac+gR1gTyr4ffh0hWEbA4Jpcf62n3yDGoBWFssS2bY7cvE 9k9cDlNQ7Q+MzWu3wSGYskzl0RQ8qrG48G5Aagc1nNlQ68U0hvtq+E7FlinEvFeZZgaD 2/0Mmp5o5/uEphmDZR+Nvz5I/FnqLAdKVjFA6yUr2mVFnHLF/mUOvd0aHI2CebNTsqS0 ihCw== 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=Wg5H2YDHoXdazfu/2vF3amemK0yPB13jQVMo2Ah93+w=; b=n5iOQkl0NDLXnJRXkY/UDE0KJrFtSRBCOY6woM9otDvqaZCkrpVaK0u1Dhh2uzjNND G93EZ7rylV0SN4YN21xHtrBCIo6Zl3OHcL5XuJF+PlPMkRR+WcZWkJp1LCmpDayUnTMA AZbuGJjANpJfXyCzGsn+eaoJECP0N/m23vNtEI7QpL3vS1h9c39yHmVgoVikbL20id0U pJ50KsKzDJ+2x3SMNIM9ilA/ZkaHQw6JXyNuqbhjqrgd1XaD/eWTtCCTB2jlHfIW+ndO zYaVDFKVpp/I85SStEfkNTkxe15kP00gf82wVf1aSxi+CpZwqsq4E+0YTTqStpIgKpJp t+Hg== X-Gm-Message-State: AKGB3mKf/g2ZYCqNe2WC9eut1kWnfJ5fibRx5TZr3YQxVn3E8ZoWJsDG j5971OpkGbmMR5gAVFAo4asdM6dO X-Google-Smtp-Source: AGs4zMYYXxj9Uy3EPZbzs66rL0GYsSXteSVnWdgDyB2a9T2L/V/x69Pa/PlpNgQmFnbkuACTEU2Ocw== X-Received: by 10.28.216.212 with SMTP id p203mr7421739wmg.50.1512516886121; Tue, 05 Dec 2017 15:34:46 -0800 (PST) Original-Received: from [192.168.1.3] ([185.105.174.193]) by smtp.googlemail.com with ESMTPSA id a71sm1502442wme.33.2017.12.05.15.34.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Dec 2017 15:34:45 -0800 (PST) In-Reply-To: <20171205190141.GA4745@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:c09::22b 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:220763 Archived-At: 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. > 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. > 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. > 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? indent-for-tab-command should have taken care of widening by that time. >> 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. > 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? > Ah, Cyprus! I'll bet it's a deal warmer than Germany at the moment! Indeed. About 15 degrees warmer. :-)