emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

why isn't quitting Customize like quitting Info?


From: Drew Adams
Subject: why isn't quitting Customize like quitting Info?
Date: Fri, 21 Jan 2005 12:07:28 -0800

Summary - not really much of a bug, not really much of a feature request:
  1) `quit-window' should be used by, default, in Customize.
  2) Things could probably be simplified; I smell cruft.


Details -

1) I use `pop-up-frames' non-nil, and I have removed *Customiz.* from
`same-window-regexps', so customize buffers open in special-display-buffer
dedicated frames. Likewise, for Info.

In Info, I hit `q' and it exits - the Info frame disappears. In Customize, I
get an error "Cannot switch buffers in a dedicated buffer". (Okay, I can
deal with that...)

In Info, there is a simple key binding of `q' to `Info-exit', which is
essentially `quit-window. That function DTRT: `quit-window' seems _designed_
for this kind of thing, taking into account the window/frame context etc. I
suspect that it is appropriate for Customize too.

In Customize, `q' is bound to `Custom-buffer-done', which runs
`custom-buffer-done-function' on the current buffer. That is bound, by
default, to `custom-bury-buffer', which just does `bury-buffer' (in a
roundabout way).

You can of course choose a different function for
`custom-buffer-done-function'. The predefined choices for this variable
include `custom-bury-buffer' and `kill-buffer'. They do not include
`quit-window'.

I would think that `quit-window' would: a) be a predefined choice for
`custom-buffer-done-function', and in fact b) be the _default_ choice. It
already deals with both `bury-buffer' and `kill-buffer' in a DTRT way. It
works in my setup; `bury-buffer' does not.


2) I also wonder (I haven't followed all the code strands to the end, to
analyze this completely) if some of the layers of defining and binding the
customize quit function might just be overkill. I suppose that some of it is
because there is not just a single key binding (`q') - there are also button
and menu ways to quit (but Info has menu quit too). Nevertheless, I suspect
there may be something to be gained by using the Info code as inspiration
and trying to simplify the customize code a bit.

Here, for instance is a section of `custom-buffer-create-internal', which
creates the Customize buffers:

  (widget-create 'push-button
                 :tag "Finish"
                 :help-echo
                 (lambda (&rest ignore)
                   (cond
                    ((eq custom-buffer-done-function
                         'custom-bury-buffer)
                     "Bury this buffer")
                    ((eq custom-buffer-done-function 'kill-buffer)
                     "Kill this buffer")
                    (t "Finish with this buffer")))
                 :action #'Custom-buffer-done)

In spite of the trouble gone to in providing multiple layers of indirection
(`Custom-buffer-done', `custom-buffer-done-function', key bindings), this
_hard-codes_ tests to provide proper tooltip strings for each of the
predefined quit-function choices. That seems unnecessary and maintenance
unfriendly, to me. If we have indirection in order to decouple the function
from its bindings, then the tooltip should either just be generic or
(somehow) automatically use the doc string of the particular quit function
used. And the generic tooltip just repeats the :tag, so it is really
useless, IMO.

All of this unsimple code seems like a great todo about nothing, to me. What
in Info is just a command bound to a key is here a plate of spaghetti.
Instead of just binding a different quit command to the quit key (and
associated menu items etc.), a user gets the privilege of using all of the
Customize heavy machineray to bind the quit command. What's the advantage?

I admit - I don't get it. There are no doubt good reasons for all this
stuff - it was added after Emacs 20, for some reason. But I don't get it.

And even in Emacs 20, the quit command for Customize was `bury-buffer', so
the "bug" that it should probably be `quit-window' is not new.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]