Re: "grouping" buffers

[Yuri Khan]

On Sun, 31 May 2020 at 12:03, Jean-Christophe Helary
<jean.christophe.helary@traduction-libre.org> wrote:

> > Every frame has a name parameter; this serves as the default for the frame 
> > title which window systems typically display at the top of the frame. You 
> > can specify a name explicitly by setting the name frame property.
>
> I don't know how to "set the name frame property". But there is probably a 
> place in the elisp manual that says how to do that.

I did this:

    (set-frame-parameter nil 'name "Hello World!")

and the title of my WM window that displays the current Emacs frame
changed. Of course this made it less convenient: now it displays a
static string, whereas previously, per my ‘frame-title-format’
configuration, it displayed the unsaved status and name of the buffer
in the currently selected window in that frame: •README.md – Emacs. So
yes:

> > Normally you don’t specify the name explicitly[…]


> Since in macos 1 frame = 1 window = 1 buffer, I can write something like "set 
> contents of document (read "buffer") of front window (read "frame") to 
> [whatever]"
>
> But that was just an example of how frames are easy to manipulate and access 
> out of the box in macos/applescript.

That is a consequence of that simple model (1 frame = 1 window = 1
buffer). In Emacs, the model is more complex, so you have to say “the
buffer shown in the selected window of the current frame”.
Fortunately, that is abbreviated to “the buffer shown in the currently
selected window”, and that to “the current buffer”, and that is
represented by passing nil to pretty much every function that accepts
a buffer argument.

Alternatively, you can refer to individual buffers, windows, and
frames, most easily by using the values of (current-buffer),
(selected-window), and (selected-frame). Also there are functions to
explore the frame/window/buffer structure, and the function
(get-buffer BUFFER-OR-NAME) to get a buffer by name. It’s harder to
talk about names of windows and frames because these things are
ephemeral.

If in your workflow you need a frame that you control, you arrange for
your code to create it and stash the reference into a private
variable, then refer to the frame via that variable.