From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: Request for pointers and advice: displaying several buffers inside a single window Date: Sat, 11 Apr 2020 10:23:18 -0700 (PDT) Message-ID: References: <83a73swwd7.fsf@gnu.org> <87wo6nxsjz.fsf@localhost> <83d08fmgul.fsf@gnu.org> <87tv1rxmgc.fsf@localhost> <83a73jmcyo.fsf@gnu.org> <87pncfxk4m.fsf@localhost> <87mu7jxi64.fsf@localhost> <87eesuxwzt.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="65267"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dim1212k@gmail.com, adam@alphapapa.net, casouri@gmail.com, emacs-devel@gnu.org To: Ihor Radchenko , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Apr 11 19:26:56 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1jNJu9-000Gq6-Sv for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 19:26:53 +0200 Original-Received: from localhost ([::1]:53910 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNJu8-0000i2-Up for ged-emacs-devel@m.gmane-mx.org; Sat, 11 Apr 2020 13:26:52 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56792) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNJsp-00089h-Iv for emacs-devel@gnu.org; Sat, 11 Apr 2020 13:25:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNJso-0004B6-08 for emacs-devel@gnu.org; Sat, 11 Apr 2020 13:25:31 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:57954) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jNJsk-0004A3-Tv; Sat, 11 Apr 2020 13:25:27 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03BHOgjH027394; Sat, 11 Apr 2020 17:25:21 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=22c7Kaa+AS7QCKpWBdiN1KruaV6Ozn/Wu+sH7SSPVUY=; b=fYuJa5YJJv2jEdPZa6/M7p5YC7UVaTuwk5xFnRPqEmqPU6IHgSJVwichNEVKRbcvLmj0 NUx4nINANu7V59hNw6SllFDqsDHwkirOP9JaqFMD5CW1YOc+ElFGMFpkmN+9oal/D1rS ac8XaHY27aJwqmNJjL4MXOI9Z2xoF8UBu5S+Uim6sjBFLMpD1gFINYPnBM/3i1BuoU3Y RleUJzIKraAyC64ObXijvdiSz8jh69owVaFR8tZFnB8m/HBZ3lvhj40crzdEd4YnLPNj y5UkUOqoEZb7gTfoSj872hw1De7sIMH3u61umFMFEOQ+sGh2peZ55T0ZYNk2K2jIW8d4 oQ== Original-Received: from userp3020.oracle.com (userp3020.oracle.com [156.151.31.79]) by aserp2120.oracle.com with ESMTP id 30b5uksaha-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Apr 2020 17:25:21 +0000 Original-Received: from pps.filterd (userp3020.oracle.com [127.0.0.1]) by userp3020.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 03BHMkRf081861; Sat, 11 Apr 2020 17:23:20 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userp3020.oracle.com with ESMTP id 30b57jhy4y-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sat, 11 Apr 2020 17:23:20 +0000 Original-Received: from abhmp0010.oracle.com (abhmp0010.oracle.com [141.146.116.16]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 03BHNJxC001531; Sat, 11 Apr 2020 17:23:19 GMT In-Reply-To: <87eesuxwzt.fsf@localhost> X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.4966.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9588 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 phishscore=0 mlxscore=0 bulkscore=0 malwarescore=0 adultscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004110163 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9588 signatures=668686 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 clxscore=1015 bulkscore=0 mlxscore=0 mlxlogscore=999 lowpriorityscore=0 impostorscore=0 adultscore=0 phishscore=0 spamscore=0 suspectscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2003020000 definitions=main-2004110163 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] [fuzzy] X-Received-From: 141.146.126.78 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:246844 Archived-At: > > To be clear, there's no need to cycle among zones. > > No need to see only one at a time. You can see all > > of them all of the time, as well as see the other, > > non-zone text, of any and all buffers. > > > > What zones.el does not offer is showing the text > > of more than one buffer in the same Emacs window. >=20 > I was not able to achieve this. Do you mean that zones > located more than one screen away in the same buffer > can be shown all together resulting in a narrowing with > multiple zones shown one after other without text > between them? No, not exactly; not a multi-narrowing. I meant only that you need not access a zone or make it visible only by narrowing to it. Without narrowing, zones are still defined, and you can use them and act on them in an infinite number of ways. Zones are just defined areas of a buffer. But as for your question about seeing only some (or all) zones, and hiding the text between them: That's indeed possible, but it's not about narrowing. It's instead about making a set of zones (or its complement) _invisible_. For this you also need library `isearch-prop.el'. If you load that library then you can use these keys on prefix key C-x n M-=3D: v - isearchp-toggle-anti-zones-invisible V - isearchp-toggle-zones-invisible ~ - isearchp-toggle-complementing-domain d - isearchp-toggle-dimming-outside-search-area The first of these toggles hiding (making invisible) the complement of (the union of) the current set of zones, that is, the anti-zones. With a prefix arg it also toggles visibility of the zones themselves the other way (e.g. makes them visible when it makes the anti-zones invisible, and vice versa). Invisibility, here, is the usual Emacs invisibility of text. So for example, if you have a bunch of zones in a given buffer, and you use `C-x n M-=3D v', then all of the text outside those zones (the anti-zones) is made invisible (disappears). You see the zones right next to each other, with no intervening text. Repeating `C-x n M-=3D= v' shows the anti-zones again. > > Maybe consider this feedback as just letting you > > know that I, at least, don't quite understand > > what you're trying to do (or why). > > > > Emacs doesn't let you use the same window for > > multiple buffers, as far as I know. >=20 > I am trying to suggest something for displaying > text from multiple buffers in a single window. > My idea is to modify Emacs buffer internals > to achieve this. I understand that. > > Emacs doesn't let you use the same window for > > multiple buffers, as far as I know. > > > > You can finagle ways to show text from multiple > > buffers in the same window, e.g. by copying it. > > And if you do that, and you then want to edit > > the copies, then, yes, you'll need to then sync > > up the original buffers with your edits. >=20 > > I wonder what your reason is for wanting that? > > That "why" might help explain your request. >=20 > I think the reasons were discussed in ... and > popped up several times in internet... Yes, I've seen those. FWIW, I agree that being able to do arbitrary editing (e.g. search-&-replace) in such a context would be useful. That we're talking about a single window here in effect means we're talking about having a window that shows a buffer that is like an indirect buffer that refers to parts of multiple buffers. One way to think of it could be as an extension of the notion of indirect buffer. zones.el doesn't help with this. It does let you do such things for zones in the _same_ buffer. And it does let you work on sets of zones across multiple buffers. But it doesn't let you work on the latter in the same window (i.e., the same ~indirect buffer for multiple buffers). > For me, the reasons are mostly related to org > mode. For example, it would be cool to have > the same org heading in multiple places (and be > able to edit the heading from any of those places). I can see that use case. But I'd encourage people to think beyond Org mode use cases for the kind of thing being discussed. Being able to have, in effect, an indirect buffer that refers to multiple buffers is _much_ more general than any Org mode uses. (I'm saying "indirect buffer" here, but I know that indirect buffers currently are limited. They are in some ways too tightly related to their base buffers.) In a way, Org mode tries to give you some similar behavior, by delimiting buffer areas using plain-text tags (similar to what XML tags do). The approach taken by zones.el is better in this regard, I think. It defines zones only by buffer and positions (which can be markers or Lisp-readable markers). A zone is like an overlay, but it has an identifier, it can be Lisp-readable and persistent, and it can be buffer-independent (used in different buffers). Anyway, good luck with your project. I hope it will ultimately be general enough to help with _all_ of the various uses people have envisioned for acting on areas of different buffers in the same Emacs window / indirect buffer. I wouldn't like to see something that is limited to something like Org mode, or is limited to use with multiple major modes. I'd like to see something very general and flexible.