all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Michael Heerdegen <michael_heerdegen@web.de>
To: help-gnu-emacs@gnu.org
Cc: "Óscar Fuentes" <ofv@wanadoo.es>, help-gnu-emacs@gnu.org
Subject: Re: `auto-dim-other-windows` -- scrutiny invited
Date: Wed, 03 Apr 2013 19:20:07 +0200	[thread overview]
Message-ID: <877gkjh6pk.fsf@web.de> (raw)
In-Reply-To: <mailman.23406.1365005023.855.help-gnu-emacs@gnu.org> (Steven Degutis's message of "Wed, 3 Apr 2013 11:03:28 -0500")

Steven Degutis <sbdegutis@gmail.com> writes:

> Hmm, it seems that using overlays could allow the dimming to be
> per-window instead of per-buffer.
>
> But overlays have a few quirks.

Yes.  BTW, efficiency is not among them in our case.  If you had
hundreds or thousands of overlays in a buffer (e.g. one in every single
line in a very large buffer), it is another thing.

> First, they're still per-buffer. You can copy them around different
> buffers, but each buffer has to have its own. So if we were going to
> use them to dim other windows, every buffer would have to always have
> an extra overlay in it.
>
> Second, while they do have a 'window' property that allows them to be
> visible only when the buffer is in a given window, this is the
> inverse of what we want. We would want them to be visible only when
> the buffer is *not* in (selected-window).

Right.  It would complicate the code, no doubt.

> There's a few ways these could be worked around.
>
> We could add overlays to every buffer, and whenever you change
> windows, remove the overlay from the current buffer and add it back
> to the previous buffer. But this is identical to what
> `auto-dim-other-buffers` already does now, only harder to write. When
> you remove it from the current buffer, you could have the same buffer
> open in multiple windows, and in all of them it's gone.

That's not exactly what I had in mind.

For every not-selected window w_n, the displayed buffer b_n would get an
overlay with the `window' overlay property being w_n.  This implies that
buffers can get more than one overlay (if visible in multiple windows).
In the selected window, those overlays are not visible, because it is
different from all windows specified in any `window' properties.

So, this approach would work, but OTOH, some users also may like the
current behavior.

> Or, we could have it reversed. We could only have an overlay on the
> current buffer at any given time, and give it the window of
> (selected-window), and keep updating these any time you change
> buffers or windows. This would successfully "differentiate" the
> current window from every other window and allow you to style it
> differently. But it has the problem of being the exact inverse of the
> original goal, which is to dim other windows. It would be more like
> `auto-prominentize-current-window`.
>
> The problem would then be that you now need to make the current
> buffer look different than the default face. But by definition, the
> default face is *exactly* what you want to be editing in.
>
> So one hacky way to solve this is to somehow "switch out" the default
> face with the one you want to be considered "dimmed", and give the
> current-window-overlay the face that was originally your "default
> face".
>
> This seems like it *could* work, but it's terrifying. Absolutely
> terrifying.

Right.

Apropos echo area: Note that the minibuffer-window is also a visible
window - the window where the echo area or the minibuffer, respectively,
is displayed.


HTH,

Michael.



  parent reply	other threads:[~2013-04-03 17:20 UTC|newest]

Thread overview: 43+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-02 21:06 `auto-dim-other-windows` -- scrutiny invited Steven Degutis
2013-04-02 22:19 ` Óscar Fuentes
2013-04-02 22:48   ` Steven Degutis
2013-04-02 23:14     ` Óscar Fuentes
2013-04-02 23:19       ` Steven Degutis
     [not found]       ` <mailman.23338.1364944796.855.help-gnu-emacs@gnu.org>
2013-04-03 13:03         ` Michael Heerdegen
2013-04-03 13:27           ` Steven Degutis
     [not found] ` <mailman.23335.1364941179.855.help-gnu-emacs@gnu.org>
2013-04-03 13:11   ` Michael Heerdegen
2013-04-03 13:19     ` Steven Degutis
2013-04-03 14:44 ` Steven Degutis
2013-04-03 14:47   ` Mark Skilbeck
2013-04-03 14:52     ` Steven Degutis
2013-04-03 14:55       ` Mark Skilbeck
2013-04-03 15:09         ` Steven Degutis
2013-04-03 15:17           ` Óscar Fuentes
2013-04-03 15:15   ` Óscar Fuentes
2013-04-03 15:32     ` Steven Degutis
2013-04-03 16:03       ` Steven Degutis
2013-04-03 17:03         ` Óscar Fuentes
2013-04-03 17:13           ` Steven Degutis
2013-04-03 17:17             ` Óscar Fuentes
2013-04-03 17:42               ` Steven Degutis
2013-04-03 18:10                 ` Óscar Fuentes
2013-04-03 18:54                   ` Steven Degutis
2013-04-03 19:19                     ` Steven Degutis
2013-04-03 20:13         ` Stefan Monnier
2013-04-03 20:22           ` Steven Degutis
2013-04-03 22:23             ` Stefan Monnier
2013-04-04 21:55               ` Drew Adams
2013-04-04 22:01                 ` Steven Degutis
2013-04-05 12:49                   ` Stefan Monnier
2013-04-06 19:23                     ` Drew Adams
     [not found]       ` <mailman.23406.1365005023.855.help-gnu-emacs@gnu.org>
2013-04-03 17:20         ` Michael Heerdegen [this message]
2013-04-03 17:44           ` Steven Degutis
2013-04-03 20:55           ` Steven Degutis
2013-04-04 16:02           ` Steven Degutis
2013-04-04  7:27         ` Joost Kremers
2013-04-04 20:52           ` Ludwig, Mark
2013-04-04 20:53             ` Steven Degutis
2013-04-04 21:31               ` Steven Degutis
2013-04-03 15:57   ` Ludwig, Mark
2013-04-03 16:06     ` Steven Degutis
2013-04-03 16:37     ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=877gkjh6pk.fsf@web.de \
    --to=michael_heerdegen@web.de \
    --cc=help-gnu-emacs@gnu.org \
    --cc=ofv@wanadoo.es \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.