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

[Drew Adams]

    > 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, thanks. I didn't mean that I wasn't interested. I was just trying to
hammer home that my ultimate interest is the user's.

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

Great. I'm busy right now, but I'll give it a try when I can.

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

Yes, a user option would be OK. On Windows, at least, iconifying is not
livable here. Perhaps the default value of the option could be one thing for
Windows and another for Unix - or would that be too confusing?

I kind of suspected there might be problems with invisible frames. I've had
other problems with them. But that, logically, should satisfy us both (if it
worked), if your concern is saving size&position.

    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.

I don't feel that. My objection is to something iconifying and deiconifying
while I'm in the middle of using it. I too use dozens of frames - and icons
too.

(In fact, I even use thumbnail frames
(http://www.emacswiki.org/cgi-bin/wiki/FisheyeWithThumbs) on the desktop as
pseudo-icons most of the time, instead of using task-bar icons. So you can
see that I don't mind a lot of icons taking up real estate.)

I don't mean to defend Windows, but I don't feel it has a problem wrt frames
(except wrt mouse-follows-focus).

    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.

Yes, I use that (whenever I don't want a thumbnail frame) - it's the default
in Windows XP. Again, the pb is not the number of icons.

In addition to interruptions from unnecessary iconifying and deiconifying,
if a no-longer-used buffer (such as *Backtrace* after you are done
debugging) were kept around as an (empty) icon, it would clutter things up a
bit more.

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

OK, I will. I don't remember what the problem was.

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

I have no problem with that, as I mentioned (`C-x 5 0'). The user option you
mentioned could simply allow that, although your fix for `c' (when returned
to top-level) and `q' to delete the frame would be better, I think. Or it
could be a three-way option: delete, iconify, leave displayed.

BTW, as long as you're in the debugger code (feature-creep warning): What
about using function-called-at-point (or symbol-at-point) to provide the
default function to debug in debug-on-entry (as in describe-function)? Most
of the time you use the debugger you're in an emacs-lisp buffer, so picking
up a lisp symbol would be helpful.

 - Drew