From: Drew Adams <drew.adams@oracle.com>
To: Ihor Radchenko <yantar92@gmail.com>, Eli Zaretskii <eliz@gnu.org>
Cc: dim1212k@gmail.com, adam@alphapapa.net, casouri@gmail.com,
emacs-devel@gnu.org
Subject: RE: Request for pointers and advice: displaying several buffers inside a single window
Date: Sat, 11 Apr 2020 10:23:18 -0700 (PDT) [thread overview]
Message-ID: <e186b236-17df-4f3b-b001-68e1bfadb869@default> (raw)
In-Reply-To: <87eesuxwzt.fsf@localhost>
> > 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.
next prev parent reply other threads:[~2020-04-11 17:23 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-03 11:54 Request for pointers and advice: displaying several buffers inside a single window Dmitrii Korobeinikov
2020-04-03 13:07 ` Eli Zaretskii
2020-04-04 22:44 ` Dmitrii Korobeinikov
2020-04-05 14:08 ` Adam Porter
2020-04-05 22:55 ` Dmitrii Korobeinikov
2020-04-10 14:45 ` Yuan Fu
2020-04-10 15:35 ` Ihor Radchenko
2020-04-10 16:43 ` Eli Zaretskii
2020-04-10 17:46 ` Ihor Radchenko
2020-04-10 18:07 ` Eli Zaretskii
2020-04-10 18:37 ` Ihor Radchenko
2020-04-10 19:01 ` Drew Adams
2020-04-10 19:19 ` Ihor Radchenko
2020-04-10 20:29 ` Drew Adams
2020-04-11 8:11 ` Ihor Radchenko
2020-04-11 17:23 ` Drew Adams [this message]
2020-04-12 2:42 ` Richard Stallman
2020-04-12 5:09 ` Drew Adams
2020-04-12 5:15 ` Drew Adams
2020-04-13 2:21 ` Richard Stallman
2020-04-13 5:23 ` Drew Adams
2020-04-12 23:54 ` Juri Linkov
2020-04-13 5:23 ` Drew Adams
2020-04-12 14:25 ` Ihor Radchenko
2020-04-12 16:38 ` Drew Adams
2020-04-10 19:12 ` Eli Zaretskii
2020-04-10 19:25 ` Ihor Radchenko
2020-04-10 19:34 ` Ihor Radchenko
2020-04-11 7:34 ` Eli Zaretskii
2020-04-11 8:35 ` Ihor Radchenko
2020-04-11 9:25 ` Eli Zaretskii
2020-04-10 19:09 ` Dmitrii Korobeinikov
2020-04-11 0:05 ` chad
2020-04-11 8:22 ` Eli Zaretskii
2020-04-11 7:30 ` Eli Zaretskii
2020-04-11 7:56 ` Dmitrii Korobeinikov
2020-04-11 8:26 ` Eli Zaretskii
2020-04-11 10:01 ` Dmitrii Korobeinikov
2020-04-03 18:30 ` [SPAM UNSURE] " Stephen Leake
2020-04-05 13:18 ` Robert Pluim
2020-04-05 20:35 ` Dmitrii Korobeinikov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=e186b236-17df-4f3b-b001-68e1bfadb869@default \
--to=drew.adams@oracle.com \
--cc=adam@alphapapa.net \
--cc=casouri@gmail.com \
--cc=dim1212k@gmail.com \
--cc=eliz@gnu.org \
--cc=emacs-devel@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).