From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Fri, 1 Dec 2017 18:20:37 +0000 Message-ID: <20171201182037.GF3840@ACM> 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; charset=us-ascii X-Trace: blaine.gmane.org 1512158898 7830 195.159.176.226 (1 Dec 2017 20:08:18 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 20:08:18 +0000 (UTC) User-Agent: Mutt/1.7.2 (2016-11-26) Cc: emacs-devel@gnu.org, Tom Tromey , Vitalie Spinu , Dmitry Gutov To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 21:08:14 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 1eKrbW-0001ci-Kx for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 21:08:10 +0100 Original-Received: from localhost ([::1]:60511 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKrbd-00071j-SO for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 15:08:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44351) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKq0z-0005au-HR for emacs-devel@gnu.org; Fri, 01 Dec 2017 13:26:22 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKq0v-0000K1-8W for emacs-devel@gnu.org; Fri, 01 Dec 2017 13:26:21 -0500 Original-Received: from colin.muc.de ([193.149.48.1]:43307 helo=mail.muc.de) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1eKq0v-0000JY-19 for emacs-devel@gnu.org; Fri, 01 Dec 2017 13:26:17 -0500 Original-Received: (qmail 61181 invoked by uid 3782); 1 Dec 2017 18:26:15 -0000 Original-Received: from acm.muc.de (p548C7BEF.dip0.t-ipconnect.de [84.140.123.239]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 01 Dec 2017 19:26:13 +0100 Original-Received: (qmail 7335 invoked by uid 1000); 1 Dec 2017 18:20:37 -0000 Content-Disposition: inline In-Reply-To: X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x [fuzzy] X-Received-From: 193.149.48.1 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:220586 Archived-At: Hello, Stefan. On Fri, Dec 01, 2017 at 11:26:08 -0500, Stefan Monnier wrote: > >> 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: That has yet to be shown. > 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. If we're going to have a multi-major-mode solution (and I think we should), let's at least get it right. I.e., it should work with _any_ major mode without grotesque restrictions on that mode. I would very much like to have AWK Mode working inside a shell-script-mode buffer. Why not? The MMM solution which appears to be being proposed won't achieve this. I would very much like the option of handling C buffers as MMM buffers, where macros would be handled by a (slightly) different mode from normal code. I'm not sure whether this is a good or practicable idea, but it would be nice to have the option. > 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. No. Our MMM solution should work without imposing restrictions on the major modes. All the awkwardness should be dealt with by the MMM. This is possible. > 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. As I keep saying, we should adapt a solution that doesn't place manacles on hackers. > 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. Then it ceases to be a general low level function and becomes one that can only be called in certain circumstances. This effectively transmits high level state to the low levels, and isn't good software engineering. > 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. This is intolerable. It will lead to twisted code. Why should a major mode need to know "how far to widen"? This is only due to the proposal to misuse narrowing to control regions with different syntax-tables, I think. If these regions are controlled without using narrowing, this and many other problems cease to exist. > So maybe we need something like: > (defvar prog-widen-function #'widen) > (defun prog-widen () (funcall prog-widen-function)) No, we need (widen) like we've had for many decades. > [ 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 -- Alan Mackenzie (Nuremberg, Germany).