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: some design notes Date: Thu, 21 Apr 2016 09:14:37 +0000 Message-ID: <20160421091437.GB1775@acm.fritz.box> References: <20160420194450.GA3457@acm.fritz.box> <87vb3blxux.fsf@russet.org.uk> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1461234756 4470 80.91.229.3 (21 Apr 2016 10:32:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2016 10:32:36 +0000 (UTC) Cc: emacs-devel@gnu.org, Dmitry Gutov To: Phillip Lord Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Apr 21 12:32:27 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 1atBuM-0001Gw-Hw for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 12:32:26 +0200 Original-Received: from localhost ([::1]:38695 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atBuI-0003kZ-Br for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 06:32:22 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35162) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atBty-0003Ug-1r for emacs-devel@gnu.org; Thu, 21 Apr 2016 06:32:03 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atBtu-0001yx-Qk for emacs-devel@gnu.org; Thu, 21 Apr 2016 06:32:02 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:26224) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atBtu-0001xe-Ha for emacs-devel@gnu.org; Thu, 21 Apr 2016 06:31:58 -0400 Original-Received: (qmail 98991 invoked by uid 3782); 21 Apr 2016 10:31:56 -0000 Original-Received: from acm.muc.de (p548A5630.dip0.t-ipconnect.de [84.138.86.48]) by colin.muc.de (tmda-ofmipd) with ESMTP; Thu, 21 Apr 2016 12:31:55 +0200 Original-Received: (qmail 3767 invoked by uid 1000); 21 Apr 2016 09:14:37 -0000 Content-Disposition: inline In-Reply-To: <87vb3blxux.fsf@russet.org.uk> 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:203142 Archived-At: Hello, Phillip On Wed, Apr 20, 2016 at 11:27:34PM +0100, Phillip Lord wrote: > A few comments, rather than an in-depth analysis, am afraid. Thanks! > Alan Mackenzie writes: > > (iv) Islands. > > o - An island will be delimited in two complementary ways: > > * - It will be enclosed syntactically by characters with "open island" and > > "close island" syntax (see section (v)). Both of these syntactic > > markers will include a flag "chain" indicating whether there is a > > previous/next island in the chain. The cdr of the syntax value will be > > the island chain to which the island belongs. > > * - It will be covered by the text property `island', whose value will be > > the pertinent island or island chain (see section (ii)) (not yet > > decided). Note that if islands are enclosed inside other islands, the > > value is the innermost island. There is the possibility of using an > > interval tree independent of the one for text properties to increase > > performance. > When you say "complementary" do you mean alternative or simultaneous? > I.e. will an island always be enclosed by syntax markers and always have > a text property. Or can it have either? Sorry, that wasn't very clear. It would always have both. The text property would enable the code for chain local variables quickly to determine the current chain. The syntactic markers would enable efficient scanning by parse-partial-sexp, etc. > I'm still not understanding how the chain of islands is set up. Is this > entirely the super modes responsibility? Yes, it would be entirely for the super mode to do. There would be a set of functions to do this, for example: (defun create-island-chain (beg end major-mode ...) ...) (where BEG and END would be the bounds of the first island in the chain). (defun add-island-to-chain (chain beg end ...) ...) (which would delimit (BEG END) as an island, and link it into CHAIN) There would also be functions for removing islands from a chain, etc. I should really have put this into the notes. Thanks! > The use of "syntax" suggests that the islands can be detected *purely* > syntactically. No. It would be up to the super mode to determine them (however is appropriate), then to call, e.g., `create-island-chain' and `add-island-to-chain'. > But, there are many places where this is not true: consider org-mode: > #+begin_src emacs-lisp > (message "hello world") > #+end_src > We cannot assume that "+end_src" is the end of a island. > Also, how will the regexp engine work when it spans an island? I ask > because, if we use the regexp engine to match delimiters, the which > syntax do we use, if there are multiple modes in the buffer. I imagine that the island-start/end syntactic markers would normally be set by the super mode as syntax-table text properties. These always take priority over whatever the current syntax table would say. These markers would be considered to be in the enclosing scope, not part of the island they define. The current syntax table would always be that of the island the current position was in. I suppose there is potential for an island to be recognised as such in the "enclosing scope", but not in the island itself. This could be mitigated against by warning super mode programmers to use island-start/end syntaxes ONLY in syntax-table text properties. The actual matching of an island to "\\s-" would be delegated to the syntax code (as is currently done for "\\s?" expressions). > > o - An island might be represented by a C or Lisp structure, it might not > > (not yet decided). This structure would hold the containing chain, > > markers pointing to the start and end of the chain, and the previous and > > next islands in the chain. > > > > (v) Syntax, etc. > > o - Two new syntax classes, "open island" and "close island" will be > > introduced. These will be designated by the characters "{" and "}". Their > > "matching character" slots will contain the island's chain. There will be > > an extra flag "chain" (denoted by "i") indicating whether there is a > > previous/next island in the chain. > > o - `scan-lists', `scan-sexps', etc. will treat a "foreign" island as > > whitespace, much as they do comments. They will also treat as whitespace > > the gap between two islands in a chain. > Difficult to say, but this might produce some counter intuitive > behaviour. So, for example, consider some text like so: > === Example > (here is some lisp) > ;; This is a long and tedious piece of documentation in my lisp program. > (here is some more lisp) > === End Example > Now moving backward a paragraph will have a significant difference in > behaviour -- on the "(" of "here is some more lisp", we move to "(here > is some lisp), while on the char before, we move the "This is a long". > Good, bad, expected? Don't know. Assuming that the comment is set up as an island inside the lisp code (which might not be the Right Thing to do) .... As a user action, moving back that paragraph would move from "(here is some more lisp)" to ";; This is a long ....", since `in-islands' would be nil during command processing. As part of a program's parsing, `in-islands' would be bound to non-nil, and backward-paragraph would move from "(here is some more lisp)" to "(here is some lisp)". This is the intended processing. [ .... ] > > (vii) Variables. > > o - Island chain local variable bindings will come into existence. These > > bindings depend on the island point is in. There will be lower level > > routines that will have "position" parameters as an alternative to using > > point. > > o - All variables which are currently buffer local will become chain local > > except for those whose symbols are given a non-nil `entire-buffer' > > property. There will be no new functions like > > `make-chain-local-variable'. > What is the default-value of a chain local variable, if the variable is > also buffer-local? This would be the (global) default value of the variable. It would not be the buffer-local value. The intention is that the buffer-local value is the value for the portions of the buffer which are not in any islands. > Will we need functions for setting all chains in a certain mode in a > single buffer? I'm not sure what you mean, here. Does "in a certain mode" mean "INTO a certain mode"? If so, setting a major or minor mode in a chain will be able to be done by putting point inside a pertinent island and calling the mode function. Maybe a new function `mapchains' could be useful. > Phil -- Alan Mackenzie (Nuremberg, Germany).