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 12:13:24 -0500 Message-ID: References: <87ehersl1c.fsf@wanadoo.es> <87r4irr1gp.fsf@wanadoo.es> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=047d7bf0c1b8c59beb04d977f806 X-Trace: ger.gmane.org 1365009238 30282 80.91.229.3 (3 Apr 2013 17:13:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 3 Apr 2013 17:13:58 +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 19:14:26 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 1UNRGT-00032V-3o for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 19:14:25 +0200 Original-Received: from localhost ([::1]:52038 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNRG4-0006tj-5N for geh-help-gnu-emacs@m.gmane.org; Wed, 03 Apr 2013 13:14:00 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:42505) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNRFi-0006sv-8t for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 13:13:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UNRFW-0000SV-I3 for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 13:13:38 -0400 Original-Received: from mail-pa0-f50.google.com ([209.85.220.50]:47890) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UNRFW-0000Rt-5G for help-gnu-emacs@gnu.org; Wed, 03 Apr 2013 13:13:26 -0400 Original-Received: by mail-pa0-f50.google.com with SMTP id bg2so997644pad.23 for ; Wed, 03 Apr 2013 10:13:25 -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=9Ssn8Ldba28o5ByFoasg6iRoN0PzJ8a32eIP0i2yqzo=; b=yCo2MU7CGT8pXxCFlXq3WnKm5s6TCxcRwSyNcjNFKY/sOkyqf5B0krGb8Xmcgt/YQq /J0d5h3oPZ8FnZoYH9L/JCoB8Tbp7nXE46QwhZbLjtQdldQsDM1NsbNrqySd+ceskIi3 jdWzgXwxB4lMCWFS6VRt9JlnxNM4/4abEX2DX1I7dVA7Je+r72FLxvdoQjtrM0wOLFKY OMGynt0UkURpaM8BbgKoXg6AP67SQYZmfGijxIM+iUMnpq1ADTYYkskaqbkH4C+wJ4Rg TXZEKtlTb5imAEHQNJrYRuRBOsmD7aFJmL4Vm9cn9FGVRqIBx2pJesdW9BOayZoeNHST 3qog== X-Received: by 10.66.117.196 with SMTP id kg4mr4379180pab.95.1365009204875; Wed, 03 Apr 2013 10:13:24 -0700 (PDT) Original-Received: by 10.70.6.100 with HTTP; Wed, 3 Apr 2013 10:13:24 -0700 (PDT) In-Reply-To: <87r4irr1gp.fsf@wanadoo.es> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.220.50 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:89953 Archived-At: --047d7bf0c1b8c59beb04d977f806 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Can minor modes be enabled/disabled on a per-window basis? If not, I think this doesn't solve the problem. -Steven On Wed, Apr 3, 2013 at 12:03 PM, =D3scar Fuentes wrote: > Steven Degutis 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. > > > --047d7bf0c1b8c59beb04d977f806 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Can minor modes be enabled/disabled on a per-window basis?= If not, I think this doesn't solve the problem.

-Steven


On Wed, Apr 3, 2013 at 12:03 PM, =D3scar Fuentes <ofv@wanadoo.es> wrote:
Steven Degutis <sbdegutis@gmail.com> writes:

> Or, we could have it reversed. We could only have an overlay on the cu= rrent
> 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 o= ther 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 i= s
> *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 give th= e
> 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, espec= ially since I
> barely know elisp.

This is the task of a global minor mode. As you probably know, minor<= br> 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.



--047d7bf0c1b8c59beb04d977f806--