From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steven Degutis Newsgroups: gmane.emacs.help Subject: Re: `auto-dim-other-windows` -- scrutiny invited Date: Thu, 4 Apr 2013 11:02:21 -0500 Message-ID: References: <87ehersl1c.fsf@wanadoo.es> <877gkjh6pk.fsf@web.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7b6d94a87d442004d98b1823 X-Trace: ger.gmane.org 1365091376 10135 80.91.229.3 (4 Apr 2013 16:02:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 4 Apr 2013 16:02:56 +0000 (UTC) To: "help-gnu-emacs@gnu.org" , =?ISO-8859-1?Q?=D3scar_Fuentes?= , michael_heerdegen@web.de Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Thu Apr 04 18:03:22 2013 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1UNmdD-0004tN-Ph for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Apr 2013 18:03:20 +0200 Original-Received: from localhost ([::1]:39812 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNmco-0007uk-SI for geh-help-gnu-emacs@m.gmane.org; Thu, 04 Apr 2013 12:02:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:46312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNmcQ-0007ir-N6 for help-gnu-emacs@gnu.org; Thu, 04 Apr 2013 12:02:38 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNmcI-0005BZ-Jp for help-gnu-emacs@gnu.org; Thu, 04 Apr 2013 12:02:30 -0400 Original-Received: from mail-da0-x231.google.com ([2607:f8b0:400e:c00::231]:61531) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNmcI-0005BM-A3 for help-gnu-emacs@gnu.org; Thu, 04 Apr 2013 12:02:22 -0400 Original-Received: by mail-da0-f49.google.com with SMTP id t11so1192538daj.36 for ; Thu, 04 Apr 2013 09:02:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=b5AxpZf5bEVDYqCFVclOioHVG3DZ6PARaRfUGzxzTj8=; b=a4NmQ29Wv+vyl1+Lo0IX3hZvohn24Kj12xoymSnmH+hQlenolCwNCr+JH+B8MdreA9 jGw2PlBjkuDjE0HpIVALt5//JsbPJVb3KTTkMf9aUWsWwF39avdDPsdEOR8BiDTh3ZMm 0yT2NmoluR9VcOOADi06po27ytAUYxAJcPLtkaEDc8A4dxjaL8M4yGnmhNXCl6YbE+t5 h8gDXtN51M7M5rTte8IcMU9+HA8hXgSHBKbmWFL7CXnq6JA9f1xV1Dq8+ZayZY8L+GQ8 jmeEu4AS3cPAcTRA4PRFqRgabVS+97yVInDE0eMY+87RUICS0eTKoOKxv2EofBQx6aLc 7ZAg== X-Received: by 10.68.170.193 with SMTP id ao1mr9289654pbc.129.1365091341385; Thu, 04 Apr 2013 09:02:21 -0700 (PDT) Original-Received: by 10.70.6.100 with HTTP; Thu, 4 Apr 2013 09:02:21 -0700 (PDT) In-Reply-To: <877gkjh6pk.fsf@web.de> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2607:f8b0:400e:c00::231 X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Original-Sender: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.help:89990 Archived-At: --047d7b6d94a87d442004d98b1823 Content-Type: text/plain; charset=ISO-8859-1 There's a fundamental problem with using overlays. Because they're applied on a per-range basis, if you want the overlay face to just have a different background, only the text in the buffer is affected, not the rest of the buffer. So if you have a buffer with just 1 line, only that one line of text will have your "dimmed" background color, the rest of the empty buffer would show the default background color. -Steven On Wed, Apr 3, 2013 at 12:20 PM, Michael Heerdegen wrote: > Steven Degutis 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. > > --047d7b6d94a87d442004d98b1823 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There's a fundamental problem with using overlays.
Because they're applied on a per-range basis, if you wa= nt the overlay face to just have a different background, only the text in t= he buffer is affected, not the rest of the buffer. So if you have a buffer = with just 1 line, only that one line of text will have your "dimmed&qu= ot; background color, the rest of the empty buffer would show the default b= ackground color.

-Steven

On Wed, Apr 3, 2013 at 12:20 PM, Michael H= eerdegen <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. =A0BTW, efficiency is not among them in our case. =A0If you had<= br> 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 differen= t
> 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<= br> > an extra overlay in it.
>
> Second, while they do have a 'window' property that allows the= m 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. =A0It 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<= br> > you remove it from the current buffer, you could have the same buffer<= br> > 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. =A0This implies t= hat
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<= br> > 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" th= e default
> face with the one you want to be considered "dimmed", and gi= ve 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.


--047d7b6d94a87d442004d98b1823--