From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Mon, 28 Mar 2016 01:59:21 +0300 Message-ID: <8d18ba1e-8252-1e6b-2bea-3a0e5e68b052@yandex.ru> References: <8737riqouj.fsf@gmail.com> <221845e0-b194-433e-bfbc-105272ae5752@default> <87twjyp21k.fsf@gmail.com> <56F242E0.7060004@online.de> <877fgtpfrw.fsf@gmail.com> <20160323211605.GA5324@acm.fritz.box> <20160324183835.GB2721@acm.fritz.box> <20160327120919.GA2682@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1459119575 19357 80.91.229.3 (27 Mar 2016 22:59:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 22:59:35 +0000 (UTC) Cc: Vitalie Spinu , =?UTF-8?Q?Andreas_R=c3=b6hler?= , emacs-devel@gnu.org, Stefan Monnier , Eli Zaretskii , Drew Adams To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 28 00:59:34 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1akJeg-00033A-An for ged-emacs-devel@m.gmane.org; Mon, 28 Mar 2016 00:59:34 +0200 Original-Received: from localhost ([::1]:37703 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akJef-0006JA-5e for ged-emacs-devel@m.gmane.org; Sun, 27 Mar 2016 18:59:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55041) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akJea-0006J4-Uy for emacs-devel@gnu.org; Sun, 27 Mar 2016 18:59:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1akJeX-0003iS-Ni for emacs-devel@gnu.org; Sun, 27 Mar 2016 18:59:28 -0400 Original-Received: from mail-wm0-x241.google.com ([2a00:1450:400c:c09::241]:35064) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1akJeX-0003iJ-CE; Sun, 27 Mar 2016 18:59:25 -0400 Original-Received: by mail-wm0-x241.google.com with SMTP id 139so11068856wmn.2; Sun, 27 Mar 2016 15:59:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-transfer-encoding; bh=r1mkjiuDUi9k/ynioAwUZrb9D643Xk3gP1hx8wo0tz4=; b=EMee8U5CEIbLoBk74AEwQeXZqgTPAu7cmttvNVrsT9XPIeV0OZVTO/atB8o0CsANkr fGwOwSCO8Qt2LuCg8EWJvq0ledZ8gfmL1L+Ie1p4Zo5Ot3+wfDEOftAbJFaxW0nU66nq XzyFaW+0zvN1RdStVfENJRkxOUv9r+XVtWBBtj3mGKHqyXcE/0Kf8ameWz4WtH2EomIv GYStK3lkJMmzUjJ5lVjsiq6BykFERDqJHCItZ4HIAtefC3dfZxdmbBe/vaTu7UmCownk Zxk+uP2hXHebP3jQAl7WFHNwa9qJlKLZ0XHhV3PVU4sLMHrz55d2H4kRdwcuFjO4CKGr eX4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:to:references:cc:from:message-id :date:user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=r1mkjiuDUi9k/ynioAwUZrb9D643Xk3gP1hx8wo0tz4=; b=QPvRA9osqmVLjZM55mQTUBRlK0zlfKsHCUzdEKTGLJnXy9spBHP98HHlNdXqxlb8ZX qutuzIuRVq5qkE2Hn4Ce9g12quUDmYN4nmhpA7A4szcamqnX3itvJ97gn0W0I4/eyrav gIASbkDNFhDeuj4h/NoPSbY08ZwbRWPh+BXDz8Vl9rqmAEAXTDFoYmlnoUESIsybN1UA OqcIlHrxomcEDiOLcsChbYu1fkVGCwuK7knD1J/Yp9GqUlZimBZmnboTIi7cNh63tfVH tyO+jdF22250QmyVkKDaJJM4y782bYUBs8ULH5p4PPUxGEgJalMy4DgdK0UpT5AJlWFo IrQg== X-Gm-Message-State: AD7BkJJDfjGUwM0K7uGTcy/sJgl4UjSGqgheSxWiUPI3fe0+K0sOYQyJJ4RrvoPTnsuZ8A== X-Received: by 10.28.35.16 with SMTP id j16mr7844985wmj.78.1459119564212; Sun, 27 Mar 2016 15:59:24 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id 73sm7577656wmy.22.2016.03.27.15.59.22 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 27 Mar 2016 15:59:23 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160327120919.GA2682@acm.fritz.box> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::241 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:202311 Archived-At: On 03/27/2016 03:09 PM, Alan Mackenzie wrote: > I can't really see a proof of concept happening. Either the thing is > implemented or it's not. There's hardly a half way point. "Full implementation" would work, too. But it would still be considered a prototype. Point is, we can't really decide whether we'll end up using it, before trying it for a while. >>> That will require more investigation. But syntax based searching and >>> regexp based searching will certainly be amongst them. I don't think that's enough. E.g. (goto-char (match-end n)) is a common idiom for syntax highlighting and indentation code. >> [island-affected primitives] > looking-at? Probably. > char-after? No. > syntax-after? No. (This works only on a single char, hence must be in a > single island, it can't span two.) > forward-char? Maybe. In fact, there's a good argument for not moving > forward when `forward-char' hits an island boundary. Being confined to the current island is not what I had in mind. If that's the idea of how such primitives would work, I don't really see a lot of benefit over using narrowing around all those calls. >> Speaking of the last one, will the buffer positions, as visible to the >> submode code, be renumerated, or will they have gaps? > > It would retain the global buffer position, for consistency with the rest > of Emacs. For example, in narrowed buffers, the position relative to > point-min is never used. True. I'm more worried about gaps. But they could be treated like whitespace, I suppose. >> Depending on your answer to the previous question, even simply inserting >> text inside one of the preceding islands might make syntax-ppss-cache >> out of date in the current island. > > That could probably be solved by making positions in that cache relative > to the beginning of the island, and things like that. I think you'd want > to make `syntax-propertize--done' island local, too. Right. So then, some yet-unknown body of code has to become island-aware, and the improvement is not that seamless anymore. >>>> Next, at which points exactly would Emacs look at the island boundaries >>>> and change the island-local variables to the values set in the current >>>> island? Probably not after each point movement. In post-command-hook? >>>> That's also already done. > >>> It wouldn't use any high level facility like post-command-hook. The >>> mechanism would be more like a buffer local variable, entirely handled >>> by the C level, so that such a binding would simply exist. > >> You didn't answer my question, though. When will the bindings apply? > > Sorry, an island local binding would be current when point is within that > island. Or, perhaps there could be some variable which would be set to a > position to do this job. What if var has an island-local binding? And my function has this: (setq var 1) (goto-char xx) ; where xx is in a different island will its value change mid-program? What if xx is in the same island? Will the value change then? I don't think either should be true. Then, the "adequate" model would amount to changing them in post-command-hook anyway. >> I don't know if we'd need the island-beginnig/island-end accessors in >> your proposal. > > I think we would. (narrow-to-region (point-min) (point-max)) is a null > operation. If the major mode has narrowed, and needs to set point-min to > "1", it will need to know the island-beginning, somehow. What if it just calls widen? >>> If you "whitespace" a region out, you've got to remember >>> the text properties that were there originally, and restore them >>> afterwards. There's no easy way to do that. > >> I think it's doable using char-property-alias-alist. The multi-mode will >> define its own property as an alias of `syntax-table', and then put it >> on and remove it from text at will. > > I don't think that would work at the moment. syntax-table text > properties would take priority over syntax-table-1 properties. Something > similar to char-property-alias-alist, but giving syntax-table-1 priority, > would need to be implemented. You're probably right. > It would relieve super modes of the tedious necessity to maintain island > local variables using functions in post-command-hook, and things like > that. They'd still have to maintain the island boundaries. And the lists of variables to set island-locally, or mode-locally, or chunk-locally. That constitutes the majority of the related code already. > It would not be necessary to use widening and narrowing to > restrict indentation/fontification code to an island. So making it seem, to the Lisp code, like the multiple related islands don't have anything (for some definition of "anything") between them is not a priority? That would be the high point of the "islands" idea from my perspective. But having only some primitives affected would likely break this use case. Here's an example of ERB code Vitalie brought up recently: <% if foo %> <%= bar(boo) %> <% end %> The parts of the buffer between %'s would be Ruby islands. The suggestion was to use the value returned by the indentation function in the second island (second line) to indent the "real" buffer contents. But: neither of the islands contains a newline. If they are combined in the most straightforward way, the Ruby line will be 'if foo bar(boo)', and its indentation would be not what we're looking for. I think the current ways to look for a newline, (progn (skip-syntax-backward " ") (eq (char-before ?\n)) or (looking-at "\\s-$") will fail to work. Also note that neither of the two islands in this example contains the newline in question. To sum up, hard examples are hard. And yet, the new feature should make some use cases possible that were impossible before, not just allow for easier island-local variables. > I don't think having islands start at position 1 is a good idea. But > having the relevant primitives skip the gaps between chained islands, and > stop at an island boundary when not chained, when `restrict-to-island' is > non-nil, would be a central idea. The "not chained" idea would require some explanation.