>> If I do (setq special-display-regexps '("[ ]?[*][^*]+[*]")), then when I hit >> `d' in the debugger, the debugger frame iconifies.
> Doesn't it de-iconify right after (thus flashing)? That's very odd. > No; it does not deiconify. Oh, I think I know what it is: that's because of Richard's new code which uses just `select-window' instead of `pop-to-buffer' and thus fails to de-iconify. > If it did, I would consider that too to be a bug - why would one want the > debugger frame to first be iconified and then be deiconified each time you > issue a debugger command? Yes, it'd also be a bug. But it'd be fixed by the last patch I sent. >> I don't understand: >> - Why bury-buffer iconifies. > Because of the case where you hit `q' or `c' or ... rather than `d'. > I don't understand what you are saying here. I'm saying that in the case of `q' or `c', I don't want the keep displaying the frame, instead I want it iconified. > It iconifies with every command, including `d'. But, aside from `d', why > should it iconify with `q' or `c'? Because `q' and `c' both really leave the debugger so you don't want to keep an empty *Backtrace* buffer/window/frame staring at you. > If you hit `q', perhaps iconifying is OK. However, I think quit-window or > killing the buffer and deleting the window (and frame) would be better than > iconifying the frame. Have you read the patches I sent and the corresponding code? It includes a comment explaining why. > Even if iconifying were OK for `q', why do that when you hit `c'? You are > still using the debugger window/buffer/frame, no? Sometimes, but usually no. Or at least I won't get back into the debugger immediately (contrary to `d'). > Why would you want to bury or iconify the buffer with `c'? It should > remain displayed, so you can use it. You can't really use it any more: at that point it's empty (until you re-enter the debugger). > Actually the code is used when we leave the debugger. It's just that > when you use `d' you only leave the debugger temporarily. > I don't see why you (or the code) would consider `d' to "leave" the > debugger, even temporarily. In what sense is the user leaving it? The debugger is entered by calling the function `debug' and is exited when the `debug' function returns. The code in question is executed at the end of `debug' just before exiting. I.e. technically, `d' causes Emacs to leave the debugger while setting up the evaluator to "immediately" re-enter the debugger. This is admittedly irrelevant to the user, so the last patch I sent you tries to hide it, but it is the reason why I consider `d' to "leave" the debugger. > Even if one considers `d' to "leave" the debugger, that way of "leaving" it > requires a completely different behavior from quitting it (`q)', IMO. Agreed, thus my patch. > If you look at what happens in a single-frame case, the code > deletes/creates a window at each step. > I don't see why it should do that either. The why is not really relevant: it's what it does (by wrapping the body of `debug' within a save-window-excursion). > You're still in the debugger; why delete and re-create the window? Does > that perhaps represent some kind of optimization? It's invisible to the > user in this case, so I don't mind, but I don't understand why it should > be done. Yes, it's invisible as long as Emacs doesn't refresh the display between the time when you hit `d' and the next function call which causes Emacs to re-enter the debugger. Sadly, contrary to what happens for window where window creation/deletion is propagated to the display upon redisplay, frame creation/deletion is effected immediately so the iconify/deiconify causes flashing whereas the deletion&re-creation of the window is usually not visible. > I still don't see why any of the debugger commands should delete and > recreate, or iconify and deiconify, or erase and redraw ... windows and > frames. As long as you are in the debugger, it should remain displayed, IMO. > When you quit, the debugger buffer and its window or frame (if one-window-p) > should be deleted completely. There's no way to know, when you quit, that you're quitting "for ever". In practice, when I hit `q' it's quite frequent that I'll be getting back to the debugger pretty soon. Deleting the buffer+window+frame means losing the size&placement information, which I find very annoying. Stefan _______________________________________________ Emacs-pretest-bug mailing list Emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug