From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls Date: Sat, 2 Dec 2017 20:01:51 +0000 Message-ID: <8352c7cc-a766-6b1f-5e9e-bb0c17256d4c@yandex.ru> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1512244926 12895 195.159.176.226 (2 Dec 2017 20:02:06 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 2 Dec 2017 20:02:06 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0 Cc: Alan Mackenzie , Tom Tromey , Vitalie Spinu , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 02 21:02:02 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 1eLDz8-00033Y-0Q for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 21:02:02 +0100 Original-Received: from localhost ([::1]:36795 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLDzF-0002Kw-De for ged-emacs-devel@m.gmane.org; Sat, 02 Dec 2017 15:02:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38860) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eLDz5-0002Kf-3F for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:02:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eLDz2-0001BT-0z for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:01:59 -0500 Original-Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:36509) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eLDz1-0001AA-Pw for emacs-devel@gnu.org; Sat, 02 Dec 2017 15:01:55 -0500 Original-Received: by mail-wm0-x234.google.com with SMTP id b76so8358355wmg.1 for ; Sat, 02 Dec 2017 12:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=iFrjmGwUs3tz4ZNd/5g5dgOHrvKV4CjemSCFNBNEXH4=; b=ite5WkUVhh7I3JA6GjAMF9eHbzZslQBG23eGCq7uiVKbXBgNWuJuxgBWDVPf28ucYe NCaHKxM0+YKjZo+cPLq7Cnl3wDBmqj+bHuipUtgNru3NbcTVFAiWIdO2yrFhEPYdwKOA M8VTC5ogTW6vnqJN33XvrL/b2bev0bC89N2/TVOmYNHD8eHLd3CgP5aPykWZJ5mqKy5i 5BG/8B48BusgzUbW2UwNyXN0cOVHBIMFdS56fjUKScZUfUFb2ilB4hrOSR1Kkp54GI5R yC/Efhs1Bq4fk+pzCedrf3VpMMfdSX07jl7oXwAhakATDZaZBMSYj8O3AovcsnUL/Y6p TDXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=iFrjmGwUs3tz4ZNd/5g5dgOHrvKV4CjemSCFNBNEXH4=; b=um5sDyromSfUTVE5xtshhqzeyukYli2yx8S4r4UHdAaZp4zcVFBK16zqYPFFIBu3EB xT/xzSv2gUh34a+3ny+7MhhTkbjzgiqJ3+mgGA5iYoegWrWak96HHQPf9QgD6ywK7O/v Fd+9vpP+7INXF7o7kI4H7r5gvgHTqez8w0Nw9ZInnkHXt1y3J8uhD+xh1KVN+tPvNioK y8TuPsBRjwES4NFvxmsF7UBbbh/gOcdfE5Veawz0qf+dqhoLLn5AGuWiXxO/UnHAnjG4 DlxPiMX0PCZ6yrb+RTMYjC/P9a5cyUGdOzyy7bLBKsRNc2T9Ckq40VNb5E5meOHAJEGs pkhg== X-Gm-Message-State: AJaThX4lUplKL65Dze2m0ltmGo5n/pcZuTcufFAMyVmswBHdvVkvzmaG xDkG+M5r/veH+TjiOedE3fs2mxVz X-Google-Smtp-Source: AGs4zMZF4HfEs4ClPdP0KI0ev+iVfIpnRUbEpopYrCaBkiaWp3p1lQQGOHudnoReT/F+rD0RrQP+Rg== X-Received: by 10.80.147.93 with SMTP id n29mr23106181eda.237.1512244914159; Sat, 02 Dec 2017 12:01:54 -0800 (PST) Original-Received: from [10.252.20.95] ([157.157.58.170]) by smtp.googlemail.com with ESMTPSA id e25sm3182337edc.64.2017.12.02.12.01.52 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 02 Dec 2017 12:01:53 -0800 (PST) In-Reply-To: Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:400c:c09::234 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:220627 Archived-At: On 12/2/17 2:24 AM, Stefan Monnier wrote: > But widening/narrowing to the current chunk might be needed for commands > specific to the major-mode, hence commands which the MMM framework > doesn't know about (and hence doesn't wrap like it does for > indent-line-function). Depending on whether the major mode is the "primary" mode or a "submode", some commands might prefer no resrictions, and some the current chunk. font-lock, on the other hand, will (almost?) always want to use the current chunk. And only the MMM framework knows whether the mode is primary or not. So the issue is not that obvious. >> You probably mean adding a variable prog-first-column-function, then? > > Right. Are you fine with only having prog-first-column variable in Emacs 26? Adding prog-first-column-function without having something similar for chunks would seem inconsistent. > Give that it's introduced specifically so it can be changed, relying > 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. > No because indent-line-function would actually perform the > re-indentation, whereas we only want to calculate the hypothetical new > indentation column. See `smie-auto-fill`. I see. >>> - 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? >> And both of them should be solved by exchanging indent-line-function for >> (non-mutating) line-intentation-function. But that's a change for >> another day. > > Ah, yes, that would be a good change. > Arguably `smie-indent-functions` already provides that functionality. As an example, yes, but it's not like we can move all modes to SMIE. >> I'm sure there can be. A complete proposal to let the modes know chunk >> boundaries, etc, has yet to be finalized, however. And just having font-lock >> and indentation work reliably in multi-mode contexts will >> be a significant win. > > 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? > 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? > Maybe a generalization of mhtml-mode, That might actually be possible, a kind of mixed-mode builder.