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: Fri, 22 Apr 2016 08:13:44 +0000 Message-ID: <20160422081344.GA1873@acm.fritz.box> References: <20160420194450.GA3457@acm.fritz.box> <8360vb6o7u.fsf@gnu.org> <20160421213323.GD1775@acm.fritz.box> <553ab39a-eeaf-4fb7-b8ae-e0592f27db6e@default> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1461313471 25635 80.91.229.3 (22 Apr 2016 08:24:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2016 08:24:31 +0000 (UTC) Cc: Eli Zaretskii , dgutov@yandex.ru, emacs-devel@gnu.org To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 10:24:23 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 1atWNy-0001qW-06 for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 10:24:22 +0200 Original-Received: from localhost ([::1]:56851 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atWNx-0007lV-8k for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 04:24:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41129) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atWNt-0007jS-Qa for emacs-devel@gnu.org; Fri, 22 Apr 2016 04:24:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atWNq-0005Cg-QP for emacs-devel@gnu.org; Fri, 22 Apr 2016 04:24:17 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:32040) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atWNq-0005CP-HU for emacs-devel@gnu.org; Fri, 22 Apr 2016 04:24:14 -0400 Original-Received: (qmail 20753 invoked by uid 3782); 22 Apr 2016 08:24:12 -0000 Original-Received: from acm.muc.de (p548A5EE9.dip0.t-ipconnect.de [84.138.94.233]) by colin.muc.de (tmda-ofmipd) with ESMTP; Fri, 22 Apr 2016 10:24:11 +0200 Original-Received: (qmail 1935 invoked by uid 1000); 22 Apr 2016 08:13:44 -0000 Content-Disposition: inline In-Reply-To: <553ab39a-eeaf-4fb7-b8ae-e0592f27db6e@default> 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:203164 Archived-At: Hello, Drew. On Thu, Apr 21, 2016 at 03:01:12PM -0700, Drew Adams wrote: > [More interesting details. Thx.] > > Given a buffer position, we need to be able to find the corresponding > > island chain. "Obviously", we do this with a text property, which we > > might as well call `island', or possibly `chain'. Since successive > > accesses to chain local variables are very likely to be in the same > > chain most of the time, we will cache the "current" chain in buffer > > local variables. > I guess you are referring to the possibility of more than one > chain having an island at point, and wanting to pick up the right > one as the "current" chain - so you check a text property, which > identifies the chain that is currently active. Is that right? Er, no. ;-) Even when there is only one island at point, we still need to determine it. A text property is a good way of doing this. > > When it comes to movement and search primitives, we want to adapt these > > so that the impact on existing major modes is minimised. Ideally, we > > would want major modes to "see" only their own islands (or lack > > thereof). Thus we treat irrelevant islands as blocks of whitespace. It > > seems to make sense to have such islands matched by subexpressions in > > regexps which match spaces. This would obviate the need to amend a > > great number of regexps currently coded in major modes. > For search, at least, I don't see why you don't make use of > `isearch-filter-predicate'. That's what I do in my code, to > search only within (or without: complement) a set of zones > (~chain of islands). That seems simple and cheap. Thanks, I didn't know about that variable. But it may not be widely applicable enough. > [I also optionally dim the non-islands during search (or the > non-non-islands, if complementing), so the areas being searched > stand out more.] That's another matter, at a different level of abstraction from the main topic. > > On the other hand, when a user does C-s or C-M-s, the Right Thing is > > surely to search the buffer as a whole, without regard to islands. We > > therefore need a flag which instructs the primitives how to behave when > > there are islands. We might as well call this flag `in-islands', for > > want of a better name. > `isearch-filter-predicate'. It can let code know whether > you are island-searching or not. That would only work for isearch. > > The user will, from time to time, delete the delimiters which define > > islands, and will insert other ones. > FWIW, markers as delimiters do not have that problem. I think they do. What happens when you have two islands bounded by four markers, and you delete a region containing the two middle markers; MaaaaaaaaaaaM MbbbbbbbbbbbbbM dddddddddddddddddd ? You might well not want the two islands a and b to be coalesced. -- Alan Mackenzie (Nuremberg, Germany).