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: Wed, 3 Apr 2013 11:03:28 -0500 Message-ID: References: <87ehersl1c.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec52e5b73a191b104d976fe3f X-Trace: ger.gmane.org 1365005032 14159 80.91.229.3 (3 Apr 2013 16:03:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Apr 2013 16:03:52 +0000 (UTC) Cc: help-gnu-emacs@gnu.org To: =?ISO-8859-1?Q?=D3scar_Fuentes?= Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane.org@gnu.org Wed Apr 03 18:04:19 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 1UNQAd-0004eG-LV for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 18:04:19 +0200 Original-Received: from localhost ([::1]:41441 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNQAE-0003Kl-US for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 12:03:54 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:51882) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNQ9w-0003Jm-4X for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:03:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNQ9p-00088c-DO for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:03:36 -0400 Original-Received: from mail-pa0-f54.google.com ([209.85.220.54]:51285) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNQ9p-00088S-3w for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 12:03:29 -0400 Original-Received: by mail-pa0-f54.google.com with SMTP id fa11so966341pad.27 for ; Wed, 03 Apr 2013 09:03:28 -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:cc:content-type; bh=lr6+cPenKwF4Avx9lxvfgP2jY9I2s976QHssKL2ZANg=; b=sBj7yzvMENlAOWBBaSNF84ynnEWnrIkzkxv8+LikLI5/kORQviGmIu5nrKHaTQL4OQ W0EJBFBlqXQagfZAblRQNbzSxMRwkVW1iorp6x7Br0TVOMvkPsLVrFl7l5LuXVJ/lRyH eeJJhIomwmHOY6RXxjI6kIa9RLtsInTiz291hunKA/Yl797wxYSDUy2E1rQFdH2vhrcx IsNvybPQavBFYU8nS+wOPZK/Q+7rPlijWN85ndQQnBznRjWJPRVzz02pSE8N54BKlORw BzTyZDTTQ9xWft0BXF1sRQEjtXJ+bjM+tFELdfAXYYBAUnIGOA7fvrcWV8VNq4Gu/PvM fOcQ== X-Received: by 10.68.64.136 with SMTP id o8mr3403350pbs.59.1365005008210; Wed, 03 Apr 2013 09:03:28 -0700 (PDT) Original-Received: by 10.70.6.100 with HTTP; Wed, 3 Apr 2013 09:03:28 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.54 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:89949 Archived-At: --bcaec52e5b73a191b104d976fe3f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 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 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 figur= e > out how to use them. > > -Steven > > > On Wed, Apr 3, 2013 at 10:15 AM, =D3scar Fuentes wrote: > >> Steven Degutis 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. >> >> >> > --bcaec52e5b73a191b104d976fe3f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hmm, it seems that using overlays could allow the dimming = to be per-window instead of per-buffer.

But overlays hav= e a few quirks.

First, they're still per-buffe= r. 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, t= his is the inverse of what we want. We would want them to be visible only w= hen the buffer is *not* in (selected-window).

There's a few ways these could be worked arou= nd.

We could add overlays to every= buffer, and whenever you change windows, remove the overlay from the curre= nt 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 onl= y 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 bu= ffers or windows. This would successfully "differentiate" the cur= rent 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, whi= ch is to dim other windows. It would be more like `auto-prominentize-curren= t-window`.

The problem would then be that you now need= to make the current buffer look different than the default face. But by de= finition, the default face is *exactly* what you want to be editing in.

So one hacky way to solve this is to someho= w "switch out" the default face with the one you want to be consi= dered "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, S= teven 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 c= an ever figure out how to use them.

-Steven


On Wed, Apr 3, 2013 at 10:15 AM, =D3scar 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 l= ot more
> efficient and faster: https://github.com/sdegutis/auto-dim-ot= her-buffers.el

I see that you introduced some intelligence for operating only on/whe= n
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<= br> 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.




--bcaec52e5b73a191b104d976fe3f--