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: Fri, 1 Dec 2017 20:50:02 +0000 Message-ID: <021066bf-729d-4305-3e09-9b76ba353e0d@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> 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 1512161500 6511 195.159.176.226 (1 Dec 2017 20:51:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Dec 2017 20:51:40 +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 Fri Dec 01 21:51:36 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 1eKsHT-0001DM-Q9 for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 21:51:32 +0100 Original-Received: from localhost ([::1]:32811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKsHb-0004FW-43 for ged-emacs-devel@m.gmane.org; Fri, 01 Dec 2017 15:51:39 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35713) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eKsGJ-0004BL-ED for emacs-devel@gnu.org; Fri, 01 Dec 2017 15:50:24 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eKsG7-0004Fz-1c for emacs-devel@gnu.org; Fri, 01 Dec 2017 15:50:19 -0500 Original-Received: from mail-wm0-x234.google.com ([2a00:1450:400c:c09::234]:40073) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eKsG6-0004EB-Pa for emacs-devel@gnu.org; Fri, 01 Dec 2017 15:50:06 -0500 Original-Received: by mail-wm0-x234.google.com with SMTP id v19so5439279wmh.5 for ; Fri, 01 Dec 2017 12:50:06 -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=OWtS64xBCKtyNKcpqBrgUK9Mg/N7csSF7woDOMvmKbs=; b=eiYfjFLMUYeNDvQ/lKbqXKpZXu8yt+TRT0lfpmHfu67CQKFfO7wu3+HbWZMRkI+7ri 4nAgv1JLfYygXy5utj9rD80z4LkRWFz7SVQmPBbvrT4sckryxbDwWdPYxut9Od3u6Z7R tYPS8lN0QoRSajRLRSqIvt5/EesoPAPWcbBG9fhJvBiuzzG9PqUu+OaeaF42Jiv0DjEv LtPmcUS7NuTDG0iv4I8LYS4akuGoJDBjhGIzA+rp+ZlUWHCA6y9RoD84/BV1mOQYPyls jStRwzqHpx/yz9t/2CmnerMeUzhwI9SHavceB5EXBvp20lx+Np/4SbN7BjOLVcLnRkXJ QpZA== 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=OWtS64xBCKtyNKcpqBrgUK9Mg/N7csSF7woDOMvmKbs=; b=blcSFbCDtkLGOV5PHp2/ObGktoj7uphP+FrfOAmTUeelfPTBfp95MJDb8Q5RCr5jEh 7QgdoXs4U4KeXRYs2HNAoAWhUBsvfgURFkSC/e39CoEBz2eo57qqYwHXBLshceTwxXSA QxINOa/2w6mBhKtu50aSdg26nBxqe+PWcEIHwyiCweTrTI5fC1DBhMATJq9WZqZHXISP ffob/7NWfntvxTIXICunGcAPq4OQQbFTuxpFCn8/hM4/EVW/P6h+/VapUWZv69cMoTIn TFk9FTh2Li6BMNA+qNEaJ095uNwr2vLL98ap1hDX2J3ymgNn4G/4tHo043OEklahu12j JRJw== X-Gm-Message-State: AJaThX6/e2U3hhd9SI0niDZLjn9kXbXp+A8AGsow2oT8aKTzu45zH8Nw ug9DX7JMMBJeemwEIsFUsqw= X-Google-Smtp-Source: AGs4zMbXcO18nrJLXTDstJqaMkZmNPAi99YTWlJ5aer9DoUlLhuy+nqt7AJEsruocCqYlTadFSAf3w== X-Received: by 10.28.216.212 with SMTP id p203mr2240508wmg.50.1512161405521; Fri, 01 Dec 2017 12:50:05 -0800 (PST) Original-Received: from [192.168.1.38] (89-160-235-67.du.xdsl.is. [89.160.235.67]) by smtp.googlemail.com with ESMTPSA id x185sm1918615wmx.12.2017.12.01.12.50.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Dec 2017 12:50:04 -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:220591 Archived-At: On 12/1/17 7:51 PM, Stefan Monnier wrote: >>> (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? The idea for multi-mode packages has always been to make do without making the major modes actually aware of hunk boundaries. And the snippet of code won't make them aware either, since the chunk boundaries are conveyed via narrowing only in particular dynamic contexts, such as when indent-line-functions is called. Adding other means too might make sense, but that's expanding the scope of the current proposal. I'd rather make it small and try to get it into Emacs 26. >> (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. Yes, so CC Mode primitives all should call cc-mode-maybe-widen. Having them call prog-widen vs widen is very much the same difference. > 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. You probably mean adding a variable prog-first-column-function, then? Or will we expect multi-mode packages to simply advise the prog-first-column function? I'm fine with that. >> 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). Won't it need to call indent-line-function to find out how much the next line should be indented? > - 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. 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. > I'm sure there can be other cases. 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.