unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: martin rudalics <rudalics@gmx.at>
To: Eric Abrahamsen <eric@ericabrahamsen.net>, emacs-devel@gnu.org
Subject: Re: Understanding atomic window groups
Date: Mon, 3 Jun 2019 11:12:31 +0200	[thread overview]
Message-ID: <26d5d317-df88-fed9-1eb5-e5f0cb07bd25@gmx.at> (raw)
In-Reply-To: <87lfyucxfx.fsf@ericabrahamsen.net>

 > Okay, I do see that `quit-window' has a more complicated job to do, and
 > multiple conditions are checked. I guess I was hoping/expecting that
 > `quit-window' in a member of an atomic window group could somehow be
 > altered to act on the whole group, rather than just the current window.

We would have to specify the respective semantics first.  Atomic
groups by default do not have main windows.  All its constituting live
windows are treated equal - as, for example, two side-by-side windows
showing the diffs of a file.  If we want to designate one constituent
of an atomic window as the "main" window and have 'quit-window' act on
the entire group as the 'quit-restore' parameter of that main window
says, we would have to write specific code for 'quit-restore-window'.

 > I would at least add the fact that atomic groups can be nested,

When I first used the term "nested" I only meant that an atomic window
can comprise an arbitrary number of windows as long as the resulting
window has a rectangular shape.  That's why I asked you to act on the
root of the atomic window instead on the parent of one of its
constituents.  I'm not sure what to say more about this in the manual
- maybe you can propose the necessary change.

 > and say
 > something about how to get _rid_ of an atomic group. When I was first
 > experimenting, I ended up having to reboot emacs, because I couldn't
 > figure out how to un-atomic the frame.

I tried to say that now.

 > It would be great to have more examples in the side windows section as
 > well. The two features together feel like they could be very powerful,
 > there's just a bit of a documentation gap.

I already devote an entire subsection to an example.

 > I've had it in the back of my mind to try replacing Gnus' homemade
 > windowing functionality with side windows, because they do pretty much
 > the same thing, but I'm not sure where to start. In particular, the doc
 > examples show a setup where certain buffers appear to _always_ be
 > displayed in certain side buffers. My assumption is that in the vast
 > majority of cases, people would want to display _this_ particular group
 > of buffers in a certain way on _this_ frame, and not pollute the global
 > config.

Which use case do you have in mind?  The people asking before for such
a feature wanted the layout apply to any frame - that is, side windows
should specify the global configuration.

martin



  parent reply	other threads:[~2019-06-03  9:12 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-22 17:50 Understanding atomic window groups Eric Abrahamsen
2019-05-23  8:39 ` martin rudalics
2019-05-23 20:14   ` Eric Abrahamsen
2019-05-24  8:01     ` martin rudalics
2019-05-24  8:24       ` Eli Zaretskii
2019-05-24 21:32       ` Eric Abrahamsen
2019-05-25  7:59         ` martin rudalics
2019-05-25  8:13           ` Eli Zaretskii
2019-06-03  9:11             ` martin rudalics
2019-06-03 15:10               ` Eli Zaretskii
2019-05-25 16:26           ` Eric Abrahamsen
2019-05-25 17:54             ` Eric Abrahamsen
2019-06-03  9:13               ` martin rudalics
2019-06-03  9:12             ` martin rudalics [this message]
2019-06-03 21:03               ` Eric Abrahamsen
2019-06-04  8:20                 ` martin rudalics
2019-06-04 17:28                   ` Eric Abrahamsen
2019-06-11 21:07                   ` Eric Abrahamsen
2019-06-15  8:16                     ` martin rudalics
2019-06-15 15:47                       ` Eric Abrahamsen

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=26d5d317-df88-fed9-1eb5-e5f0cb07bd25@gmx.at \
    --to=rudalics@gmx.at \
    --cc=emacs-devel@gnu.org \
    --cc=eric@ericabrahamsen.net \
    /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).