view-remove-frame-by-deleting ignored?

view-remove-frame-by-deleting ignored?

[Thorsten Bonow]

Hi,

it appears that view-remove-frame-by-deleting is set to t by default to no effect.

It should "Determine how View mode removes a frame no longer needed.  If nil, make an icon of the frame.  If non-nil, delete the frame."

Here (GNU Emacs 28.1, Debian Unstable), the frame is always iconified:

emacs -Q
M-x view-file-other-frame
<choose a file to view>
Press "q" for View-quit

The frame is iconified but not removed.  Is this correct?  How can I delete the
frame on quitting?

Any help is appreciated.

Toto


-- 
Sent from my GNU Emacs running on GNU/Linux

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> emacs -Q
> M-x view-file-other-frame
> <choose a file to view>
> Press "q" for View-quit
> 
> The frame is iconified but not removed.  Is this correct?  How can I
> delete the frame on quitting?

Try customizing option `frame-auto-hide-function' to `delete-frame' instead of the default value of `iconify-frame'.

Yes, it's too bad that this option isn't more easily discoverable.  Perhaps it should be mentioned in the doc string of `view-remove-frame-by-deleting'?  Perhaps it should be mentioned in doc strings of other view-mode thingies?

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> Try customizing option `frame-auto-hide-function'
> to `delete-frame' instead of the default value
> of `iconify-frame'.
> 
> Yes, it's too bad that this option isn't more
> easily discoverable.  Perhaps it should be
> mentioned in the doc string of
> `view-remove-frame-by-deleting'?  Perhaps it
> should be mentioned in doc strings of other
> view-mode thingies?

If you check the binding of `q' in view-mode it
tells you it's bound to `View-quit'.  But nothing
in that function's doc string gives you a hint
that option can be used to delete the frame if
the file being viewed is alone in its frame.

It's `quit-restore-window' that uses the option,
and so ends up deleting the frame.  And that's
called by `quit-window', which is called by
`View-quit'.

There's no top-level, easy way for a user to
know this, I think.  The doc of view-mode should
definitely point it out better, IMO.

Re: [External] : view-remove-frame-by-deleting ignored?

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> It's `quit-restore-window' that uses the option,
> and so ends up deleting the frame.  And that's
> called by `quit-window', which is called by
> `View-quit'.

Where?

I don't seem to be able to find any place where this variable is
referenced in the Emacs sources.  Toggling the option also doesn't seem
to have any effect.  Or am I too tired (could be)?

Michael.

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> > Try customizing option `frame-auto-hide-function'
> > to `delete-frame' instead of the default value
> > of `iconify-frame'.
> > ...
> > It's `quit-restore-window' that uses the option,
> > and so ends up deleting the frame.  And that's
> > called by `quit-window', which is called by
> > `View-quit'.
> 
> Where?
> 
> I don't seem to be able to find any place where this
> variable is referenced in the Emacs sources.  Toggling
> the option also doesn't seem to have any effect.
> Or am I too tired (could be)?

Hadn't try to find exactly where it's done (but
see below).  I see this, e.g., in Emacs 28.1 (and
earlier):

emacs -Q

M-x debug-on-entry quit-restore-window
M-x view-file-other-frame foo.el

Step through and you'll see something like this:

Debugger entered--entering a function:
* iconify-frame(#<frame *Backtrace* 000001e4b300f470>)
* window--delete(#<window 70 on foo.el> nil nil)
* #<subr quit-restore-window>(nil bury)
* apply(#<subr quit-restore-window> (nil bury))
* quit-restore-window(nil bury)
  quit-window()
  view-mode-exit(nil kill-buffer-if-not-modified)
  View-quit()
  funcall-interactively(View-quit)
  command-execute(View-quit)

Get rid of the frame and buffer for foo.el, to start
over.

Use `M-x customize-option frame-auto-hide-function'
to set the option to `delete-frame' (instead of the
default, `iconify-frame').

M-x view-file-other-frame foo.el

Step through and you'll see something like this:

Debugger entered--entering a function:
* delete-frame(#<frame *Backtrace* 000001e4b3017840>)
* window--delete(#<window 7 on foo.el> nil nil)
* #<subr quit-restore-window>(nil bury)
* apply(#<subr quit-restore-window> (nil bury))
* quit-restore-window(nil bury)
  quit-window()
  view-mode-exit(nil kill-buffer-if-not-modified)
  View-quit()
  funcall-interactively(View-quit)
  command-execute(View-quit)

In more detail, it comes from this return value
from `window-deletable':

Debugger entered--returning value: frame
  window-deletable-p(#<window 124 on foo.el>)
* #<subr window--delete>(#<window 124 on foo.el> nil nil)
* apply(#<subr window--delete> (#<window 124 on foo.el> nil nil))
* window--delete(#<window 124 on foo.el> nil nil)
  quit-restore-window(nil bury)
  quit-window()
  view-mode-exit(nil kill-buffer-if-not-modified)
  View-quit()
  funcall-interactively(View-quit)
  command-execute(View-quit)

And that's from this code in `window-deletable-p':

(cond
 ((frame-root-window-p window)
  ;; WINDOW's frame can be deleted only if there are other frames
  ;; on the same terminal, and it does not contain the active
  ;; minibuffer.
  (unless (or (eq frame (next-frame frame 0))
          ;; We can delete our frame only if no other frame
          ;; currently uses our minibuffer window.
          (catch 'other
            (dolist (other (frame-list))
              (when (and (not (eq other frame))
                         (eq (window-frame
                               (minibuffer-window other))
                         frame))
                (throw 'other t))))
          (let ((minibuf (active-minibuffer-window)))
            (and minibuf (eq frame (window-frame minibuf))
                 (not (eq (default-toplevel-value
                            'minibuffer-follows-selected-frame)
                          t)))))
    'frame))

Re: [External] : view-remove-frame-by-deleting ignored?

[Thorsten Bonow]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

>> > Try customizing option `frame-auto-hide-function' > to `delete-frame'
>> instead of the default value > of `iconify-frame'.  > ...  > It's
>> `quit-restore-window' that uses the option, > and so ends up deleting the
>> frame.  And that's > called by `quit-window', which is called by >
>> `View-quit'.
>> 
>> Where?
>> 
>> I don't seem to be able to find any place where this variable is referenced
>> in the Emacs sources.  Toggling the option also doesn't seem to have any
>> effect.  Or am I too tired (could be)?

> Hadn't try to find exactly where it's done (but see below).  I see this,
> e.g., in Emacs 28.1 (and earlier):

> emacs -Q

> M-x debug-on-entry quit-restore-window M-x view-file-other-frame foo.el

> Step through and you'll see something like this:

> Debugger entered--entering a function: * iconify-frame(#<frame *Backtrace*
> 000001e4b300f470>) * window--delete(#<window 70 on foo.el> nil nil) * #<subr
> quit-restore-window>(nil bury) * apply(#<subr quit-restore-window> (nil
> bury)) * quit-restore-window(nil bury) quit-window() view-mode-exit(nil
> kill-buffer-if-not-modified) View-quit() funcall-interactively(View-quit)
> command-execute(View-quit)

> Get rid of the frame and buffer for foo.el, to start over.

> Use `M-x customize-option frame-auto-hide-function' to set the option to
> `delete-frame' (instead of the default, `iconify-frame').

> M-x view-file-other-frame foo.el

> Step through and you'll see something like this:

> Debugger entered--entering a function: * delete-frame(#<frame *Backtrace*
> 000001e4b3017840>) * window--delete(#<window 7 on foo.el> nil nil) * #<subr
> quit-restore-window>(nil bury) * apply(#<subr quit-restore-window> (nil
> bury)) * quit-restore-window(nil bury) quit-window() view-mode-exit(nil
> kill-buffer-if-not-modified) View-quit() funcall-interactively(View-quit)
> command-execute(View-quit)

> In more detail, it comes from this return value from `window-deletable':

> Debugger entered--returning value: frame window-deletable-p(#<window 124 on
> foo.el>) * #<subr window--delete>(#<window 124 on foo.el> nil nil) *
> apply(#<subr window--delete> (#<window 124 on foo.el> nil nil)) *
> window--delete(#<window 124 on foo.el> nil nil) quit-restore-window(nil bury)
> quit-window() view-mode-exit(nil kill-buffer-if-not-modified) View-quit()
> funcall-interactively(View-quit) command-execute(View-quit)

> And that's from this code in `window-deletable-p':

> (cond ((frame-root-window-p window) ;; WINDOW's frame can be deleted only if
> there are other frames ;; on the same terminal, and it does not contain the
> active ;; minibuffer.  (unless (or (eq frame (next-frame frame 0)) ;; We can
> delete our frame only if no other frame ;; currently uses our minibuffer
> window.  (catch 'other (dolist (other (frame-list)) (when (and (not (eq other
> frame)) (eq (window-frame (minibuffer-window other)) frame)) (throw 'other
> t)))) (let ((minibuf (active-minibuffer-window))) (and minibuf (eq frame
> (window-frame minibuf)) (not (eq (default-toplevel-value
> 'minibuffer-follows-selected-frame) t))))) 'frame))

Thx, modifying `frame-auto-hide-function' works for me.

I think `view-remove-frame-by-deleting' was forgotten to remove in commit
357f93d245344725f9d7c5b96eadc400107923b6 when `view-mode-exit' was simplified
among other things.

Toto

-- 
Sent from my GNU Emacs running on GNU/Linux

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> Thx, modifying `frame-auto-hide-function' works for me.

You're welcome.

> I think `view-remove-frame-by-deleting' was forgotten to remove in commit
> 357f93d245344725f9d7c5b96eadc400107923b6 when `view-mode-exit' was
> simplified among other things.

Not sure what that means.  I don't use non-released
Emacs builds.  If it would intentionally no longer
be possible to choose to have `quit-window' also
delete the frame, for a one-window frame, then that
would be an unfortunate, misguided change, IMO.  I
hope that's not the going to be the case.

Re: [External] : view-remove-frame-by-deleting ignored?

[Emanuel Berg]

Drew Adams wrote:

> I don't use non-released Emacs builds.

What does that mean, what builds are released?

Change of first, second, or all (any) version number?

-- 
underground experts united
https://dataswamp.org/~incal

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> > I don't use non-released Emacs builds.
> 
> What does that mean, what builds are released?
> Change of first, second, or all (any) version number?

I think 28.2 is the latest release.  29.1 is
not yet released.  37.4 is not yet released.

When 42.x is released the universe will be
done with whatever it's been trying to do.
Or so I hear.  Which universe, you ask?  Each
in which you see this msg.
___

FWIW -

I generally use 26.3, as later releases broke
too much for me. :-(

I keep the latest build of each Emacs major
release (e.g. 24.5, but not 24.4 etc.).  But
I haven't bothered to pick up 28.2 yet.  I
use 27.2 and later only for some testing and
bug reporting.  I use 26.3 for my own use.

I byte-compile my libraries with the oldest
release for which each is compatible.  Which
means I need to load the source later, if I
need some feature from it that requires a
later release than the byte-compiled file.
Lots of code works just fine with Emacs 20.7.

Re: [External] : view-remove-frame-by-deleting ignored?

[Po Lu]

Drew Adams <drew.adams@oracle.com> writes:

> I generally use 26.3, as later releases broke
> too much for me. :-(

Too bad.  I see this a lot with Emacs users as of late, where they pick
some version of Emacs that has not seen development in years (or even
decades) and stick to it, because we break too much.

One such popular version is 25.3, another is 23.4, and yet another is
21.4.

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> > I generally use 26.3, as later releases broke
> > too much for me. :-(
> 
> Too bad.  I see this a lot with Emacs users as of late, where they pick
> some version of Emacs that has not seen development in years (or even
> decades) and stick to it, because we break too much.
> 
> One such popular version is 25.3, another is 23.4, and yet another is
> 21.4.

I really can't speak for anyone else.  I don't
expect that there are lots of people in my
situation.

On the other hand, I imagine there are lots of
developers who use whatever Emacs version is
available already built in the version of
Linux their company uses.  I saw a lot of Emacs
21 for years afterward, when they could have
built 24.x or even 25.x.

The number of Emacs users, is, I expect, far
larger than the number of Emacs aficionados
who frequent Emacs mailing lists, sites, and
Q&A sites.  Lots of users just use it to do
their work.

Re: [External] : view-remove-frame-by-deleting ignored?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Emanuel Berg <incal@dataswamp.org>,  "help-gnu-emacs@gnu.org"
>  <help-gnu-emacs@gnu.org>
> Date: Wed, 12 Oct 2022 08:57:26 +0800
> 
> Drew Adams <drew.adams@oracle.com> writes:
> 
> > I generally use 26.3, as later releases broke
> > too much for me. :-(
> 
> Too bad.  I see this a lot with Emacs users as of late, where they pick
> some version of Emacs that has not seen development in years (or even
> decades) and stick to it, because we break too much.

FTR, in this particular case, our requests that Drew helps us debug
the problem which caused him stick to 26.3 were met with refusal.  No
one else reported or experienced those problems, so without Drew's
help we cannot make any progress.  This is all in the archives of the
bug tracker.

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> > > I generally use 26.3, as later releases
> > > broke too much for me. :-(
> >
> > Too bad.  I see this a lot with Emacs users
> > as of late, where they pick some version of
> > Emacs that has not seen development in years
> > (or even decades) and stick to it, because
> > we break too much.
> 
> FTR, in this particular case, our requests that
> Drew helps us debug the problem which caused him
> stick to 26.3 were met with refusal.

That is _absolutely_ untrue.  A completely unfair
characterization.

I provided the info I could, with the time and
know-how I have available.  Trying to track down
the problem in more detail is beyond me, as I've
explained.  I never once complained that someone
else needs to do something to investigate the
problem.

It's my problem.  Never said otherwise.  I don't
know what Emacs changes led to the problems.

I'm not expecting Emacs development to cater to
my setup.  Never have.  I can't make good use of
Emacs after release 26, but I don't expect that
to change.

I use Emacs 26 and earlier, and unless something
unexpectedly fixes the problems I have with later
releases I'll no doubt continue to use 26.  It's
not the end of the world, for me at least.  I'm a
happy camper (even though I'd prefer to benefit
from the good that's been done in later releases).

I haven't complained that Emacs hasn't fixed what
got broken.  I've only reported the problems
(what little I can).

I've anyway held out a glimmer of hope (without
any expectation) that, whether by accident or by
discovery (e.g. someone else having such problems
at some point, and able to provide a reproducible
recipe), some fixes might just happen - that's
happened in the past (in particular wrt frame /
window / minibuffer problems).

I'm not waiting for that.  I can use Emacs 26
with my full setup.  That works for me.  And I
of course test my libraries with more recent
releases, for the benefit of other users.

It's only with my standalone minibuffer frame
that I experience the minibuffer focus-change
problems.  I don't know of any problems with my
libraries.  (And yes, I prefer Emacs 26 with my
standalone minibuffer to later releases without
it.)

> No one else reported or experienced those problems,

I never claimed otherwise.  Although I believe
that Stefan Monnier (cc'd) has also indicated,
more than once, that he has/had some similar
problems wrt minibuffer frame focus.  I believe
he said the problems he experience[ds] started
with Emacs 26.  (I can use 26 OK, generally.)
Both he and I use a standalone minibuffer frame.

To be clear, I don't/can't speak for Stefan,
and I don't believe he's given any more info
about his problems in this regard.  But I think
he did chime in a few times to say that he
experience[ds] similar focus problems.  He'll
correct me if I'm mistaken.

> so without Drew's help we cannot make any progress.

I never claimed or expected otherwise.  I've
moved on.  I have a life to live. ;-)

> This is all in the archives of the bug tracker.

And I invite anyone interested to dig it all out
of there.  I don't recall the bug (or emacs-devel)
threads, but perhaps you'll point folks to them,
instead of just insinuating things?

For some reason Eli, you never miss an opportunity
to attack me personally.  Too bad.  Hope it does
you some good, somehow.  Beyond that, I hope, for
your sake, you get past that need someday.

Re: [External] : view-remove-frame-by-deleting ignored?

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 12 Oct 2022 15:33:14 +0000
> 
> > > > I generally use 26.3, as later releases
> > > > broke too much for me. :-(
> > >
> > > Too bad.  I see this a lot with Emacs users
> > > as of late, where they pick some version of
> > > Emacs that has not seen development in years
> > > (or even decades) and stick to it, because
> > > we break too much.
> > 
> > FTR, in this particular case, our requests that
> > Drew helps us debug the problem which caused him
> > stick to 26.3 were met with refusal.
> 
> That is _absolutely_ untrue.  A completely unfair
> characterization.

It's fair and true.  As you yourself describe:

> I provided the info I could, with the time and
> know-how I have available.  Trying to track down
> the problem in more detail is beyond me, as I've
> explained.

Exactly: once we asked for more effort than you were prepared to
invest you said no.  How is that not a refusal?  You were told several
times that you are the only one who can reproduce the problem, and you
still declined to help more.  So here we are today.

> I'm not expecting Emacs development to cater to
> my setup.  Never have.  I can't make good use of
> Emacs after release 26, but I don't expect that
> to change.

Then please make a point of saying this when you mention that you
stick to Emacs 26.3, lest people who aren't privy to the history of
this don't fall into the trap of thinking we break stuff and don't
bother fixing it.

> For some reason Eli, you never miss an opportunity
> to attack me personally.  Too bad.

It's actually the other way around.

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> > For some reason Eli, you never miss an 
> > opportunity to attack me personally.
> > Too bad.
> 
> It's actually the other way around.

No, it's not.  At all.

And I've volunteered repeatedly that I really
appreciate the job you do as Emacs maintainer.

Of all those active in Emacs devel, we're
fortunate, IMO, that you're the main guy.
And I don't say such things gratuitously.

And in particular I appreciate your carefulness
in conservatively making changes.  And your
attention to doc.

None of that makes any difference to you, alas.

Re: [External] : view-remove-frame-by-deleting ignored?

[Michael Heerdegen]

Drew Adams <drew.adams@oracle.com> writes:

> > > For some reason Eli, you never miss an 
> > > opportunity to attack me personally.
> > > Too bad.
> > 
> > It's actually the other way around.
>
> No, it's not.  At all.

If you want an outside perspective: if it is (maybe it is), it is both
ways.  Sorry.

Michael.

Re: [External] : view-remove-frame-by-deleting ignored?

[Emanuel Berg]

Po Lu wrote:

>> I generally use 26.3, as later releases broke too much for
>> me. :-(
>
> Too bad. I see this a lot with Emacs users as of late, where
> they pick some version of Emacs that has not seen
> development in years (or even decades) and stick to it,
> because we break too much.

Break too much, what? Old code?

I have not had any such issues and the little that is reported
by the byte-compiler is just interesting, rather, to fix.

Like Mr Neo said, "Upgrades" ...

-- 
underground experts united
https://dataswamp.org/~incal

Re: [External] : view-remove-frame-by-deleting ignored?

[Thorsten Bonow]

>>>>> Drew Adams <drew.adams@oracle.com> writes:

>> Thx, modifying `frame-auto-hide-function' works for me.
> You're welcome.

>> I think `view-remove-frame-by-deleting' was forgotten to remove in commit
>> 357f93d245344725f9d7c5b96eadc400107923b6 when `view-mode-exit' was
>> simplified among other things.

> Not sure what that means.  I don't use non-released Emacs builds.  If it
> would intentionally no longer be possible to choose to have `quit-window'
> also delete the frame, for a one-window frame, then that would be an
> unfortunate, misguided change, IMO.  I hope that's not the going to be the
> case.

This was done in 2011... As I understand, only the possibility to configure
view-mode to delete the frame when calling `View-exit' was lost.  The code
checking the value of `view-remove-frame-by-deleting' was removed from
`view-mode-exit' but the variable itself was not deleted.

See https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/view.el?id=357f93d245344725f9d7c5b96eadc400107923b6

Toto

-- 
Sent from my GNU Emacs running on GNU/Linux

RE: [External] : view-remove-frame-by-deleting ignored?

[Drew Adams]

> This was done in 2011... As I understand, only the possibility to
> configure view-mode to delete the frame when calling `View-exit'
> was lost.  The code checking the value of
> `view-remove-frame-by-deleting' was removed from `view-mode-exit'
> but the variable itself was not deleted.

I see. I misunderstood - misread what you wrote.

Re: [External] : view-remove-frame-by-deleting ignored?

[Michael Heerdegen]

Thorsten Bonow <thorsten.bonow@post.rwth-aachen.de> writes:

> Thx, modifying `frame-auto-hide-function' works for me.
>
> I think `view-remove-frame-by-deleting' was forgotten to remove in
> commit 357f93d245344725f9d7c5b96eadc400107923b6 when `view-mode-exit'
> was simplified among other things.

Looks like that, yes.  Thanks for discovering.  Can you please make a
bug report?

Thx,

Michael.

Re: [External] : view-remove-frame-by-deleting ignored?

[Thorsten Bonow]

>>>>> Michael Heerdegen <michael_heerdegen@web.de> writes:

> Looks like that, yes.  Thanks for discovering.  Can you please make a bug
> report?

Done: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58413

Toto

--
Sent from my GNU Emacs running on GNU/Linux

Re: [External] : view-remove-frame-by-deleting ignored?

[Michael Heerdegen]

Thorsten Bonow <thorsten.bonow@post.rwth-aachen.de> writes:

> > Looks like that, yes.  Thanks for discovering.  Can you please make a bug
> > report?
>
> Done: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=58413

Thanks, Thorsten.

Michael.