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: Sun, 27 Mar 2016 12:09:19 +0000 Message-ID: <20160327120919.GA2682@acm.fritz.box> 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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1459080420 10587 80.91.229.3 (27 Mar 2016 12:07:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 27 Mar 2016 12:07:00 +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 Sun Mar 27 14:06:51 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 1ak9T0-00014h-P8 for ged-emacs-devel@m.gmane.org; Sun, 27 Mar 2016 14:06:51 +0200 Original-Received: from localhost ([::1]:35759 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak9Sz-0004oG-Iw for ged-emacs-devel@m.gmane.org; Sun, 27 Mar 2016 08:06:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59508) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak9Sk-0004o8-KS for emacs-devel@gnu.org; Sun, 27 Mar 2016 08:06:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ak9Sh-0003ZO-Bo for emacs-devel@gnu.org; Sun, 27 Mar 2016 08:06:34 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:24575) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ak9Sh-0003Wb-2A for emacs-devel@gnu.org; Sun, 27 Mar 2016 08:06:31 -0400 Original-Received: (qmail 40425 invoked by uid 3782); 27 Mar 2016 12:06:28 -0000 Original-Received: from acm.muc.de (p5B146029.dip0.t-ipconnect.de [91.20.96.41]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sun, 27 Mar 2016 14:06:27 +0200 Original-Received: (qmail 3098 invoked by uid 1000); 27 Mar 2016 12:09:19 -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.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:202281 Archived-At: Hello, Dmitry. On Fri, Mar 25, 2016 at 02:11:34AM +0200, Dmitry Gutov wrote: > On 03/24/2016 08:38 PM, Alan Mackenzie wrote: > > With islands it should work well, regardless of whether any major mode > > widens or narrows. That's because primitives (such as regexp search) > > would constrain themselves to the island. > It might work well. Without so much as a proof of concept, there's no > way to tell, really. 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. > Submode-local, and chunk-local, variables work fine. But you don't get > functioning facilities just by having variables. No. But you certainly don't get them without variables. ;-) > >> You'll have to present the total list of facilities, decide how the > >> islands would be applied, and other issues will likely come up from > >> unexpected places. > > That will require more investigation. But syntax based searching and > > regexp based searching will certainly be amongst them. > What about 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. goto-char? No. (All assuming `restrict-to-island' is bound to non-nil.) > 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. > > The island-local variables would stay with the island, so that when > > somebody inserts or removes text the right thing would be done. If > > somebody deletes the island, those variables would disappear (just as > > buffer local ones do when a buffer is deleted). > 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. > >> On the one hand, we'd probably want to retain some variables, in order > >> not to rerun the major mode functions over and over again. On the > >> other hand, if we were to put e.g. syntax-ppss-last into an > >> island-local variable (and it's a logical continuation of this idea), > >> after island boundaries change it should what... become unbound? Nil? > > That's for the application to decide. The island local binding would > > countinue to exist for as long as the island exists, and the application > > would be free to use it. > Something would have to create and maintain the island identities, as > users add and remove text, including island delimiters, it's not like > Emacs could do that automagically. My point is, implementing significant > part in Elisp is unavoidable anyway. The job of the super mode would be to maintain the islands, including creating them, and deleting them when the user deletes text which characterizes an island. This would of course be mainly in Lisp, yes. > >> 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 is "(narrow-to-region 1 (point-max))" going to become? It seems > > there will be a need for "the bounds of the island", which will impose > > complexities in major mode code. > Replacing '1' with (point-min) everywhere sounds like a minor change all > modes can bear. > 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. > >> That's not to say that being able to make parse-partial-sexp to skip > >> over certain intervals wouldn't be valuable. But you can do that, sort > >> of, already, by applying existing text properties to those intervals > >> (like beginning-of-comment/end-of-comment, or just "whitespace" over the > >> whole of it), and then removing them at the end of an operation. > > Not really. 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. > >> But the end benefits might not be high enough to justify the necessary > >> work and the increase in complexity in internals. > > They might not. They might. Basically, nobody else really seams > > interested in my idea, so it doesn't look like it will happen. > It sounds somewhat attractive to me, but we should understand more > clearly the goals we'll reach with it, as well as the semantics of the > new feature. It would relieve super modes of the tedious necessity to maintain island local variables using functions in post-command-hook, and things like that. It would not be necessary to use widening and narrowing to restrict indentation/fontification code to an island. > In order to deliver on the promise of seamless-ness, I think the islands > should be able to believe that every one of them starts with position 1, > and that they all have no gaps. I.e. every primitive would have to > behave that way, at least as long as the relevant global variable is > non-nil. 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. -- Alan Mackenzie (Nuremberg, Germany).