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: Fri, 22 Apr 2016 10:04:42 -0700 (PDT) Message-ID: <698fdcc8-c6f9-4e71-b5c0-202e6a5c71ba@default> References: <20160420194450.GA3457@acm.fritz.box> <8360vb6o7u.fsf@gnu.org> <20160421213323.GD1775@acm.fritz.box> <553ab39a-eeaf-4fb7-b8ae-e0592f27db6e@default> <20160422081344.GA1873@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 1461344725 22896 80.91.229.3 (22 Apr 2016 17:05:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 22 Apr 2016 17:05:25 +0000 (UTC) Cc: Eli Zaretskii , dgutov@yandex.ru, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 22 19:05:13 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 1ateW1-0006Wf-5f for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 19:05:13 +0200 Original-Received: from localhost ([::1]:36445 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ateW0-0002gz-JM for ged-emacs-devel@m.gmane.org; Fri, 22 Apr 2016 13:05:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57581) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ateVk-0002eJ-MC for emacs-devel@gnu.org; Fri, 22 Apr 2016 13:04:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ateVj-0004lD-HO for emacs-devel@gnu.org; Fri, 22 Apr 2016 13:04:56 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:36633) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ateVd-0004jC-Qe; Fri, 22 Apr 2016 13:04:50 -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 u3MH4j6k031800 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Apr 2016 17:04:46 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id u3MH4jPO003459 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 22 Apr 2016 17:04:45 GMT Original-Received: from abhmp0003.oracle.com (abhmp0003.oracle.com [141.146.116.9]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id u3MH4hev008493; Fri, 22 Apr 2016 17:04:44 GMT In-Reply-To: <20160422081344.GA1873@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:203180 Archived-At: > > 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. >=20 > Thanks, I didn't know about that variable. But it may not be > widely applicable enough. I guess you're referring to point movements, among other things. `isearch-filter-predicate', or similar, could presumably be made so (more widely applicable). It is also used by `perform-replace' (e.g. `query-replace'), BTW - not just search. The point is that a predicate is more general than a regexp, and it doesn't interfere with the use of a regexp (and vice versa). > > > 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. W= e > > > therefore need a flag which instructs the primitives how to behave > > > when there are islands. > > > > `isearch-filter-predicate'. It can let code know whether > > you are island-searching or not. >=20 > That would only work for isearch. Not if other code takes it into account. It only worked for search until `perform-replace' started taking it into account. > > > The user will, from time to time, delete the delimiters > > > which define islands, and will insert other ones. >=20 > > FWIW, markers as delimiters do not have that problem. >=20 > 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; >=20 > MaaaaaaaaaaaM MbbbbbbbbbbbbbM > dddddddddddddddddd >=20 > ? You might well not want the two islands a and b to be coalesced. What's the alternative? If you're worried about different modes (for example) for aaaaaa and bbbbbb then consider keeping lists of markers per mode (or whatever) - like we sometimes handle overlays using one or more lists. Anyway, it was only a "FWIW". I use both text properties and markers. There are advantages and disadvantages to any implementation. Also, where I use markers I allow extra info in a given zone, in addition to the markers: ;; A "basic zone" is a list of two buffer positions followed ;; by a possibly empty list of extra information: ;; (POS1 POS2 . EXTRA). IOW, some info is location-specific (buffer and position), and other info (EXTRA) is zone-specific. In your scenario, if a zone's second marker is deleted then code could decide, based on whatever (including whether or not aaaaaaaa and bbbbbbbb are in the same mode or have compatible "EXTRA" island info), whether to: coalesce them, delete them (as islands, not the text), or keep them separate. The point is that the code can do anything. But yes, a single marker does not record more than a buffer and a position. I think, however, that the additional info you are wanting to associate here is really (typically, at least) info to associate with the island, and not info to associate with an individual marker.