Hello,
When developing GUI applications, I find it essential to have the Emacs frame pop up when my application signals an unhandled error. The problem is that the debugger will often pop up while I'm interacting with the application (and Emacs is usually hidden somewhere beneath it), so I would often be left staring at a frozen GUI not understanding what was happening.
This pull request https://github.com/slime/slime/pull/92 makes the frame raise.
It also does the same thing when entering `slime-ed' and `slime-open-inspector' for similar reasons. In my particular case, sometimes those events come from the application GUI, sometimes from the Allegro CL IDE.
I have two questions for my fellow SLIME users:
1. is there any situation where this behaviour would be undesirable?
2. if so, we need a customisation variable. Which behaviour should be the default one?
Thanks, Luís
- if so, we need a customisation variable. Which behaviour should be the default one?
for SLDB popup should be the default.
for the other two it's not that obvious, but i'm leaning towards popup as the default.
On Thu, Jan 16 2014, Luís Oliveira wrote:
I have two questions for my fellow SLIME users:
is there any situation where this behaviour would be undesirable?
if so, we need a customisation variable. Which behaviour should be the default one?
These decisions should be left to Emacs's display-buffer function, which can be customized with stuff like display-buffer-overriding-action and related variables. Frame/window management is a can of worms that's better left outside of SLIME's scope.
Helmut
On Thu, Jan 16, 2014 at 6:33 PM, Helmut Eller eller.helmut@gmail.com wrote:
These decisions should be left to Emacs's display-buffer function, which can be customized with stuff like display-buffer-overriding-action and related variables. Frame/window management is a can of worms that's better left outside of SLIME's scope.
So, you mean I could make Emacs raise the frame everytime a new buffer is displayed? (I suppose that would cover ed, sldb, inspector.) Can you give me an hint on how to set that up?
On Thu, Jan 16 2014, Luís Oliveira wrote:
On Thu, Jan 16, 2014 at 6:33 PM, Helmut Eller eller.helmut@gmail.com wrote:
These decisions should be left to Emacs's display-buffer function, which can be customized with stuff like display-buffer-overriding-action and related variables. Frame/window management is a can of worms that's better left outside of SLIME's scope.
So, you mean I could make Emacs raise the frame everytime a new buffer is displayed? (I suppose that would cover ed, sldb, inspector.) Can you give me an hint on how to set that up?
(setq display-buffer-alist '(("^\*sldb" . ((lambda (buffer alist) (raise-frame)) . nil))))
Helmut
On Thu, Jan 16, 2014 at 7:02 PM, Helmut Eller eller.helmut@gmail.com wrote:
(setq display-buffer-alist '(("^\*sldb" . ((lambda (buffer alist) (raise-frame)) . nil))))
Cool. How do you feel about a slime-raise-frame contrib that sets this up? (I'll probably have to resort to defadvice for slime-ed, though.)
On Thu, Jan 16 2014, Luís Oliveira wrote:
On Thu, Jan 16, 2014 at 7:02 PM, Helmut Eller eller.helmut@gmail.com wrote:
(setq display-buffer-alist '(("^\*sldb" . ((lambda (buffer alist) (raise-frame)) . nil))))
Cool. How do you feel about a slime-raise-frame contrib that sets this up?
I wouldn't spend my time on window management because it's a difficult problem. But don't let me stop you.
(I'll probably have to resort to defadvice for slime-ed, though.)
defadvice shouldn't be needed if you can change the source, e.g., you could add a hook. Maybe it would be better to delegate everything to server-visit-files.
Helmut
On Thu, Jan 16, 2014 at 7:29 PM, Helmut Eller eller.helmut@gmail.com wrote:
I wouldn't spend my time on window management because it's a difficult problem. But don't let me stop you.
FWIW, we've been using this scheme at work for 2 or 3 years and it works pretty well.
(I'll probably have to resort to defadvice for slime-ed, though.)
defadvice shouldn't be needed if you can change the source, e.g., you could add a hook. Maybe it would be better to delegate everything to server-visit-files.
I'll look into it. Thanks for the tips.
-
Attila Lendvai -
Helmut Eller -
Luís Oliveira