bug#4550: 23.1; give users a choice for quitting backtrace buffer

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Drew Adams]

emacs -Q
 
This change in debug.el is not good:
 
Revision 1.107 - (view) (download) (annotate) - [select for diffs] 
Fri Apr 18 01:29:23 2008 UTC (17 months, 1 week ago) by monnier 
Branch: MAIN 
CVS Tags: font-backend-base 
Branch point for: font-backend 
Changes since 1.106: +4 -3 lines 
Diff to previous 1.106 
(debug): Revert to bury-buffer since quit-window is not better anyway.
 
In my case, this change means that the debugger frame is iconified
each time, and this includes some times when the debugger is still
active, which makes it impossible to access/use. (*)
 
The point is that `bury-buffer' is unacceptable for my use - it is
practically impossible for me to use the debugger in Emacs 23.  I can
live with no action at all (which keeps the *Backtrace* frame around)
or with `quit-window' in place of `bury-buffer'. I cannot live with
`bury-buffer'.  So I redefine `debug', just to change that one silly
function call.
 
The solution is to call a function that is the value of a user option:
`debugger-quit-function'. I don't care what the default value is -
make it `bury-buffer' if you want.
 
The user option's value should have :type `function' or, better, a
`choice' between nil and `function', where nil would mean do nothing.
If the :type is just `function' a user can of course use function
`ignore' to do nothing, but that is not so obvious for some users, so
in that case, please call that out in the doc string.
 
The code would then do this, in place of calling (bury-buffer):
 
;; If the option can have value nil:
(when debugger-quit-function
  (funcall debugger-quit-function))
 
;; If the option value can only be a function:
(funcall debugger-quit-function)
 
I would then customize the option to `quit-window' (or nil or
`ignore').
 

---
(*) No, I'm not going to try to figure out what's happening in those
cases where it is iconified when still active; it's hard enough using
the debugger when broken like this, without trying to debug the
debugger.  In case it helps, I will say however that I don't remember
seeing that when `bury-buffer' was used briefly during Emacs 22
development - back then it was iconified only when empty (finished),
IIRC.
 

In GNU Emacs 23.1.1 (i386-mingw-nt5.1.2600)
 of 2009-07-29 on SOFT-MJASON
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (4.4)'
 

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> In my case, this change means that the debugger frame is iconified
> each time, and this includes some times when the debugger is still
> active, which makes it impossible to access/use. (*)
>
> The point is that `bury-buffer' is unacceptable for my use - it is
> practically impossible for me to use the debugger in Emacs 23.  I can
> live with no action at all (which keeps the *Backtrace* frame around)
> or with `quit-window' in place of `bury-buffer'. I cannot live with
> `bury-buffer'.  So I redefine `debug', just to change that one silly
> function call.

That sounds annoying.  Do you have a recipe for how to reproduce this
bug?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Drew Adams]

> That sounds annoying.  Do you have a recipe for how to reproduce this
> bug?

We've been through it all before.
Stefan understands the problem.

I provided a clean, simple solution: Add a user option that defines the
behavior.  Make the default value of the option be whatever you want, including
`bury-buffer' (which causes the annoyance for me).

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

> We've been through it all before.
> Stefan understands the problem.
>
> I provided a clean, simple solution: Add a user option that defines the
> behavior.  Make the default value of the option be whatever you want, including
> `bury-buffer' (which causes the annoyance for me).

`q' is bound to `top-level' if I say `(debug)'.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Drew Adams]

> `q' is bound to `top-level' if I say `(debug)'.

So what? It was in Emacs 22 also (and Emacs 21 and 20...).
The behavior is not the same.

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Lars Magne Ingebrigtsen]

"Drew Adams" <drew.adams@oracle.com> writes:

>> `q' is bound to `top-level' if I say `(debug)'.
>
> So what? It was in Emacs 22 also (and Emacs 21 and 20...).
> The behavior is not the same.

It means that I'm unable to reproduce the behaviour you're describing.
If you're still not willing to give a recipe for reproducing this error,
I have no other choice than to close it.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Drew Adams]

> >> `q' is bound to `top-level' if I say `(debug)'.
> >
> > So what? It was in Emacs 22 also (and Emacs 21 and 20...).
> > The behavior is not the same.
> 
> It means that I'm unable to reproduce the behaviour you're describing.
> If you're still not willing to give a recipe for reproducing 
> this error, I have no other choice than to close it.

1. Download these two files and put them in your load-path:
http://www.emacswiki.org/emacs/download/hexrgb.el
http://www.emacswiki.org/emacs/download/oneonone.el

2. Start Emacs:

runemacs.exe -Q --debug-init -l "hexrgb.el" -l "oneonone.el" -f "1on1-emacs"

3. Make *Backtrace* be a special-display buffer:

M-: (setq special-display-regexps '("[ ]?[*][^*]+[*]"))

4: Enter the debugger for `describe-mode':

M-x debug-on-entry RET describe-mode RET

C-h m

5: You are now in the debugger.  Hit `q' to exit.
The *Backtrace* frame gets iconified.

I want the frame to either remain or be deleted, not iconified.
I want users to be able to specify the behavior they prefer.

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Stefan Monnier]

> I want the frame to either remain or be deleted, not iconified.
> I want users to be able to specify the behavior they prefer.

Why don't you provide a patch for bury-buffer that adds the needed hook?
That would be easier than repeating your desire for such a feature.


        Stefan

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[martin rudalics]

 > I want the frame to either remain or be deleted, not iconified.
 > I want users to be able to specify the behavior they prefer.

We can add a buffer display specifier which tells a priori what to do
with the window/frame/buffer when the window is no more needed.  For
that I'd need a list of specification concepts for

- what to do with the window (delete it or keep it),

- what to do with the frame (iconfiy, delete, keep it, make it
   invisible),

- what to do with the buffer (kill it, bury it),

with an optional function that could be called for each of these.

If a consensus can be reached, this could be easily done.  The calling
application would propose the default behavior via an argument and the
user could override it.

martin

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Štěpán Němec]

martin rudalics <rudalics@gmx.at> writes:

>> I want the frame to either remain or be deleted, not iconified.
>> I want users to be able to specify the behavior they prefer.
>
> We can add a buffer display specifier which tells a priori what to do
> with the window/frame/buffer when the window is no more needed.  For
> that I'd need a list of specification concepts for
>
> - what to do with the window (delete it or keep it),
>
> - what to do with the frame (iconfiy, delete, keep it, make it
>   invisible),
>
> - what to do with the buffer (kill it, bury it),
>
> with an optional function that could be called for each of these.
>
> If a consensus can be reached, this could be easily done.  The calling
> application would propose the default behavior via an argument and the
> user could override it.

I think this would be great (with the options you listed). IMO the
possibility to customize the window quit/"undisplay" action is as
important as with the display action. I assume this customization would
be respected by `quit-window'?

  Štěpán

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[martin rudalics]

 > I assume this customization would
 > be respected by `quit-window'?

Conceptually, it would be respected by `switch-to-prev-buffer',
`replace-buffer-in-windows' and `quit-restore-window' (the buffer
killing aspect would be probably only handled by the latter).  IIUC
`quit-window' has a long history of its own and I'm not sure whether
people would like it to change behavior.

But the desired behavior would be stored in the `quit-restore' window
parameter, so any function could use that.  The default behavior would
be the one used by `quit-restore-window' now.

martin

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Štěpán Němec]

On Sun, Jul 17, 2011 at 02:06:39PM +0200, martin rudalics wrote:
> > I assume this customization would
> > be respected by `quit-window'?
> 
> Conceptually, it would be respected by `switch-to-prev-buffer',
> `replace-buffer-in-windows' and `quit-restore-window' (the buffer
> killing aspect would be probably only handled by the latter).  IIUC
> `quit-window' has a long history of its own and I'm not sure whether
> people would like it to change behavior.

Yeah, but AIUI one of the points of the recent buffer display reform is
to provide a unified customization interface, so I think it would be a
shame to still leave cases which the user has to handle outside of it
(which in this case would be particularly ugly, as `quit-window' doesn't
seem to provide any means to hook into what it does other than the
prefix argument).

Perhaps `quit-window' could check if a relevant specification exists,
and default to the current behaviour if none is found?

  Štěpán

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[martin rudalics]

 > Yeah, but AIUI one of the points of the recent buffer display reform is
 > to provide a unified customization interface, so I think it would be a
 > shame to still leave cases which the user has to handle outside of it
 > (which in this case would be particularly ugly, as `quit-window' doesn't
 > seem to provide any means to hook into what it does other than the
 > prefix argument).

The "buffer display reform" doesn't cover the case where a window is
obtained "manually", for example, by C-x 2.  `quit-restore-window' does
hanlde that and `quit-window' too, both in their own ways.

 > Perhaps `quit-window' could check if a relevant specification exists,
 > and default to the current behaviour if none is found?

Perhaps.  `bury-buffer' is another function that could do that.  I once
thought of making `quit-restore-window' the only function to "quit" a
window but meanwhile I had to recognize that people have developed very
strict conceptions about how a window shall be quit.

martin

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Stefan Monnier]

>> I want the frame to either remain or be deleted, not iconified.
>> I want users to be able to specify the behavior they prefer.

> We can add a buffer display specifier which tells a priori what to do
> with the window/frame/buffer when the window is no more needed.  For
> that I'd need a list of specification concepts for

> - what to do with the window (delete it or keep it),

> - what to do with the frame (iconfiy, delete, keep it, make it
>   invisible),

> - what to do with the buffer (kill it, bury it),

> with an optional function that could be called for each of these.

Sounds way overkill to me.
All Drew needs AFAIK is a bury-buffer-function that lets him change the
iconify-frame default to something else.


        Stefan

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[martin rudalics]

 > (debug): Revert to bury-buffer since quit-window is not better anyway.
 >
 > In my case, this change means that the debugger frame is iconified
 > each time, and this includes some times when the debugger is still
 > active, which makes it impossible to access/use. (*)

Is this still an issue?

martin

bug#4550: 23.1; give users a choice for quitting backtrace buffer

[Drew Adams]

>  > (debug): Revert to bury-buffer since quit-window is not 
>  > better anyway.
>  >
>  > In my case, this change means that the debugger frame is iconified
>  > each time, and this includes some times when the debugger is still
>  > active, which makes it impossible to access/use. (*)
> 
> Is this still an issue?

No, I believe so it is fixed now.  Thx.  I will close it.