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: Fri, 01 Dec 2017 11:26:08 -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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512151234 11380 195.159.176.226 (1 Dec 2017 18:00:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 18:00:34 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org, Tom Tromey , Vitalie Spinu , Dmitry Gutov To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 19:00:29 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 1eKpbr-0002Rb-2F for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 19:00:23 +0100 Original-Received: from localhost ([::1]:59276 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKpby-0006x0-9Z for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 13:00:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44535) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKo8m-00035n-9M for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:26:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKo8j-0002cA-3R for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:26:16 -0500 Original-Received: from alt13.smtp-out.videotron.ca ([135.19.0.26]:64223 helo=alt12.smtp-out.videotron.ca) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1eKo8i-0002aH-UD for emacs-devel@gnu.org; Fri, 01 Dec 2017 11:26:13 -0500 Original-Received: from fmsmemgm.homelinux.net ([23.233.195.134]) by Videotron with SMTP id Ko8eeBHi1MUwsKo8fejrJL; Fri, 01 Dec 2017 11:26:10 -0500 X-Authority-Analysis: v=2.2 cv=Q6mi28+a c=1 sm=1 tr=0 a=xXJ578j8WyTliCxld3/pTA==:117 a=xXJ578j8WyTliCxld3/pTA==:17 a=ocR9PWop10UA:10 a=gym6D8uv9x3A-qVEUawA:9 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 73E0DAE0A9; Fri, 1 Dec 2017 11:26:08 -0500 (EST) In-Reply-To: <20171201154913.GB3840@ACM> (Alan Mackenzie's message of "Fri, 1 Dec 2017 15:49:13 +0000") X-CMAE-Envelope: MS4wfC9XTKqxI+9Ky5as+oQ/efJV7kU1c2u3zywmJ3nwSsfdBgVQoGH7dxqkmeVJioeDa0d+hsFAZwOxJKF38wXgCridT1wdySHeO2e+artfzFQNdDsDTv/5 z2N8SCy1yaUTXWttHBoMfyTJNElXG1xdGUh+/9Kr3+s8h6RCZwxyXxK88BaNZH6qXhnjP5kBXfo8In52v5Q/p1fReAP21PsZS1jFOdMr9TfZU/jBxqSfEJio Qc47bf2zEWZWHzLdND7pD2gaH26v/S/gi/01LKFuaERRgnl+adwHGU4fXfSx2/Z2UqRgesvEkpN0wSTTqczbtAjmIWCxiyQIdPEOuzm2Hrs= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 135.19.0.26 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:220567 Archived-At: >> To rephrase, don't widen in indent-line-function or >> beginning-of-defun-function. > This is an intolerable restriction. The low level function mentioned > above cannot, should not, must not know whether it's being called > (indirectly) from indent-line-function or b-o-d-function. It's a change. So, to make it work right, some code will need to adapt. As mentioned by Dmitry, this shouldn't introduce breakage in general: the code will only need to adapt *if* it wants to work with multi-major-mode solutions. For the normal use case, you can still widen/narrow to your heart's content and nobody will be the wiser. There's nothing special here: any multi-major-mode solution will need to define some convention/protocol that major need to follow in order to work well. Now if you worry that (after the code is adapted) the result is code that is too complex/brittle, time will tell, but I get the impression that it won't be too bad, likely no worse than any other solution. The way your above situation would be handled is to say "the low level function mentioned above assumes that the buffer has already been properly widened". This way, it doesn't need to know whether it's being called (indirectly) from indent-line-function or b-o-d-function. But some of its callers may need to be changed to do the widening, and indeed, in order to know how far to widen, they'll need the help from the multi-major-mode package. So maybe we need something like: (defvar prog-widen-function #'widen) (defun prog-widen () (funcall prog-widen-function)) [ And maybe for the same reason, we need a function (rather than a variable) that returns the `first-column`, so we can get the info anywhere/anytime rather than only during indentation. ] Stefan