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: Wed, 6 Apr 2016 01:52:23 +0300 Message-ID: References: <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> <654b8ea3-84ea-60d9-6fe1-b088d52579c3@yandex.ru> <20160405162928.GD3463@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 1459896767 16442 80.91.229.3 (5 Apr 2016 22:52:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 5 Apr 2016 22:52:47 +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 Wed Apr 06 00:52:42 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 1anZpw-0003EH-Rk for ged-emacs-devel@m.gmane.org; Wed, 06 Apr 2016 00:52:41 +0200 Original-Received: from localhost ([::1]:39692 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZpw-0006vR-7q for ged-emacs-devel@m.gmane.org; Tue, 05 Apr 2016 18:52:40 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50483) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZpq-0006qF-Ed for emacs-devel@gnu.org; Tue, 05 Apr 2016 18:52:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1anZpp-00031U-0c for emacs-devel@gnu.org; Tue, 05 Apr 2016 18:52:34 -0400 Original-Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]:35739) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1anZpj-0002ut-4W; Tue, 05 Apr 2016 18:52:27 -0400 Original-Received: by mail-wm0-x22b.google.com with SMTP id 191so39359795wmq.0; Tue, 05 Apr 2016 15:52:26 -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=RukdFnK/Fbt0arEm6rrQxpRVl6KTOJTf2O5cAqlmppY=; b=L7b8N2Vw9MVgAOKUam9fFO+2TUUUyX4yXanSM0LlaN5y2Nnp2f9YHSIC5dNrFJbvAt RFU0EwjbXtgIgwIpekIP2qhC1WJ1RwINaEScle0dRJH9skgjZDDx/hSsAcmtUlRTdg3/ 9VlEWFVNlOTaGTJOzs/SSWN42geIR0V8IMlO/nbC/4OQzJ+h89brplryg/uGxrIgvsww Tr9ff1jusYMYhNtPsVhcyWDSNe5aRuM9ngCBNTtn5izT/Bfi7jRx9p/sBY9ug1Srecpn lFY4O5MdU8id9oSaYoKaTSGuGaQKVTUgVWC3kxW7A8BFhqaOuCLpAHg2GfZseODGRAXu fH5w== 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=RukdFnK/Fbt0arEm6rrQxpRVl6KTOJTf2O5cAqlmppY=; b=bjrFSQA0FJVzj/kHN22rILoLbGRyYtgIy5QSPUbJviyHKKiqxIGA5vgYwJ9KykLRp5 ueCdNC/wuNMXVwBK92jlwIXkWN/Me6D5IFr6jdsAHlLH/o7f9I4X4/GsTP1ndUznAzMC 0CDfsJNAKhRf0oBmGaApeL2Vg34KCVemjdVqaPbE+TbxKRNNrBKYoZmm1OFypKTYQEcg oofTWdPPOFH0LmNtHdEUFdjAX/1YETKgeh6xxNB+uLjWjYB+fVr3Bp+kve5GX8g07QhY 0dT0nUQ3PHf0mtxWfben9U5SAth7ES0O7olWmCVOBqrbXOJEDGNfBypGPyQ9vUXdmxKV eniA== X-Gm-Message-State: AD7BkJI64WdSoI+fVExJqy1oezxBi6+uSidtXfnvs7OEYHcsNalk5u6ig2SuSjXxhPjH4w== X-Received: by 10.28.23.70 with SMTP id 67mr20334330wmx.70.1459896746345; Tue, 05 Apr 2016 15:52:26 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id x2sm25427567wjr.33.2016.04.05.15.52.24 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 05 Apr 2016 15:52:25 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 In-Reply-To: <20160405162928.GD3463@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::22b 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:202758 Archived-At: Hi Alan, On 04/05/2016 07:29 PM, Alan Mackenzie wrote: >> As one option, yes. Let's call it option A, and it entails renumerating >> buffer positions to avoid gaps. > > I'm solidly against using alternative buffer positions. The unforeseen > side effects we'd have to cope with would be excessive. The machinery > we'd have to set up to convert from "real" offsets to "no gaps" offsets > would be horrendous. That's my expectation, too. > There's no reason forward-char shouldn't jump to > the next island in a chain without renumbering buffer positions. > (Assuming `restrict-to-island' has been bound to non-nil by the super > mode.) s/shouldn't/couldn't; I'm not sure it should, actually. forward-char doesn't normally skip over syntactic whitespace. > When the key variable `restrict-to-island' is bound to non-nil, things > like search-forward would skip over islands. Otherwise it would see the > insides of islands. The latter would be what a user doing C-s would > normally want to happen. Maybe seeing inside islands is not that terrible. Good code should check syntax-ppss anyway, even if it finds a match inside a foreign island. > parse-partial-sexp would always > save its state on encountering the start of an island, and restore it at > the end of the island. Sure, OK. Or it could just treat the foreign islands as comments, and avoid creating a stack of states. Whichever way is easier to implement. > For the island itself, it would set the state to > that at the end of the previous island in the chain, or to "nil". Are you thinking of syntax-ppss instead? The return value of parse-partial-sexp must has to depend on where is the start position. Although if it uses a stack of states internally, it will be easier for syntax-ppss to work with (syntax-ppss would be able to reuse cache points within islands foreign to the current one). > I think thinking of it as "changing the value of a variable" is a clumsy > way to regard it. "Accessing the correct binding for the current buffer > position" is more how I would describe it. Any way we call it now will essentially be a post factum rationalization if a programmer is surprised by the behavior. I'm describing the behavior. Maybe it's not too bad, IDK. >>> 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. > > Maybe, but having two extra kinds of locals is more than twice as > complicated as only having one. "island chain local" variables are used a lot more often than the "island local" ones, in mmm-mode. > I think "the above concern" was about the lack of newlines in the three > ruby lines of the example, and the difficulties this would cause > indentation. One thing we could do is to make an island syntactically > equivalent to a newline for the enclosing code. Maybe. Yes, it doesn't sounds like a natural solution. Adding a newline in the middle of a line might change the meaning of an expression, or at least throw off some heuristics we're using in indentation code. > But we'd surely be happy enough with > > <% if foo %> > <% = bar(boo) %> > <% end %> Not really, no. That's just not how ERB is traditionally formatted. And see below (note how the HTML tags, which belong to the superior mode, are indented an extra level when inside <% if ... %>...<% end %>). EJS and JSP are also formatted similarly. > As a matter of interest, is it really likely that users will type in > embedded ruby code with <%...%> delimiters around each line, rather than > one pair around, say, a function or an entire program? The latter would be an exception. Here's a real-life ERB example: https://github.com/swanson/stringer/blob/master/app/views/archive.erb >> - 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. > > If the abstraction we're talking about is sound, then the code complexity > will be manageable. People cope with buffer local variables, people cope > with the regexp engine searching for syntactic things. Yes, a sound abstraction is key.