emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: debugger with pop-up-frames non-nil: keeps creating new frames


From: Stefan Monnier
Subject: Re: debugger with pop-up-frames non-nil: keeps creating new frames
Date: Fri, 10 Jun 2005 14:12:39 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

> From a user point of view, `c' continues debugging (without digging deeper
> like `d' does), and `q' quits debugging. I'm speaking only from a user point
> of view. What the implementation considers "leaving", "aborting",
> "continuing", etc. I don't really care about.

I understand.  I am just trying to explain to you the technical side as
well, so you may better understand the code (this is emacs-devel after all)
and may also better help us figure out the best solution.

> Yes, I too mentioned that at the top level `c' effectively takes you out.
> Nevertheless, if it is too complex to distinguish this case, then just let
> users use `q' to signal that they are finished.

The current code (as of yesterday) should get this right.

> I suggested making the frame invisible (instead of deleting or iconifying
> it) when the buffer is left definitively - that should keep the
> size&positition info. Have you tried that? After all, that's what we're
> after here: I want to stop displaying the frame, and you want to retain its
> size&position info. Just set the visible frame parameter to nil, and leave
> the size and position info as is.

invisible frames are poorly supported (they'd require significant further
changes since pop-to-buffer wouldn't make it visible again), and
I definitely prefer it being iconified.  If it's really so important for the
two of us to have different behaviors in the same cases, maybe a config var
is in order.

I suspect a major reason is that my window manager has no trouble handling
dozens of windows (aka frames), whereas yours makes it more painful.
Although last time I tried Windows's grouping (which places every
window/frame of the same application in a single spot in the bar) it
worked well.

>     I think I'm beginning to understand a bit more what you're complaining
>     about.  IIUC you use debug-on-error extensively, whereas I use
                                    ^^^^^
                                    entry
>     edebug for
>     those situations.  I mostly only use the `debug' debugger via
>     debug-on-error, debug-on-signal, debug-on-quit, or an explicit call to
>     (debug).

> Is there a typo there somewhere?

Yes, sorry.

> I've never used edebug.  Actually, I tried it a couple times, but had bad
> luck with it (I don't remember the details).

Impressive.  I got hooked the very first time I tried it.  It's really neat,
you should try it again.

>>> You're still in the debugger; why delete and re-create the window?

>     Probably for simple implementation reasons.  And maybe also so that the
>     code itself is run in an environment unaffected by the debugger.
>     I.e. without the extra window.

> You might want to check how it was done in Emacs 20. Things seemed to DTRT
> then, IMO.

It deleted and recreated the window.
As for the frames (if you used pop-up-frames or special-display-regexp), it
just left the backtrace frame around, which I find very inconvenient.


        Stefan




reply via email to

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