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 14:51:54 -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> <3549c65b-e545-bd47-c25b-3a2c1e730804@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512159392 12518 195.159.176.226 (1 Dec 2017 20:16:32 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 20:16:32 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Alan Mackenzie , Tom Tromey , Vitalie Spinu , emacs-devel@gnu.org To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 01 21:16:27 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 1eKrjV-0002oR-I2 for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 21:16:25 +0100 Original-Received: from localhost ([::1]:60629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKrjc-0008ST-4D for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 15:16:32 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57439) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKrLs-0002L9-0Z for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:52:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKrLo-0007EY-4I for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:52:00 -0500 Original-Received: from pmta31.teksavvy.com ([76.10.157.38]:58441) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eKrLn-0007Cn-VE for emacs-devel@gnu.org; Fri, 01 Dec 2017 14:51:56 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EcEQBJsiFa/1rWbkFcHAEBAQQBAQoBA?= =?us-ascii?q?YM8gVSPOo4CAYF8NAGYXYU/BAIChSpFEwEBAQEBAQEBAQNoKIUkAQQBViMFCws?= =?us-ascii?q?OJhIUGA0kii0IqT2KWAEBAQEGAgEli382ixkFkxePS5cnhhCDU4dcmAM3IoFNM?= =?us-ascii?q?hoIMIJkgwaBbCOKYwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EcEQBJsiFa/1rWbkFcHAEBAQQBAQoBAYM8gVSPOo4CAYF?= =?us-ascii?q?8NAGYXYU/BAIChSpFEwEBAQEBAQEBAQNoKIUkAQQBViMFCwsOJhIUGA0kii0Iq?= =?us-ascii?q?T2KWAEBAQEGAgEli382ixkFkxePS5cnhhCDU4dcmAM3IoFNMhoIMIJkgwaBbCO?= =?us-ascii?q?KYwEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,346,1508817600"; d="scan'208";a="10493525" Original-Received: from 65-110-214-90.cpe.pppoe.ca (HELO pastel.home) ([65.110.214.90]) by smtp.teksavvy.com with ESMTP; 01 Dec 2017 14:51:54 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 25AEA61286; Fri, 1 Dec 2017 14:51:54 -0500 (EST) In-Reply-To: <3549c65b-e545-bd47-c25b-3a2c1e730804@yandex.ru> (Dmitry Gutov's message of "Fri, 1 Dec 2017 18:59:04 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.38 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:220588 Archived-At: >> (defvar prog-widen-function #'widen) >> (defun prog-widen () (funcall prog-widen-function)) > I don't know if we need that in the common API, but individual packages can > define such shims if they find that convenient. If we don't add such a thing in the common API, how could individual packages know the boundary of the current chunk without adding MMM-specific hacks? > (defvar cc-mode-inside-indent-line nil) > (defun cc-mode-maybe-widen () > ;; You can also throw in an Emacs version check here, > ;; for good measure. > (unless cc-mode-inside-indent-line (widen))) > And then the "low-level primitives" can call cc-mode-maybe-widen. But just `widen` will do thew wrong thing (it'll widen too much) when we're inside an MMM chunk. >> [ 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. ] > Please elaborate. > How does using a function instead of a variable change the duration when > prog-first-column is set? Having it as a function means you don't have to compute the value of prog-first-column every time to "enter" a chunk, but instead we only compute it if/when the submode decides it needs to know what is the value of prog-first-column. > And when else will we need this value? Here are some examples I can think of: - auto-fill-mode may like to compute the hypothetical indentation that would result from inserting a newline somewhere (and do that before touching the buffer). - some package may like to highlight lines which aren't currently indented right (so, it won't call indent-according-to-mode, but it will need to compute the "desired" indentation). I'm sure there can be other cases. Stefan