[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: "grouping" buffers

From: Drew Adams
Subject: RE: "grouping" buffers
Date: Sun, 31 May 2020 09:39:10 -0700 (PDT)

> > Frame Titles
> > 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.

The general way to change frame parameters is to
use function `modify-frame-parameters'.

There are also functions `set-frame-parameter' and

And I pointed you to code (in `frame-cmds.el')
that defines a command to rename a frame.  You're
free to use or adapt that.
> I think there should be a command that does that in frame.el.

Maybe so, but it's simple to define your own.  Even
if you don't want to use a 3rd-party library such
as `frame-cmds.el', you can reuse or adapt some of
its code, if you like.

> >> or to call a frame to the front for example, like I'd call
> >> a buffer to the front.
> >
> > By "call to the front", do you mean select the frame,
> > giving it focus?  That's standard command `select-frame' or
> > `select-frame-by-name' (or function `select-frame-set-focus').
> When I call select-frame I get "command-execute: select-frame must be
> bound to an event with parameters" I don't know what that means.

Yes, that's not covered well in the manuals, IMO.
You might consider filing a bug report.  The doc
should probably say that that command should be
bound to a mouse event.  Or perhaps that error
message could be made more clear.

Bind such a command to a menu item or some other
mouse event, and Bob's your uncle.

Googling for exactly that error message shows you
some info about this, but not much.  Here's one
search hit:

> Thanks to autocompletion I found about select-frame-by-name, and well,
> that worked fine, but as far as I can tell it's documented neither in
> the elisp manual nor in the emacs manual.

Most commands are not documented in the manuals.
It's not the purpose of the manuals to exhaustively
document each function, variable, etc.

(But if you feel that some specific function or
variable merits mention in a manual, you can
suggest that using `M-x report-emacs-bug'.)

The place to start, for info, is the doc string.
Then go to the source code.  `select-frame-by-name'
is defined in `frame.el'.  (But yeah, `select-frame'
is defined in C source code.)

> >> I can call it to the front or to the back, I can modify its
> >> contents, I can rearrange the size and placement of each frame, etc.
> >
> > Dunno what you mean by modify its contents.
> 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]"

In Emacs I guess you're talking about changing the
content of a buffer.  You know how to do that.  And
to do it with code, the buffer doesn't even need to
be displayed. 

> > Most frame changes are done ultimately with
> > `modify-frame-parameters'.
> I see. Maybe the section I quoted above could have an explicit link to
> that section. I mean, *all* sections in the Emacs manual should have a
> link to the relevant part of the Elisp manual...

If you want such suggestions to have an effect on
the Emacs developers, consider filing an enhancement
request: `M-x report-emacs-bug'.

> Now it occurs to me that the tab feature that has been recently
> included in Emacs is easier to use out of the box than frames. For ex,
> by default I can call a menu where all the tabs are listed and I can
> select any one of them.
> Although it is a different "menu", I just checked and F10 menu does
> have a frame item but it's buried inside the Buffer item.


Library `menu-bar+.el' gives you a top-level `Frames'
menu, with these items (the `Frames' under `Buffers'
continues to just list frames for selection).

 Hide Frames / Show Buffers  (C-M-Z)
 Iconify All Frames  <vertical-line> <S-down-mouse-1>
 Maximize Frame
 Maximize Frame Horizontally
 Maximize Frame Vertically
 Toggle Max Frame
 Toggle Max Frame Horizontally
 Toggle Max Frame Vertically
 Tile Frames Horizontally...
 Tile Frames Vertically...
 Set Frame Parameter from Frame...
 Set All Frame Parameters from Frame...
 Fit This Frame              C-x C-_
 Delete Frame                C-x 5 0
 New Frame                   C-x 5 2
 New Frame on Display...

And if you also use Icicles then there is an
`Icicles' submenu, with these multicommand

 + Change Background of Frame...
 + Change Foreground of Frame...
 + Change Font of Frame...

> In conclusion, I think there could be the following modifications to
> the system to improve usability:
> Short term:
> 1) Assign a C-x 5 default keybinding to "select-frame-by-name"
> 2) Add a C-x 5 bound command for renaming a frame
> 3) Document select-frame-by-name in the 2 manuals
> 4) Move the F10 "Frames" menu item to the menu root
> Medium term:
> 4) Systematically add links to the Elisp manual in the Emacs manual. To
> make sure that new users get a habit to checking the two.

See above.  `M-x report-emacs-bug'.  That's for
enhancement requests, as well as bug reports.

FWIW, I agree with your general assessment that
Emacs has relatively poor support for frames,
or put differently, frames are the poor cousins
of Emacs windows.

One reason for this is no doubt that Emacs has
much less control over frames - behavior and
appearance.  Window managers have ultimate
control, and different window mgrs behave
differently.  All Emacs can do is to request
or suggest something of a window mgr.

Another reason (my guess) is that (partly
because Emacs has relatively poor support for
frames) Emacs users and developers use frames
less.  So they don't tend to develop new
features taking frames into account much, and
they might not test things much taking frames
into account.

See this page for more about this issue/problem:

> I also need to understand why "select-frame" spits that error
> message...

See above.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]