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

["Óscar Fuentes" <ofv@wanadoo.es>]

Steven Degutis <sbdegutis@gmail.com> writes:

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

This is the task of a global minor mode. As you probably know, minor
modes can be activated and deactivated at whim. On activation, the minor
mode stores the default background and changes it for the "dimmed" one.
Then applies an overlay to the buffer in the active window, assigning
the `window' property. When the user deactivates the minor mode, the
previous default background is recovered.

There are details like what happens if the user changes the default
background while the minor mode is activated and dealing with the fact
that the default background is per-frame.