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: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sun, 03 Dec 2017 16:52:25 -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 1512338002 4273 195.159.176.226 (3 Dec 2017 21:53:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 3 Dec 2017 21:53:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Dec 03 22:53:18 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 1eLcCK-0000ll-5I for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 22:53:16 +0100 Original-Received: from localhost ([::1]:40288 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLcCR-0002rU-IZ for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 16:53:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52358) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLcBk-0002pQ-Sm for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:52:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLcBh-0000xs-Pg for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:52:40 -0500 Original-Received: from [195.159.176.226] (port=51288 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLcBh-0000w8-Hv for emacs-devel@gnu.org; Sun, 03 Dec 2017 16:52:37 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1eLcBW-0006b6-1a for emacs-devel@gnu.org; Sun, 03 Dec 2017 22:52:26 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 74 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:dwh1yo7w2BhR7xJEQiq27V5iCpY= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:220666 Archived-At: > Convince Alan to do what? Do we even understand well enough what are > the problems in CC Mode that get in the way? Yes. > About the only thing > spelled out in this discussion was the need not to widen. Personally, > I think this is not a grave issue, just some technical problem that is > certainly solvable (you proposed one such solution). Indeed. > But is that all? You mentioned some other problems, but never > described them. What are they? Are they grave enough to prevent your > proposal from ever supporting CC Mode, 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). > even if your proposal is amended? No need to amend anything. > 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). > cause it to end up like all the previous ones: either committed to > Emacs and basically unused, or, worse, collecting dust in long > forgotten patches or branches? His proposal is really really small, and matches what is already done in mmm-mode and mhtml-mode, so it's actually the solution that's least likely to collect dust, because it's already in use. > Emacs 26 has enough new features to justify a major release, so I see > no reason to press so hard to get this feature into it as well. I think the failure here is to describe clearly the proposal. The core of the proposal, AFAIK, is the following: state that indent-line-function can rely on the current narrowing to find all the relevant text, because the caller has already widened when necessary for that. To make it true, we need a few changes in the code, mostly we need to tweak indent-according-to-mode so that it widens before calling indent-line-function. This change should be harmless because even if the user has narrowed the buffer, the indentation should always be done depending on the whole buffer's content anyway. >> It's not well supported, and it's incompatible with the code we are >> discussing. There's no point in having it present in Emacs 26, and then >> removing it in Emacs 27. > That code is in Emacs for more than 2 years. It's been in emacs.git's master, yes, but not in any released version of Emacs. > It was admitted with Stefan's full support, and at least ANTLR needs > it in conjunction with Python. These can very easily be adjusted to rely on the new convention. Stefan