From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 21:24:45 -0500 Message-ID: References: <20171129233237.27462.23351@vcs0.savannah.gnu.org> <20171129233238.504B5204F1@vcs0.savannah.gnu.org> <5d668ce5-1482-a3d4-c01b-7d996a532567@yandex.ru> <20171130214621.GA22157@ACM> <27985594-3bb4-ce88-8928-2ccfeac13eae@yandex.ru> <20171201154913.GB3840@ACM> <1e542021-e389-cca4-6acd-349efddb2652@yandex.ru> <20171201223529.GG3840@ACM> <4a94ec5c-efdd-50f1-ff4d-277f5f45c2df@yandex.ru> <83lgil1qme.fsf@gnu.org> <83d13x1j2s.fsf@gnu.org> <34abea95-c7f7-e8fa-8407-8c2fd2a4cfe1@yandex.ru> <83y3mkzw1n.fsf@gnu.org> <83mv2zzv7z.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512354340 10627 195.159.176.226 (4 Dec 2017 02:25:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 02:25:40 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 03:25:26 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 1eLgRf-0001ob-6J for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 03:25:23 +0100 Original-Received: from localhost ([::1]:40887 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLgRh-0002Y3-Er for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 21:25:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54221) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLgR8-0002Xv-JR for emacs-devel@gnu.org; Sun, 03 Dec 2017 21:24:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLgR4-0001bm-K6 for emacs-devel@gnu.org; Sun, 03 Dec 2017 21:24:50 -0500 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:6302) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLgR4-0001bN-Ej for emacs-devel@gnu.org; Sun, 03 Dec 2017 21:24:46 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2HBwwAvsSRa/7mYWxdcGwEBAQEDAQEBC?= =?us-ascii?q?QEBAYM8gR4BNY4tjwyBfZcCghSFRQKFK0gPAQEBAQEBAQEBA2gohSQBBAF5EAs?= =?us-ascii?q?NASYSFBgxLol/CKoaIQKKMAEBAQEGAgElhUuDP4MrixkFkxqPUpcnhhGDUyiHN?= =?us-ascii?q?JgHSAEQgU0yGggwgmSCURwZgWwjikoBAQE?= X-IPAS-Result: =?us-ascii?q?A2HBwwAvsSRa/7mYWxdcGwEBAQEDAQEBCQEBAYM8gR4BNY4?= =?us-ascii?q?tjwyBfZcCghSFRQKFK0gPAQEBAQEBAQEBA2gohSQBBAF5EAsNASYSFBgxLol/C?= =?us-ascii?q?KoaIQKKMAEBAQEGAgElhUuDP4MrixkFkxqPUpcnhhGDUyiHNJgHSAEQgU0yGgg?= =?us-ascii?q?wgmSCURwZgWwjikoBAQE?= X-IronPort-AV: E=Sophos;i="5.45,357,1508817600"; d="scan'208";a="11094886" Original-Received: from unknown (HELO pastel.home) ([23.91.152.185]) by smtp.teksavvy.com with ESMTP; 03 Dec 2017 21:24:45 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 53C4261367; Sun, 3 Dec 2017 21:24:45 -0500 (EST) In-Reply-To: (Dmitry Gutov's message of "Mon, 4 Dec 2017 00:03:14 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 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:220675 Archived-At: >> No, it's just a small matter of adjusting CC-mode here and there. >> But given that the only person who understands this part of CC-mode well >> enough is Alan, it's difficult for anyone but Alan to do it (I think >> I could do it as well, but I know that my solution wouldn't please Alan >> because it would involve switching over to syntax-propertize, so my >> motivation to do it is rather low). > Maybe you understand the issue better than me. Or maybe it's the conversion > to syntax-propertize that would do away with the extra caches that IIRC were > giving me troubles. Not really, no: adjusting the current code so that those caches work right in mmm-mode can also be done and can't be terribly hard either (e.g. flush the caches whenever the narrowing has changed, or index the caches with the current narrowing. Basically the same solutions we've discussed to get syntax-ppss to coexist reliably with narrowing). Of course, it would take you or me a lot of time trying to understand how those things currently work, then choose a solution, then implement it, but it's still just a small matter of adjusting CC-mode here and there. Nothing fundamentally hard. >>> How do you address the issues which prog-indentation-context did >>> (e.g., if the embedded chunk of code is incomplete, and perhaps even >>> syntactically invalid)? >> We can easily provide a similar functionality with Dmitry's design. >> Dmitry hasn't bothered doing that, because so far it's never been used >> (so it's not even clear whether it's ever needed nor whether it would >> provide the needed info). > To be clear, I'm not sure what you mean. But then, the problem/question > isn't well-formulated here. I think he was referring to the PREVIOUS-CHUNKS part of prog-indentation-context. The MMM framework could easily provide some similar facility (which would take care of changing the narrowing when needed). But I think we had better see some concrete uses first before deciding upon a design for that. Stefan