> 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
_______________________________________________
Emacs-pretest-bug mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
