From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Mon, 04 Dec 2017 18:12:34 +0200 Message-ID: <83r2saxyj1.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1512404101 17156 195.159.176.226 (4 Dec 2017 16:15:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 4 Dec 2017 16:15:01 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 04 17:14: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 1eLtOO-00044o-VQ for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 17:14:53 +0100 Original-Received: from localhost ([::1]:43919 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtOW-0007pW-8J for ged-emacs-devel@m.gmane.org; Mon, 04 Dec 2017 11:15:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44313) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtMN-0006HM-Dk for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:12:51 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLtMM-0007iU-DA for emacs-devel@gnu.org; Mon, 04 Dec 2017 11:12:47 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57115) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLtMM-0007iQ-9I; Mon, 04 Dec 2017 11:12:46 -0500 Original-Received: from [176.228.60.248] (port=4296 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eLtML-0006CC-3N; Mon, 04 Dec 2017 11:12:45 -0500 In-reply-to: (message from Stefan Monnier on Sun, 03 Dec 2017 16:52:25 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:220701 Archived-At: > From: Stefan Monnier > Date: Sun, 03 Dec 2017 16:52:25 -0500 > > > 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). What I don't understand is why we are asked to remove prog-indentation-context. I don't see how its existence contradicts the possibility of calling 'widen' directly or leaving the variable at its default nil value. What am I missing? > 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. Why does it need to widen, though? If the mode's indent-line-function is not supposed to call 'widen', why do we do that in indent-according-to-mode? I don't think this has been explained anywhere. When you widen, the text that comes into the view will be entirely alien syntactically to the sub-mode that is trying to indent, right? The existing code calls prog-widen in those cases, but that only widens to include the current chunk (or whatever else the writer of prog-indentation-context had in mind), which had this issue under control, but the proposed changes toss that. > 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. But that's an incompatible change, isn't it? And I don't see what it has to do with MMM, where any restriction prior to the call to the indentation function should be honored. > > 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. That matters very little these days, as many people track the development branches and adapt their packages to the new features before they are released. > > 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. Why not just leave them alone? IOW, where do they get in the way of MMM calling 'widen' directly?