unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: ahyatt@gmail.com, lennart.borgman@gmail.com, 5482@debbugs.gnu.org
Subject: bug#5482: frame-invisible-p reports nil for iconified frames on w32
Date: Sun, 26 Jun 2016 18:58:30 +0300	[thread overview]
Message-ID: <83bn2oymah.fsf@gnu.org> (raw)
In-Reply-To: <576FABF6.2050800@gmx.at> (message from martin rudalics on Sun, 26 Jun 2016 12:18:30 +0200)

> Date: Sun, 26 Jun 2016 12:18:30 +0200
> From: martin rudalics <rudalics@gmx.at>
> Cc: 5482@debbugs.gnu.org
> 
>  >> Create a frame
>  >>
>  >>    (setq my-frame (make-frame))
>  >>
>  >> Iconify it. Then make it first invisible and then visible again:
>  >>
>  >>    (make-frame-invisible my-frame)
>  >>    (make-frame-visible my-frame)
>  >>
>  >> The result of checking if it is visible is now nil (should be `iconified'):
>  >>
>  >>    (frame-visible-p my-frame)
>  >>
>  >> This is with a fresh checkout from yesterday.
>  >>
>  >>
>  >> BTW the implementation of frame-visible-p seems a bit strange to me on
>  >> w32. It is easy to check visibility using GetWindowPlacement, but is
>  >> this used?
>  >
>  > Sorry for the late reply here.  In Emacs 25, the behavior is different,
>  > at least for me in Mac OS X.  Now, when I do (make-frame-visible
>  > my-frame), the frame uniconifies and becomes a normal window again.
> 
> And that's wrong according to the OP. The frame should stay iconified.

AFAIU, there are actually 2 issues here: the nil value returned by
frame-visible-p, which is what I see here if frame-visible-p is
invoked immediately after make-frame-visible, i.e. without letting
Emacs enter redisplay; and the fact that the frame becomes a normal
window.

The first issue is expected, since we ask the UI thread to update the
frame's display, and that takes some short time.  In general, one
shouldn't expect the effect of changing frame visibility to be
reflected to Lisp immediately; a call to sit-for is a good idea.

As for the second issue, I disagree that this behavior is wrong,
because it matches the documentation:

  A frame on a graphical display may be “visible”, “invisible”, or
  “iconified”.  If it is visible, its contents are displayed in the usual
		^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  manner.  If it is iconified, its contents are not displayed, but there
  ^^^^^^
  is a little icon somewhere to bring the frame back into view (some
  window managers refer to this state as “minimized” rather than
  “iconified”, but from Emacs’ point of view they are the same thing).  If
  a frame is invisible, it is not displayed at all.

   -- Command: make-frame-visible &optional frame
       This function makes frame FRAME visible.

So I see no reason to fix anything in what make-frame-visible does in
this case.

I could perhaps agree that iconify-frame should have undone the effect
of make-frame-invisible in this use case, though.





  reply	other threads:[~2016-06-26 15:58 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-01-26 20:37 bug#5482: frame-invisible-p reports nil for iconified frames on w32 Lennart Borgman
2016-06-26  3:56 ` Andrew Hyatt
2016-06-26 10:18   ` martin rudalics
2016-06-26 15:58     ` Eli Zaretskii [this message]
2016-06-27  6:22       ` martin rudalics
2016-06-27 15:40         ` Eli Zaretskii
2016-06-27 16:56           ` martin rudalics
2016-06-28 16:00             ` Eli Zaretskii
2018-06-14  0:48         ` Noam Postavsky

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=83bn2oymah.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=5482@debbugs.gnu.org \
    --cc=ahyatt@gmail.com \
    --cc=lennart.borgman@gmail.com \
    --cc=rudalics@gmx.at \
    /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).