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

[Steven Degutis <sbdegutis@gmail.com>]

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

Hmm, it seems that using overlays could allow the dimming to be per-window
instead of per-buffer.

But overlays have a few quirks.

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

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.

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. I don't know if I'm qualified for this task, especially since I
barely know elisp.

-Steven


On Wed, Apr 3, 2013 at 10:32 AM, Steven Degutis <sbdegutis@gmail.com> wrote:

> Actually since overlays can be per-window, it might actually make dimming
> other *windows* work, which was the original goal, rather than other
> *buffers*.
>
> So using window-specific overlays may be worth a try. If I can ever figure
> out how to use them.
>
> -Steven
>
>
> On Wed, Apr 3, 2013 at 10:15 AM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Steven Degutis <sbdegutis@gmail.com> writes:
>>
>> > It's now called `auto-dim-other-buffers` and it just got a whole lot
>> more
>> > efficient and faster:
>> https://github.com/sdegutis/auto-dim-other-buffers.el
>>
>> I see that you introduced some intelligence for operating only on/when
>> the buffers affected by the change. Maybe it is worth to try the overlay
>> approach. I bet that it will be efficient enough.
>>
>> What I'm concerned about is the collision of the overlay that auto-dim
>> creates with the overlays that might pre-exist in the window. But the
>> current implementation already suffers a similar problem with faces, so
>> it can't be worse.
>>
>>
>>
>

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