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: IDE Date: Sat, 10 Oct 2015 13:15:23 -0700 (PDT) Message-ID: <2ac04754-50e8-4cc3-8487-dbdb6d39961d@default> References: < <5612E996.7090700@yandex.ru>> < <83bnc7tavr.fsf@gnu.org>> <<5618C92A.3040207@yandex.ru> <83a8rrt9ag.fsf@gnu.org>> <<5618D376.1080700@yandex.ru> <831td3t62e.fsf@gnu.org>> <<5618E51D.4070800@yandex.ru> <83twpzrp05.fsf@gnu.org>> <<5618ED93.8000001@yandex.ru> <83lhbbrnn7.fsf@gnu.org>> <<56191EBE.5050404@yandex.ru> <83612essaw.fsf@gnu.org>> <<877fmuix68.fsf@isaac.fritz.box> <8337xispn2.fsf@gnu.org>> <<56195055.6010409@gmx.at> <87oag6ftoq.fsf@fencepost.gnu.org>> <<83pp0mr1f7.fsf@gnu.org> <87fv1ifshu.fsf@fencepost.gnu.org>> <<83lhbar0tn.fsf@gnu.org>> 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 1444508194 16598 80.91.229.3 (10 Oct 2015 20:16:34 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 10 Oct 2015 20:16:34 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii , David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 10 22:16:20 2015 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 1Zl0Z1-0003gL-GI for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 22:16:19 +0200 Original-Received: from localhost ([::1]:46216 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl0Z0-0003HG-QF for ged-emacs-devel@m.gmane.org; Sat, 10 Oct 2015 16:16:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55414) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl0YH-0002uJ-82 for emacs-devel@gnu.org; Sat, 10 Oct 2015 16:15:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Zl0YG-0001yw-5q for emacs-devel@gnu.org; Sat, 10 Oct 2015 16:15:33 -0400 Original-Received: from aserp1040.oracle.com ([141.146.126.69]:35937) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Zl0YC-0001xa-1Y; Sat, 10 Oct 2015 16:15:28 -0400 Original-Received: from aserv0022.oracle.com (aserv0022.oracle.com [141.146.126.234]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t9AKFPBJ023690 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 10 Oct 2015 20:15:25 GMT Original-Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by aserv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t9AKFPAT011526 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sat, 10 Oct 2015 20:15:25 GMT Original-Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t9AKFOZP021853; Sat, 10 Oct 2015 20:15:24 GMT In-Reply-To: <<83lhbar0tn.fsf@gnu.org>> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9 (901082) [OL 12.0.6691.5000 (x86)] X-Source-IP: aserv0022.oracle.com [141.146.126.234] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 141.146.126.69 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:191174 Archived-At: > Not sure what you are saying. Is it that a region with two ends is > not enough, and we need a list of regions? If so, I'm okay with > that, and I don't see any serious obstacles to implement that. FWIW, library `zones.el' provides that, along with various commands for defining and using such multiple-zone "regions". http://www.emacswiki.org/emacs/Zones You can sort, intersect, or unite zones; narrow the buffer to a zone or select one as the region, (un)highlight zones, make a list of zones persistent (re-created with a bookmark), or use incremental search across it (overlapping zones in the list are united for this). You can name lists of zones and switch among them for different multi-zone operations. You can associate arbitrary information with a zone, which is otherwise just a pair of buffer positions (e.g. markers). This does _not_ provide the feature of having zones that are in different major modes. I agree that that particular feature is sorely missing. There have been various attempts at providing it, but I'm not aware of any that has been really satisfactory in a general way.