From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: A vision for multiple major modes [was: Re: [Emacs-diffs] widen-limits c331b66:] Date: Mon, 18 Apr 2016 21:32:26 +0000 Message-ID: <20160418213226.GA4687@acm.fritz.box> References: <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=us-ascii X-Trace: ger.gmane.org 1461015191 8926 80.91.229.3 (18 Apr 2016 21:33:11 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 18 Apr 2016 21:33:11 +0000 (UTC) Cc: Vitalie Spinu , Andreas =?iso-8859-1?Q?R=F6hler?= , emacs-devel@gnu.org, Stefan Monnier , Eli Zaretskii , Drew Adams To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 18 23:33:02 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 1asGmz-0003L0-Kx for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 23:33:01 +0200 Original-Received: from localhost ([::1]:45735 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGmy-0004k8-UM for ged-emacs-devel@m.gmane.org; Mon, 18 Apr 2016 17:33:00 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46284) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGmk-0004fI-8d for emacs-devel@gnu.org; Mon, 18 Apr 2016 17:32:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1asGmg-0000Hm-RD for emacs-devel@gnu.org; Mon, 18 Apr 2016 17:32:46 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:64247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1asGmg-0000Gm-Il for emacs-devel@gnu.org; Mon, 18 Apr 2016 17:32:42 -0400 Original-Received: (qmail 31824 invoked by uid 3782); 18 Apr 2016 21:32:41 -0000 Original-Received: from acm.muc.de (p5B1471E3.dip0.t-ipconnect.de [91.20.113.227]) by colin.muc.de (tmda-ofmipd) with ESMTP; Mon, 18 Apr 2016 23:32:40 +0200 Original-Received: (qmail 5812 invoked by uid 1000); 18 Apr 2016 21:32:26 -0000 Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 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:203075 Archived-At: Hello, Dmitry. Sorry this reply has taken so long. I've been preoccupied with things in real life. On Wed, Apr 06, 2016 at 01:52:23AM +0300, Dmitry Gutov wrote: > Hi Alan, > On 04/05/2016 07:29 PM, Alan Mackenzie wrote: > > 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.) I've now renamed `restrict-to-island' to `in-islands', because it's shorter to write and read, and also with the "s", it's more accurate. > s/shouldn't/couldn't; I'm not sure it should, actually. forward-char > doesn't normally skip over syntactic whitespace. I think I agree with you here. All the searching and skipping commands will have to be considered. For example, under what circumstances should skip-syntax-forward skip the gap between two chained islands? I'm coming round to the idea that both a "foreign" island and a gap in a chain should be treated as a single unit of whitespace, and should match "\\s-" - and possibly "[[:space:]]". > > 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. I'm thinking of major modes searching for somethingi, rather than users' searching. > > 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. No, it can't treat a foreign island as a comment, since its end point might be inside that island. [ .... ] > 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 it must use a stack of states. > > 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. Most programmers will be working on major modes, or things like them, so the bindings will stay the same. I'm hoping there won't be surprises there. [ .... ] > > 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. I now think this is a tangent to the discussion. Whatever solution is settled on, it will probably be a part of a particular super mode (? ERB Mode??) rather than part of the island mechanism. I now don't think that that newline idea was good. [ .... ] > > 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 Thanks. I've downloaded it. > >> - 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. I'm writing a more detailed outline of the island idea. I hope to post it on emacs-devel in the next day or two. There are two things I'm currently unhappy about - (i) That buffer local variables (as they are now) will need to be rigidly classified as either ones which would be island chain local, or ones which would be entire buffer variables. This applies particularly to variables defined and used in the C code; (ii) It's looking like major modes will explicitly have to bind `in-islands' to non-nil when their commands are executed. -- Alan Mackenzie (Nuremberg, Germany).