Re: `auto-dim-other-windows` -- scrutiny invited

[Steven Degutis <sbdegutis@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3499 bytes --]

Hmm, this could work. I mean, it would have to be a separate project since
by definition it dims other windows, not other buffers.

But it sounds like it might be tricky and have some caveats I haven't quite
thought out yet.

-Steven


On Wed, Apr 3, 2013 at 12:20 PM, Michael Heerdegen <michael_heerdegen@web.de
> wrote:

> 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.
>
>

[-- Attachment #2: Type: text/html, Size: 4438 bytes --]