From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: A vision for multiple major modes: some design notes Date: Thu, 21 Apr 2016 15:01:12 -0700 (PDT) Message-ID: <553ab39a-eeaf-4fb7-b8ae-e0592f27db6e@default> References: <20160420194450.GA3457@acm.fritz.box> <8360vb6o7u.fsf@gnu.org> <20160421213323.GD1775@acm.fritz.box> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1461276107 10293 80.91.229.3 (21 Apr 2016 22:01:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 21 Apr 2016 22:01:47 +0000 (UTC) Cc: dgutov@yandex.ru, emacs-devel@gnu.org To: Alan Mackenzie , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 00:01:31 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 1atMfC-00073W-7q for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 00:01:30 +0200 Original-Received: from localhost ([::1]:48811 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMfB-0000ZP-EX for ged-emacs-devel@m.gmane.org; Thu, 21 Apr 2016 18:01:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53088) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMf7-0000US-DK for emacs-devel@gnu.org; Thu, 21 Apr 2016 18:01:26 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1atMf6-0007pH-DK for emacs-devel@gnu.org; Thu, 21 Apr 2016 18:01:25 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:32965) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1atMf0-0007mE-Qo; Thu, 21 Apr 2016 18:01:19 -0400 Original-Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u3LM1FHs025572 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 22:01:16 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3LM1Fth031876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 21 Apr 2016 22:01:15 GMT Original-Received: from abhmp0019.oracle.com (abhmp0019.oracle.com [141.146.116.25]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3LM1Dlg020375; Thu, 21 Apr 2016 22:01:14 GMT In-Reply-To: <20160421213323.GD1775@acm.fritz.box> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6744.5000 (x86)] X-Source-IP: aserv0021.oracle.com [141.146.126.233] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 156.151.31.81 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:203158 Archived-At: [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? > 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. [I also optionally dim the non-islands during search (or the non-non-islands, if complementing), so the areas being searched stand out more.] > 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. > 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. [The `isearch-prop.el' code can use zones defined by either their limits (e.g., markers) or text or overlay properties on their text. It lets commands like `query-replace' do similarly.]