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: Fri, 1 Apr 2016 04:15:18 +0300 Message-ID: <654b8ea3-84ea-60d9-6fe1-b088d52579c3@yandex.ru> References: <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> <8d18ba1e-8252-1e6b-2bea-3a0e5e68b052@yandex.ru> <20160329000720.GC5095@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 1459473356 11857 80.91.229.3 (1 Apr 2016 01:15:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 1 Apr 2016 01:15:56 +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 Fri Apr 01 03:15:52 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 1alngl-0005jD-9U for ged-emacs-devel@m.gmane.org; Fri, 01 Apr 2016 03:15:51 +0200 Original-Received: from localhost ([::1]:35330 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alngk-00009v-7Y for ged-emacs-devel@m.gmane.org; Thu, 31 Mar 2016 21:15:50 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40283) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alngS-00009i-Ua for emacs-devel@gnu.org; Thu, 31 Mar 2016 21:15:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1alngR-0004YN-BB for emacs-devel@gnu.org; Thu, 31 Mar 2016 21:15:32 -0400 Original-Received: from mail-wm0-x232.google.com ([2a00:1450:400c:c09::232]:37669) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1alngM-0004X4-Vj; Thu, 31 Mar 2016 21:15:27 -0400 Original-Received: by mail-wm0-x232.google.com with SMTP id p65so3946123wmp.0; Thu, 31 Mar 2016 18:15:22 -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=2udits/99hy2gJH5zb29K0wHhZL/LbeSceTv3Vo3vwk=; b=Y7mq75vLjhDD7NII+OHKXdIeyAmgdAe8ddlF9s7ssrrB8Pj8+yDjo2PkhUyu6mYHxj ccImd623/7njxtKOXCu1qGAugtlXU+E1P2josmsl7ZC1F/LdoB68jqPErtdf0jD7jRtV Ow1wZHHmM8EX14IDM8JLNXISg5e4s47xFpEhfko6YsPDEb1z0XxGRJlyZZvYp1Qon8R8 MG/sBW07tlCizGvkxy/LPQ10NYwJ7s3SIgw6ob/DYt81ytIvHFS986xtbSQgLEF43xUf 3dhOe1sK+sFd3qUAfz1cm2kbVMSH8UB3Jmc0Ue+Po3aR8wIvSkY7rM1KOV7gu7xrG7eq dfuQ== 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=2udits/99hy2gJH5zb29K0wHhZL/LbeSceTv3Vo3vwk=; b=AditPFIasdUh2EUGgzjIXeCj7GxG6JZJWxBFuMgZRMO0gnDjKsVYRZs+Nk9qeK0Ofb pf3GhUTnTp7Wf6c16uV6SCcyL+VaSrP9QgyAkCeOtg+2L+gVisYN/mCW435mmc1QPRJn JS1NChmEoCmSENub1l0intWH6D4GKtf1xov8pi6jtjDSTk8/NOsyFI6et+G8MFUtJLE6 qqNtYF+BvKHK2GuuJoMw3wgJ6xwQeis/DlCP0TPi8A79nlxWqFUCTbw+FEMxFfextx9T ANPwWq0pO/LUyPbSdD8n30hUTOS7bsKDA/OjCe5Nv6P/Xn5edIlyC86OW2BBsn9kFd4n sTPA== X-Gm-Message-State: AD7BkJJO+o9JgS3YipHD4JzbmfT62qGHZqR+D7sKNrjzJLWTmbyiQDQTud4ImtPA1clBKw== X-Received: by 10.194.89.2 with SMTP id bk2mr6088162wjb.39.1459473321957; Thu, 31 Mar 2016 18:15:21 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id hx10sm11487875wjb.25.2016.03.31.18.15.19 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 31 Mar 2016 18:15:21 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160329000720.GC5095@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::232 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:202544 Archived-At: On 03/29/2016 03:07 AM, Alan Mackenzie wrote: >> E.g. (goto-char (match-end n)) is a common >> idiom for syntax highlighting and indentation code. > > Yes, but that match is going to be in the same island, or at the very > least, in the chain of islands containing the current one. Would looking-at skip over intermediate islands? Basically, I wonder if (= (+ (match-beginning 0) (length (match-string 0)) (match-end 0)) is going to always hold in that new world. > Are you thinking more that `forward-char' should move from the end of an > island to the beginning of the next island in a chain? As one option, yes. Let's call it option A, and it entails renumerating buffer positions to avoid gaps. >> True. I'm more worried about gaps. But they could be treated like >> whitespace, I suppose. > > For example, by `forward-char'? What primitives were you thinking of, > here? This would be option B. forward-char doesn't care if the characters are whitespace or not. I don't know if e.g. search-forward would see the contents of the intermediate islands as a bunch of actual space characters (it's something to consider). Most importantly, the contents of intermediate islands would match "\\s-", and parse-partial-sexp would similarly skip over them. >> Right. So then, some yet-unknown body of code has to become >> island-aware, and the improvement is not that seamless anymore. > > The way I see it, the super modes would have to be totally aware of the > island mechanism, but the major modes would be largely, it not totally, > unaware of it. `syntax-ppss' seems more part of the super mode > mechanism. At the very least, that does sound somewhat complicated. >> 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? > > A different island local binding would become current, so yes its value > would thereby change. Much like if var had a buffer local binding, and > you do (set-buffer "foo"), the value of var you'd just set would no > longer be in the current binding. if xx is in the same island, the > binding just setq'd would remain the same. That might be something to look out for. Changing a buffer is an operation with big consequences, we know that already, but using goto-char didn't have too many implications until now (aside from point-entered hooks, I guess, which are being phased out). >> I don't think either should be true. Then, the "adequate" model would >> amount to changing them in post-command-hook anyway. > > What sort of variables are you thinking about here? [ Some time later:] > Could it be that it might be better to have "island chain local" > variables rather than merely "island local" ones? mmm-mode has both kinds. > So that the three ruby > lines in your example below would be three islands in a chain, and would > thus all share a set of "island chain local" bindings rather than each > line having its own binding? Yes, probably. But that doesn't solve the above concern. >> 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? > > By "related", I think you mean the same thing I meaan by "chained" - the > three ruby mode lines enclosed in <%...%> in your example below, would be > chained together by the super mode. Yes, we can call them chained. As long as it doesn't imply anything about any presence of islands of other types between them. >> 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. > > The question seems to be, are we indenting in the super mode or in each > island? The answer seems to be you'd want to indent in the super mode > here, I think. Indentation in the super mode would look like this: <% if foo %> <%= bar(boo) %> <% end %> which is not what we'd really want. But yes, a good solution would take html-mode's indentation logic as a base, and modify it with the indentation offsets provided by the islands. >> 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. > > Two? Don't you mean three, here? Is this a minor mistake in your > counting or am I missing something important because I don't grok ruby? The mistake would be mine, but really, I'm just talking about the first two. We're discussing the indentation of the second line. The third one is just here to make the example look more complete. >> The "not chained" idea would require some explanation. > > For example, islands in a shell script which were individual AWK scripts > would not be chained together. But the three (?two) lines of ruby in the > example above would be chained together. I think we need to work this > out more precisely. Makes sense. > For example, in the three ruby line scenario above, is there any variable > you can think of for which it would be advantageous to have a binding > for each island rather than a shared binding for the set of three (?two)? Not off the top of my head. Maybe there's none. > I'm kind of envisioning successive `forward-char's moving from the end > of "<% if foo %>" to the beginning of "<%= bar(boo) %>", or even from > the end of "if foo" to the beginning of "bar(boo)". How does this sound? Sounds like what I've calling option A above. Basically, my vague concerns are: - Performance (checking islands boundaries in each primitive must incur overhead, even when there are no islands). - Code complexity: new code paths that might be exercised not very often in the future. Hence, they could be prone to breakage. A dedicated test suite would help with that, though. Also, think back to the problem of the absence of newlines in the Ruby islands in the above example. The indentation engine needs them, and it might be harder to make newlines appear both inside and outside of the Ruby islands (the html-mode indentation code needs them too, I'd wager). This is where option B has another advantage, aside from (probably) being easier to implement.