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: Sat, 02 Dec 2017 18:47:57 -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> <021066bf-729d-4305-3e09-9b76ba353e0d@yandex.ru> <8352c7cc-a766-6b1f-5e9e-bb0c17256d4c@yandex.ru> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1512258493 18718 195.159.176.226 (2 Dec 2017 23:48:13 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 23:48:13 +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 Sun Dec 03 00:48:07 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 1eLHVu-0004JA-FT for ged-emacs-devel@m.gmane.org; Sun, 03 Dec 2017 00:48:06 +0100 Original-Received: from localhost ([::1]:37279 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLHVy-0001Bw-Ms for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 18:48:10 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58680) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLHVr-0001Bq-Cp for emacs-devel@gnu.org; Sat, 02 Dec 2017 18:48:04 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLHVo-0006t6-9j for emacs-devel@gnu.org; Sat, 02 Dec 2017 18:48:03 -0500 Original-Received: from pmta11.teksavvy.com ([76.10.157.34]:5726) by eggs.gnu.org with esmtps (TLS1.0:RSA_ARCFOUR_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLHVo-0006sf-2b for emacs-devel@gnu.org; Sat, 02 Dec 2017 18:48:00 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2GXCgBqOiNa/wx53mhbHAEBAQQBAQoBA?= =?us-ascii?q?YM8gVSPOo4CAYF8FCABSZgYCoU1BAIChSpEFAEBAQEBAQEBAQNoKIUkAQQBViM?= =?us-ascii?q?FCwsOJhIUGA0kii0Iqg6KWAEBAQcCASWDQYVJgnU2ixkFkxqGIIkyoQuHXJZNg?= =?us-ascii?q?To2I4FNMhoIMIJkgwaBbCOKZwEBAQ?= X-IPAS-Result: =?us-ascii?q?A2GXCgBqOiNa/wx53mhbHAEBAQQBAQoBAYM8gVSPOo4CAYF?= =?us-ascii?q?8FCABSZgYCoU1BAIChSpEFAEBAQEBAQEBAQNoKIUkAQQBViMFCwsOJhIUGA0ki?= =?us-ascii?q?i0Iqg6KWAEBAQcCASWDQYVJgnU2ixkFkxqGIIkyoQuHXJZNgTo2I4FNMhoIMIJ?= =?us-ascii?q?kgwaBbCOKZwEBAQ?= X-IronPort-AV: E=Sophos;i="5.45,350,1508817600"; d="scan'208";a="11025361" Original-Received: from 104-222-121-12.cpe.teksavvy.com (HELO fmsmemgm.homelinux.net) ([104.222.121.12]) by smtp.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Dec 2017 18:47:58 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id E28C9AE0A9; Sat, 2 Dec 2017 18:47:57 -0500 (EST) In-Reply-To: <8352c7cc-a766-6b1f-5e9e-bb0c17256d4c@yandex.ru> (Dmitry Gutov's message of "Sat, 2 Dec 2017 20:01:51 +0000") X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 76.10.157.34 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:220635 Archived-At: > Are you fine with only having prog-first-column variable in Emacs 26? Since Eli only wants MMM-support if it work 100% everywhere, I don't think it matters what gets into Emacs itself in this respect, because the real stuff will have to live elsewhere. The thing we should try and fight for of course are those such as making indent-according-to-mode widen before calling indent-line-function. >> Give that it's introduced specifically so it can be changed, relying ^ ^^ n on >> advice would be a bad idea (especially since the advice would generally >> want to be buffer-local, which is easier to get with a variable). > Makes sense. I'm glad English includes enough redundancy that you could make out what I meant. >>>> - 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). >>> This example will *definitely* need to call indent-line-function. >> Again no, because it doesn't want to modify the buffer. > This one I don't understand: how would you know the indentation is correct > without trying to reindent? The idea is just to highlight those lines whose indentation would be modified by indent-line-function, so you only want to compute the target column and compare it with the current column. >> Arguably `smie-indent-functions` already provides that functionality. > As an example, yes, but it's not like we can move all modes to SMIE. Hence the "arguably": it can be used without using SMIE, but it's not as convenient as you might like. E.g. you can do: (require 'smie) (define-derived-mode ... ... (setq-local smie-indent-functions '(my-compute-indent)) ...) You can even reuse some parts of smie-indent-functions which don't depend on the smie-grammar/rules business, e.g.: (setq-local smie-indent-functions '(smie-indent-fixindent smie-indent-bob smie-indent-comment smie-indent-comment-continue smie-indent-comment-close smie-indent-comment-inside smie-indent-inside-string my-compute-indent)) but the more serious problem is that other packages (such as auto-fill) can't rely on `smie-indent-functions' because it's not used by all major modes. >> Agreed. As far as I'm concerned your proposal is good to go, which is >> why I was talking about subsequent changes. > The current state of the branch, then? Sure. >> BTW, could we get some kind of multi-mode package in elpa.git or >> emacs.git to go along with that (it doesn't have to be fancy, but it's >> important that it doesn't have any submode-specific hacks). > Do you have any particular hacks in mind, in e.g. mmm-mode? No. Can we put mmm-mode into elpa.git? Stefan