GNU bug report logs - #37079
26.2.90 feature request; bury-frame command for desktop-wm

Previous Next

Package: emacs;

Reported by: VanL <van <at> scratch.space>

Date: Mon, 19 Aug 2019 05:09:01 UTC

Severity: wishlist

Tags: notabug

Found in version 26.2.90

Done: Stefan Kangas <stefan <at> marxist.se>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 37079 in the body.
You can then email your comments to 37079 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Mon, 19 Aug 2019 05:09:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to VanL <van <at> scratch.space>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Mon, 19 Aug 2019 05:09:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: VanL <van <at> scratch.space>
To: bug-gnu-emacs <at> gnu.org
Subject: 26.2.90 feature request; bury-frame command for desktop-wm
Date: Mon, 19 Aug 2019 15:08:22 +1000
Hello,

The frame commands in

  info:emacs#Frame Commands

don't include a command to `bury-frame' as distinct from minimize-frame (C-z) in the desktop-wm.

Having 'bury-frame' allows quick switching away-from-then-return-back-to Emac's focus-frame while working with not-Emacs-app.  I hope this does not require very deep coding complications into the specific desktop-wm's frameworks making this feature request not worth the effort.  Thank you.



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Mon, 19 Aug 2019 07:39:02 GMT) Full text and rfc822 format available.

Message #8 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: VanL <van <at> scratch.space>, 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request; bury-frame command for
 desktop-wm
Date: Mon, 19 Aug 2019 09:38:12 +0200
> don't include a command to `bury-frame' as distinct from
> minimize-frame (C-z) in the desktop-wm.
>
> Having 'bury-frame' allows quick switching
> away-from-then-return-back-to Emac's focus-frame while working with
> not-Emacs-app.  I hope this does not require very deep coding
> complications into the specific desktop-wm's frameworks making this
> feature request not worth the effort.  Thank you.

What should 'bury-frame' do?  In which sense would it be different
from 'lower-frame'?  How would you return-back-to a buried frame?

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Mon, 19 Aug 2019 09:32:02 GMT) Full text and rfc822 format available.

Message #11 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: VanL <van <at> scratch.space>
To: martin rudalics <rudalics <at> gmx.at>
Cc: 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request;
 bury-frame command for desktop-wm
Date: Mon, 19 Aug 2019 19:31:13 +1000
> On 19 Aug 2019, at 17:38, martin rudalics <rudalics <at> gmx.at> wrote:
> 
> What should 'bury-frame' do?  In which sense would it be different
> from 'lower-frame'?  How would you return-back-to a buried frame?

The two terms are synonymous.  I searched for the idea closest to 'lower-frame' on the web and used 'bury-frame' in this feature request for the reason that `bury' is what is done to move a buffer to the `bottom' of a 'listing of buffers'.

Use case: I am editing within an Emacs frame.  I context switch to another app and want to lower (or bury) the Emacs frame with a quick keyboard shortcut.  After completing the task at the other app which has taken my hand to the mouse I want to continue on that lowered Emacs frame by clicking on that.  To bury the frame completely without any part of it showing for mouse clicking to raise is a corner case I may not want all of the time.

--
v.



Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Wed, 21 Aug 2019 07:38:02 GMT) Full text and rfc822 format available.

Message #14 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: VanL <van <at> scratch.space>
Cc: 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request; bury-frame command for
 desktop-wm
Date: Wed, 21 Aug 2019 09:36:54 +0200
>> What should 'bury-frame' do?  In which sense would it be different
>> from 'lower-frame'?  How would you return-back-to a buried frame?
>
> The two terms are synonymous.  I searched for the idea closest to
> 'lower-frame' on the web and used 'bury-frame' in this feature
> request for the reason that `bury' is what is done to move a buffer
> to the `bottom' of a 'listing of buffers'.

Whatever 'bury-buffer' does, it's effect can be fully controlled by
Emacs itself.  'lower-frame' has Emacs ask the window manager to put
the window of an Emacs frame at the bottom of the z-order of visible
windows.  Thereafter, the effect of this operation is completely with
the window manager and Emacs has no control over it.

> Use case: I am editing within an Emacs frame.  I context switch to
> another app and want to lower (or bury) the Emacs frame with a quick
> keyboard shortcut.

So all you want is that Emacs by default assigns a keyboard shortcut
to 'lower-frame'.  Which combination did you have in mind?

> After completing the task at the other app which
> has taken my hand to the mouse I want to continue on that lowered
> Emacs frame by clicking on that.  To bury the frame completely
> without any part of it showing for mouse clicking to raise is a
> corner case I may not want all of the time.

You mean lowering the frame would continue to show parts of it not
hidden by other applications' windows while minimizing the frame would
not show aynthing.  I still wonder why you don't just actively switch
to that other application's window (with the mouse or via Alt-Tab)
instead of using 'lower-frame' which would just passively reveal the
window that happens to be beneath the one of the Emacs frame.

martin




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Thu, 22 Aug 2019 01:25:02 GMT) Full text and rfc822 format available.

Message #17 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: martin rudalics <rudalics <at> gmx.at>
Cc: VanL <van <at> scratch.space>, 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request;
 bury-frame command for desktop-wm
Date: Wed, 21 Aug 2019 21:24:16 -0400
martin rudalics wrote:

> Whatever 'bury-buffer' does, it's effect can be fully controlled by
> Emacs itself.  'lower-frame' has Emacs ask the window manager to put
> the window of an Emacs frame at the bottom of the z-order of visible
> windows.  Thereafter, the effect of this operation is completely with
> the window manager and Emacs has no control over it.

I expect any decent window manager to offer a (customizable) key binding
for this operation. Eg with XFCE I have it bound to window-key + down-arrow.
This works for all applications; so I don't see a need for an
Emacs-specific key-binding.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Thu, 22 Aug 2019 12:37:01 GMT) Full text and rfc822 format available.

Message #20 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: VanL <van <at> scratch.space>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Glenn Morris <rgm <at> gnu.org>, 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request;
 bury-frame command for desktop-wm
Date: Thu, 22 Aug 2019 22:36:18 +1000
martin rudalics <rudalics <at> gmx.at> writes:

> Whatever 'bury-buffer' does, it's effect can be fully controlled by

I don't know the extent of interpenetration Emacs&WM have.  The b for
bury binds to 'Buffer-menu-bury' in the `*Buffer List*' which was what I
also wanted to do to the frame.

> So all you want is that Emacs by default assigns a keyboard shortcut
> to 'lower-frame'.  Which combination did you have in mind?

Everybody has their pref for keybinding and I know better to keep my
defpref to myself.  I'm after the 'command' to lowerframe and that is
all to see multiple corners of many apps and their frames like a poker
player's hand of cards.

> I still wonder why you don't just actively switch
> to that other application's window (with the mouse or via Alt-Tab)
> instead of using 'lower-frame' which would just passively reveal the
> window that happens to be beneath the one of the Emacs frame.

In my case Command-Tab does the app-to-app context switch; it is too
coarse a move.  All the frames belonging to app get foregrounded.  If I
am able to stay in Emacs to use lowerframe on specific frame I may only
want to read what's in the other app without touching it and then
resurface specific Emacs frame again.  There I've avoided touching the
mouse completely.

Like Glenn says XFCE has window-key + down-arrow, I'm asking for the
command to do that.  I'm not asking for key-binding.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Fri, 23 Aug 2019 07:47:02 GMT) Full text and rfc822 format available.

Message #23 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: VanL <van <at> scratch.space>
Cc: Glenn Morris <rgm <at> gnu.org>, 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request; bury-frame command for
 desktop-wm
Date: Fri, 23 Aug 2019 09:46:27 +0200
> Everybody has their pref for keybinding and I know better to keep my
> defpref to myself.  I'm after the 'command' to lowerframe and that is
> all to see multiple corners of many apps and their frames like a poker
> player's hand of cards.

I'm probably too silly to understand what you mean:


lower-frame is an interactive built-in function in ‘C source code’.

(lower-frame &optional FRAME)

  Probably introduced at or before Emacs version 19.29.

Send FRAME to the back, so it is occluded by any frames that overlap it.
If you don’t specify a frame, the selected frame is used.
If Emacs is displaying on an ordinary terminal or some other device which
doesn’t support multiple overlapping frames, this function does nothing.


Please try to understand that I'm apparently missing some detail in
what you want to achieve.

> Like Glenn says XFCE has window-key + down-arrow, I'm asking for the
> command to do that.  I'm not asking for key-binding.

But why does 'lower-frame' not do for your Emacs frame what XFCE's
window-key + down-arrow does for Glen's?

martin





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Fri, 23 Aug 2019 09:29:02 GMT) Full text and rfc822 format available.

Message #26 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: VanL <van <at> scratch.space>
To: martin rudalics <rudalics <at> gmx.at>
Cc: Glenn Morris <rgm <at> gnu.org>, 37079 <at> debbugs.gnu.org
Subject: Re: bug#37079: 26.2.90 feature request;
 bury-frame command for desktop-wm
Date: Fri, 23 Aug 2019 19:28:16 +1000
martin rudalics <rudalics <at> gmx.at> writes:

>> I'm after the 'command' to lowerframe and that is all to see multiple
>> corners of many apps and their frames like a poker player's hand of
>> cards.
>
> I'm probably too silly to understand what you mean: lower-frame [...]

I see, now.  Thanks.  What I needed to do was:

 1. C-h a "lower frame" <-- I looked up the same term in a search engine
 and then I recycled the use of the term 'bury' for 'lower' from
 familiarity with the commands on buffer list to write-up this feature
 request.

> Please try to understand that I'm apparently missing some detail in
> what you want to achieve.

Thank you for your patience.

>> Like Glenn says XFCE has window-key + down-arrow, I'm asking for the
>> command to do that.  I'm not asking for key-binding.
>
> But why does 'lower-frame' not do for your Emacs frame what XFCE's
> window-key + down-arrow does for Glen's?

The two commands 'lower-frame' and 'raise-frame' are exactly what I was
wanting and they are already there in Emacs and work plainly according
to their name.  I didn't try to find them in the most obvious way, as above.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#37079; Package emacs. (Fri, 24 Jan 2020 00:28:01 GMT) Full text and rfc822 format available.

Message #29 received at 37079 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: VanL <van <at> scratch.space>
Cc: martin rudalics <rudalics <at> gmx.at>, 37079 <at> debbugs.gnu.org,
 Glenn Morris <rgm <at> gnu.org>
Subject: Re: bug#37079: 26.2.90 feature request; bury-frame command for
 desktop-wm
Date: Fri, 24 Jan 2020 01:26:52 +0100
close 37079
tags 37079 + notabug
thanks

VanL <van <at> scratch.space> writes:

>> But why does 'lower-frame' not do for your Emacs frame what XFCE's
>> window-key + down-arrow does for Glen's?
>
> The two commands 'lower-frame' and 'raise-frame' are exactly what I was
> wanting and they are already there in Emacs and work plainly according
> to their name.  I didn't try to find them in the most obvious way, as above.

If I read this correctly, the commands the reporter asked for is
already in Emacs.  So I'm closing this bug.

Best regards,
Stefan Kangas




bug closed, send any further explanations to 37079 <at> debbugs.gnu.org and VanL <van <at> scratch.space> Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Fri, 24 Jan 2020 00:28:02 GMT) Full text and rfc822 format available.

Added tag(s) notabug. Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Fri, 24 Jan 2020 00:28:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Fri, 21 Feb 2020 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 4 years and 64 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.