[Top][All Lists]

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

Re: Quit and Close Emacs Special Windows

From: Ergus
Subject: Re: Quit and Close Emacs Special Windows
Date: Mon, 29 Jun 2020 19:22:47 +0200
User-agent: NeoMutt/20180716

On Mon, Jun 29, 2020 at 05:00:01PM +0000, Drew Adams wrote:

No idea; sorry.  I'm just saying what I do.

The definition of `quit-window-delete' that I use
has this comment:

;; Candidate as a replacement for `quit-window',
;; at least when used interactively.  For example:
;; (define-key global-map [remap quit-window] 'quit-window-delete)
;; Thanks to Martin Rudalics for suggestions.

Someone else will need to make changes to Emacs, if
such is decided.

The things I mentioned don't necessarily belong
together for others.  For me they make sense together.

For example, making buffers `*...*' special-display
is unrelated to quitting help buffers with `q'.

I tried your code for making buffers `*...*' special-display and as I
only use -nw the behavior is not good. The first time I call commands
like `man' nothing happens in the front but the buffer starts in the

In gui the behavior is fine as expected.

But for me it makes sense.  I show all such buffers
in their own dedicated window (frame, in fact), and
when I use `q' to quit the buffer I want to delete
the frame.  I imagine that at least some others won't
want such behavior.

Do I think that it would be good to have a simple way
to get `q' to delete the window?  Yes.  Do I think it
would be good to have a simple way for `q' to delete
a one-window frame?  Yes.  But someone else will need
to think about and decide whether that's helpful in
general and, if so, what's the best way to offer it.

I think that with a simple variable and an `or` in the condition will be
good enough (something like quit-always-kill or so).

The only corned case I can imagine so far is the case where quit-window
is not called from `q' in not *...* buffers. But I don't know if that
even happen.

Hopefully someone will come with a better solution...


reply via email to

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