From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: RE: Request for pointers and advice: displaying several buffers inside a single window Date: Sun, 12 Apr 2020 22:25:23 +0800 Message-ID: <87imi4aii4.fsf@localhost> 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 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="31392"; mail-complaints-to="usenet@ciao.gmane.io" Cc: dim1212k@gmail.com, adam@alphapapa.net, casouri@gmail.com, emacs-devel@gnu.org To: Drew Adams , Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Apr 12 16:30:00 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 1jNdcW-00083l-7e for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Apr 2020 16:30:00 +0200 Original-Received: from localhost ([::1]:33992 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNdcV-0002GQ-At for ged-emacs-devel@m.gmane-mx.org; Sun, 12 Apr 2020 10:29:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34274) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jNdbv-0001pj-GY for emacs-devel@gnu.org; Sun, 12 Apr 2020 10:29:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jNdbt-00015k-NX for emacs-devel@gnu.org; Sun, 12 Apr 2020 10:29:23 -0400 Original-Received: from mail-pf1-x435.google.com ([2607:f8b0:4864:20::435]:39685) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jNdbr-000155-65; Sun, 12 Apr 2020 10:29:19 -0400 Original-Received: by mail-pf1-x435.google.com with SMTP id k15so3422697pfh.6; Sun, 12 Apr 2020 07:29:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=ZRg09qaZdWuNhpJkpbhrheM31w1Y8xbMkGwto3ueErE=; b=Z/S0P0YQIQThEdTIY1BEykJhdnbG8OyKuuCYGZXlWq7u+jyfxbc5UYiUITOPVs2ae1 SXIE/vJXfSJzOelKjDoLVHWdXx8CoMgTVhSVH61Mm91Gh1f6NDMzwaO2EnyevZ8+02aN hZsZm+HxkQ/Xc+zwkUjqEWtAtku3weA9sOBRlDDHnPBtb9qvLqUIDjuXo5EHPUmyQzPd 3K42wwVg6cnlk+U/Q/2jbKC0Ruy2d4ONUl3MTQFZV7FwDlo/P/T0SNtBKrxw5EBWVS3h u9snCMsu9i4je9CuywcFgudfPRfejh5hF6yMyyupt7LKuEw6kVxMdOWJh2zWaDOVAduR GSkQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=ZRg09qaZdWuNhpJkpbhrheM31w1Y8xbMkGwto3ueErE=; b=feY/jHCGq1RbyYHQALEo1K47LDqWZ6Dkz/3sBl3Z7XnUdmYktr3T3UJH+67WKFuQwJ FFl15/2DKNeUNcs+SqDc3sDjTyWOFhiSarpUOJ3j8VUYwJnGx5ch8XUcpzvaknVrBxIK FNb164L9tK/x8a8FDV2SjK0x+rI5pnnS9wGffU0xeeXyUgK9fYORtraaj+fJU/Ceor71 rm9JgG17WH7YT4wdXCpyBX//d74LxgMCLjtMT6hqREeCnzXDRWWs6ViZOP7mKdDMSGBL NTqtXimeR0w2z33eAhvhBLujXg0DX6Xlli/axJQXOyKQ806Cw2I/OMpBoFePgbDHiIWa cyzQ== X-Gm-Message-State: AGi0Pua0KDW+Js+2llF68dGv/li8OUcfhVzmLgC3j4Z7lmKlQIoYZyxx MvUNjvyHm43PqprwDUjhIWo= X-Google-Smtp-Source: APiQypKKyP9GjxahfizaMaggNvqmO8pM4TwmEAwjkXO5MTUbNYjjPt0oY3a67Iffrj2w+rQF2EVM5g== X-Received: by 2002:aa7:9a92:: with SMTP id w18mr13732535pfi.95.1586701757907; Sun, 12 Apr 2020 07:29:17 -0700 (PDT) Original-Received: from localhost ([45.35.9.245]) by smtp.gmail.com with ESMTPSA id z12sm6688472pfj.144.2020.04.12.07.29.15 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Apr 2020 07:29:17 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::435 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:246866 Archived-At: > 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. Got it. > 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-=: I missed it when reading commentary. Probably because I was mostly looking at key bindings part. I guess that it would be helpful to add these key bindings to **Keys** section of the commentary, similarly to highlight.el-related bindings. > 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 agree that the discussed concept can be used far beyond org-mode scope. (Otherwise, there would be little reason to discuss adding it to Emacs core.) I just shared my personal use case (in addition to the provided links). > 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. FYI, my pre-alpha implementation of synchronised text is in github (https://github.com/yantar92/mirror-text). If you (or anyone else in the thread) is interested, feedback is welcome. Drew Adams writes: >> > 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. >> >> 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-=: > > 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-= 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-= 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. >> >> 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. >> >> > I wonder what your reason is for wanting that? >> > That "why" might help explain your request. >> >> 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. -- Ihor Radchenko, PhD, Center for Advancing Materials Performance from the Nanoscale (CAMP-nano) State Key Laboratory for Mechanical Behavior of Materials, Xi'an Jiaotong University, Xi'an, China Email: yantar92@gmail.com, ihor_radchenko@alumni.sutd.edu.sg