* bug#12708: 24.1; M-x display-time-world "q" close window
@ 2012-10-22 20:44 Kevin Ryde
2012-10-23 6:33 ` martin rudalics
0 siblings, 1 reply; 12+ messages in thread
From: Kevin Ryde @ 2012-10-22 20:44 UTC (permalink / raw)
To: 12708
Severity: wishlist
In an M-x display-time-world, it'd be good if the "q" key closed the
window (as well as killing the buffer).
The window is a small extra opened at the bottom of the screen by the
command. If it's still that size then it's not much use for anything
else.
M-x calendar has its "q" close the small window it opens. I'm suspect
it's not possible to share code, as the calendar bit looks like it does
other things too.
In GNU Emacs 24.1.1 (i486-pc-linux-gnu, GTK+ Version 2.24.8)
of 2012-08-07 on blah.blah, modified by Debian
Configured using:
`configure '--build' 'i486-linux-gnu' '--build' 'i486-linux-gnu'
'--prefix=/usr' '--sharedstatedir=/var/lib' '--libexecdir=/usr/lib'
'--localstatedir=/var/lib' '--infodir=/usr/share/info'
'--mandir=/usr/share/man' '--with-pop=yes'
'--enable-locallisppath=/etc/emacs24:/etc/emacs:/usr/local/share/emacs/24.1/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.1/site-lisp:/usr/share/emacs/site-lisp'
'--with-crt-dir=/usr/lib/i386-linux-gnu' '--with-x=yes'
'--with-x-toolkit=gtk' '--with-toolkit-scroll-bars'
'build_alias=i486-linux-gnu' 'CFLAGS=-g -O2 -fstack-protector
--param=ssp-buffer-size=4 -Wformat -Werror=format-security -Wall'
'CPPFLAGS=-D_FORTIFY_SOURCE=2''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: nil
value of $LC_CTYPE: nil
value of $LC_MESSAGES: nil
value of $LC_MONETARY: nil
value of $LC_NUMERIC: nil
value of $LC_TIME: nil
value of $LANG: en_AU
value of $XMODIFIERS: nil
locale-coding-system: iso-latin-1-unix
default enable-multibyte-characters: t
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-22 20:44 bug#12708: 24.1; M-x display-time-world "q" close window Kevin Ryde
@ 2012-10-23 6:33 ` martin rudalics
2012-10-24 7:44 ` Juri Linkov
2012-10-24 14:53 ` Chong Yidong
0 siblings, 2 replies; 12+ messages in thread
From: martin rudalics @ 2012-10-23 6:33 UTC (permalink / raw)
To: Kevin Ryde; +Cc: 12708
> In an M-x display-time-world, it'd be good if the "q" key closed the
> window (as well as killing the buffer).
>
> The window is a small extra opened at the bottom of the screen by the
> command. If it's still that size then it's not much use for anything
> else.
>
> M-x calendar has its "q" close the small window it opens. I'm suspect
> it's not possible to share code, as the calendar bit looks like it does
> other things too.
We could do
(defun quit-window-kill-buffer (&optional window)
"Quit WINDOW and kill its buffer.
WINDOW must be a live window and defaults to the selected one."
(interactive)
(quit-restore-window window 'kill))
(defvar display-time-world-mode-map
(let ((map (make-sparse-keymap)))
(define-key map "q" 'quit-window-kill-buffer)
map)
"Keymap of Display Time World mode.")
But `display-time-world' should probably also use `display-buffer'
instead of `pop-to-buffer' and put the buffer in `view-mode'. After
all, who wants to edit or navigate the *wclock* buffer?
martin
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-23 6:33 ` martin rudalics
@ 2012-10-24 7:44 ` Juri Linkov
2012-10-27 11:04 ` martin rudalics
2012-10-24 14:53 ` Chong Yidong
1 sibling, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-10-24 7:44 UTC (permalink / raw)
To: martin rudalics; +Cc: 12708, Kevin Ryde
> We could do
>
> (defun quit-window-kill-buffer (&optional window)
> "Quit WINDOW and kill its buffer.
> WINDOW must be a live window and defaults to the selected one."
> (interactive)
> (quit-restore-window window 'kill))
>
> (defvar display-time-world-mode-map
> (let ((map (make-sparse-keymap)))
> (define-key map "q" 'quit-window-kill-buffer)
> map)
> "Keymap of Display Time World mode.")
BTW, when I needed to do the same for the *Occur* buffer
(to kill it after going to the occurrence) I created a new command
`occur-mode-goto-occurrence-kill-buffer' based on
`occur-mode-goto-occurrence-other-window':
(defun occur-mode-goto-occurrence-kill-buffer ()
"Go to the occurrence the current line describes, and kill the Occur buffer."
(interactive)
(let ((buf (current-buffer))
(pos (occur-mode-find-occurrence)))
(switch-to-buffer-other-window (marker-buffer pos))
(goto-char pos)
(kill-buffer buf)
(run-hooks 'occur-mode-find-occurrence-hook)))
I still have no idea how to generalize this common behavior.
> But `display-time-world' should probably also use `display-buffer'
> instead of `pop-to-buffer' and put the buffer in `view-mode'. After
> all, who wants to edit or navigate the *wclock* buffer?
In addition to this, it could also use the action
`display-buffer-below-selected' (like in dired),
and instead of `fit-window-to-buffer' it could use
'((window-height . fit-window-to-buffer)).
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-24 7:44 ` Juri Linkov
@ 2012-10-27 11:04 ` martin rudalics
2012-10-27 11:45 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: martin rudalics @ 2012-10-27 11:04 UTC (permalink / raw)
To: Juri Linkov; +Cc: 12708
> BTW, when I needed to do the same for the *Occur* buffer
> (to kill it after going to the occurrence) I created a new command
> `occur-mode-goto-occurrence-kill-buffer' based on
> `occur-mode-goto-occurrence-other-window':
>
> (defun occur-mode-goto-occurrence-kill-buffer ()
> "Go to the occurrence the current line describes, and kill the Occur buffer."
> (interactive)
> (let ((buf (current-buffer))
> (pos (occur-mode-find-occurrence)))
> (switch-to-buffer-other-window (marker-buffer pos))
> (goto-char pos)
> (kill-buffer buf)
> (run-hooks 'occur-mode-find-occurrence-hook)))
>
> I still have no idea how to generalize this common behavior.
Why don't you quit the *Occur* buffer window first and do a simple
`pop-to-buffer' afterwards? In any case I think that the "kill the
*Occur* buffer" effect should be achieved with some sort of prefix.
BTW, I find bindings like
(define-key map "\C-c\C-c" 'occur-mode-goto-occurrence)
(define-key map "\C-m" 'occur-mode-goto-occurrence)
(define-key map "o" 'occur-mode-goto-occurrence-other-window)
very confusing.
> In addition to this, it could also use the action
> `display-buffer-below-selected' (like in dired),
I think `display-buffer-at-bottom' would suit better. But this needs
some way to say bottom-left, bottom-center, bottom-right. I'm not yet
sure how to do that best.
> and instead of `fit-window-to-buffer' it could use
> '((window-height . fit-window-to-buffer)).
I installed that now.
martin
^ permalink raw reply [flat|nested] 12+ messages in thread* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-27 11:04 ` martin rudalics
@ 2012-10-27 11:45 ` Juri Linkov
2012-10-27 13:45 ` martin rudalics
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-10-27 11:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 12708
>> (defun occur-mode-goto-occurrence-kill-buffer ()
>> "Go to the occurrence the current line describes, and kill the Occur buffer."
>> (interactive)
>> (let ((buf (current-buffer))
>> (pos (occur-mode-find-occurrence)))
>> (switch-to-buffer-other-window (marker-buffer pos))
>> (goto-char pos)
>> (kill-buffer buf)
>> (run-hooks 'occur-mode-find-occurrence-hook)))
>
> Why don't you quit the *Occur* buffer window first and do a simple
> `pop-to-buffer' afterwards?
I tried it to be closer to the workflow of
`occur-mode-goto-occurrence-other-window'.
But your recipe would work as well.
> BTW, I find bindings like
>
> (define-key map "\C-c\C-c" 'occur-mode-goto-occurrence)
> (define-key map "\C-m" 'occur-mode-goto-occurrence)
> (define-key map "o" 'occur-mode-goto-occurrence-other-window)
>
> very confusing.
You might find it more confusing when I tell you that in ~/.emacs
I bound `occur-mode-goto-occurrence-kill-buffer' to C-RET ;-)
>> In addition to this, it could also use the action
>> `display-buffer-below-selected' (like in dired),
>
> I think `display-buffer-at-bottom' would suit better. But this needs
> some way to say bottom-left, bottom-center, bottom-right. I'm not yet
> sure how to do that best.
Shouldn't `display-buffer-at-bottom' create a window with the width of
the frame's full width? In this case, left/center/right are not needed.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-27 11:45 ` Juri Linkov
@ 2012-10-27 13:45 ` martin rudalics
2012-10-27 15:02 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: martin rudalics @ 2012-10-27 13:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: 12708
>>> (defun occur-mode-goto-occurrence-kill-buffer ()
>>> "Go to the occurrence the current line describes, and kill the Occur buffer."
>>> (interactive)
>>> (let ((buf (current-buffer))
>>> (pos (occur-mode-find-occurrence)))
>>> (switch-to-buffer-other-window (marker-buffer pos))
>>> (goto-char pos)
>>> (kill-buffer buf)
>>> (run-hooks 'occur-mode-find-occurrence-hook)))
>> Why don't you quit the *Occur* buffer window first and do a simple
>> `pop-to-buffer' afterwards?
>
> I tried it to be closer to the workflow of
> `occur-mode-goto-occurrence-other-window'.
> But your recipe would work as well.
For <= two windows per frame users there's a difference: If the *Occur*
buffer appeared in a new window, the other window would be reused with
your approach. If we delete the *Occur* window first, the other window
would be split.
>> BTW, I find bindings like
>>
>> (define-key map "\C-c\C-c" 'occur-mode-goto-occurrence)
>> (define-key map "\C-m" 'occur-mode-goto-occurrence)
>> (define-key map "o" 'occur-mode-goto-occurrence-other-window)
>>
>> very confusing.
>
> You might find it more confusing when I tell you that in ~/.emacs
> I bound `occur-mode-goto-occurrence-kill-buffer' to C-RET ;-)
Not really. I use M-RET for going to the tag around `point'. It has
some kind of "come on, get there ..." connotation for me.
> Shouldn't `display-buffer-at-bottom' create a window with the width of
> the frame's full width? In this case, left/center/right are not needed.
I'm not sure. People with two side-by-side windows would probably like
to split-below their window on the right for calendar-like things that
take fairly few columns only. We need some framework for specifying
such behavior in a user-friendly way. Well, they could use side-windows
already ...
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-27 13:45 ` martin rudalics
@ 2012-10-27 15:02 ` Juri Linkov
2012-10-28 15:23 ` martin rudalics
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2012-10-27 15:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 12708
>> Shouldn't `display-buffer-at-bottom' create a window with the width of
>> the frame's full width? In this case, left/center/right are not needed.
>
> I'm not sure. People with two side-by-side windows would probably like
> to split-below their window on the right for calendar-like things that
> take fairly few columns only.
"Split-below on the right" is quite weird behavior as default.
Better would be "Split-below in the same column" (where column means
a vertical list of windows). With a column of two windows
this is the same as `display-buffer-below-selected' already does.
> We need some framework for specifying such behavior in a user-friendly
> way. Well, they could use side-windows already ...
In a user-friendly framework the user could just type a "print-screen" key
and it will convert the current window configuration info a structure
that can be used as a basis for further configuration.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-27 15:02 ` Juri Linkov
@ 2012-10-28 15:23 ` martin rudalics
2012-10-28 17:41 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: martin rudalics @ 2012-10-28 15:23 UTC (permalink / raw)
To: Juri Linkov; +Cc: 12708
>> I'm not sure. People with two side-by-side windows would probably like
>> to split-below their window on the right for calendar-like things that
>> take fairly few columns only.
>
> "Split-below on the right" is quite weird behavior as default.
> Better would be "Split-below in the same column" (where column means
> a vertical list of windows). With a column of two windows
> this is the same as `display-buffer-below-selected' already does.
Where would you put a calendar in a configuration like this:
-----------------
| | |
| | |
| | |
| | |
-----------------
Regardless of which window is selected, IMO the location would be
-----------------
| | |
| | |
| |--------|
| | here. |
-----------------
martin
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-28 15:23 ` martin rudalics
@ 2012-10-28 17:41 ` Juri Linkov
0 siblings, 0 replies; 12+ messages in thread
From: Juri Linkov @ 2012-10-28 17:41 UTC (permalink / raw)
To: martin rudalics; +Cc: 12708
> Where would you put a calendar in a configuration like this:
>
> -----------------
> | | |
> | | |
> | | |
> | | |
> -----------------
I think it should depend on which window is selected
like `display-buffer-below-selected' does:
-----------------
| |selected|
| | |
| |--------|
| | here. |
-----------------
-----------------
|selected| |
| | |
|--------| |
| here. | |
-----------------
The reasoning being that the result should look the same
as in a narrow 1-window frame:
----------
|selected|
| |
|--------|
| here. |
----------
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-23 6:33 ` martin rudalics
2012-10-24 7:44 ` Juri Linkov
@ 2012-10-24 14:53 ` Chong Yidong
2012-10-24 16:25 ` Glenn Morris
1 sibling, 1 reply; 12+ messages in thread
From: Chong Yidong @ 2012-10-24 14:53 UTC (permalink / raw)
To: martin rudalics; +Cc: 12708, Kevin Ryde
martin rudalics <rudalics@gmx.at> writes:
> But `display-time-world' should probably also use `display-buffer'
> instead of `pop-to-buffer' and put the buffer in `view-mode'. After
> all, who wants to edit or navigate the *wclock* buffer?
Yes, display-time-world is clearly behind the times, and the use of
pop-to-buffer is a mistake. I changed display-time-world-mode to derive
from special mode, and display-time-world to use display-buffer.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#12708: 24.1; M-x display-time-world "q" close window
2012-10-24 14:53 ` Chong Yidong
@ 2012-10-24 16:25 ` Glenn Morris
2012-10-24 18:27 ` Chong Yidong
0 siblings, 1 reply; 12+ messages in thread
From: Glenn Morris @ 2012-10-24 16:25 UTC (permalink / raw)
To: Chong Yidong; +Cc: 12708, Kevin Ryde
Chong Yidong wrote:
> Yes, display-time-world is clearly behind the times, and the use of
> pop-to-buffer is a mistake. I changed display-time-world-mode to derive
> from special mode, and display-time-world to use display-buffer.
emacs -Q -f display-time-world
q ; in world time buffer
M-x display-time-world
-> Buffer is read-only: #<buffer *wclock*>
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-10-28 17:41 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-10-22 20:44 bug#12708: 24.1; M-x display-time-world "q" close window Kevin Ryde
2012-10-23 6:33 ` martin rudalics
2012-10-24 7:44 ` Juri Linkov
2012-10-27 11:04 ` martin rudalics
2012-10-27 11:45 ` Juri Linkov
2012-10-27 13:45 ` martin rudalics
2012-10-27 15:02 ` Juri Linkov
2012-10-28 15:23 ` martin rudalics
2012-10-28 17:41 ` Juri Linkov
2012-10-24 14:53 ` Chong Yidong
2012-10-24 16:25 ` Glenn Morris
2012-10-24 18:27 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).