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

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

[Steven Degutis]

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

    (defun auto-dim-other-windows ()
      (make-face 'sd/dimmed-font)
      (set-face-attribute 'sd/dimmed-font nil :background "black")

      (defun sd/prominantize-current-buffer (fn)
        (buffer-face-set 'sd/dimmed-font)
        (funcall fn)
        (buffer-face-set nil))

      (defmacro sd/advise-window-changing-fn (fn)
        `(defadvice ,fn (around window-changing-fn-advice activate)
           (sd/prominantize-current-buffer (lambda () ad-do-it))))

      (sd/advise-window-changing-fn other-window)
      (sd/advise-window-changing-fn other-frame)
      (sd/advise-window-changing-fn next-buffer)
      (sd/advise-window-changing-fn previous-buffer)
      (sd/advise-window-changing-fn quit-window)
      (sd/advise-window-changing-fn mouse-select-window))

-Steven

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

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

[Óscar Fuentes]

Steven Degutis <sbdegutis@gmail.com> writes:

>     (defun auto-dim-other-windows ()
>       (make-face 'sd/dimmed-font)
>       (set-face-attribute 'sd/dimmed-font nil :background "black")
>
>       (defun sd/prominantize-current-buffer (fn)
>         (buffer-face-set 'sd/dimmed-font)
>         (funcall fn)
>         (buffer-face-set nil))
>
>       (defmacro sd/advise-window-changing-fn (fn)
>         `(defadvice ,fn (around window-changing-fn-advice activate)
>            (sd/prominantize-current-buffer (lambda () ad-do-it))))
>
>       (sd/advise-window-changing-fn other-window)
>       (sd/advise-window-changing-fn other-frame)
>       (sd/advise-window-changing-fn next-buffer)
>       (sd/advise-window-changing-fn previous-buffer)
>       (sd/advise-window-changing-fn quit-window)
>       (sd/advise-window-changing-fn mouse-select-window))

Interesting idea.

Some observations (in case you already are interested on bugs &
enhancements):

Newly created windows doesn't show the effect (to replicate just do M-x
2). It is necessary to have different buffers on each window and move
the cursor form one to another one time to trigger the background
change.

When the other window contains several backgrounds, the effect is
displeasing.

Instead of picking a hard-coded background for the other windows, maybe
the current default background should be probed and a transformation
(darken, etc) applied to it. This would be most useful for users who
change themes from time to time.

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

[Steven Degutis]

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

Thanks for the ideas.

I've made an official github repo here:
https://github.com/sdegutis/auto-dim-other-buffers.el/

The face is now customizable, with the black-background one being a dumb
default. This way, everyone can choose for themselves what will look right,
whether the background should get lighter or darker or maybe the text color
should instead.

-Steven


On Tue, Apr 2, 2013 at 5:19 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> >     (defun auto-dim-other-windows ()
> >       (make-face 'sd/dimmed-font)
> >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> >
> >       (defun sd/prominantize-current-buffer (fn)
> >         (buffer-face-set 'sd/dimmed-font)
> >         (funcall fn)
> >         (buffer-face-set nil))
> >
> >       (defmacro sd/advise-window-changing-fn (fn)
> >         `(defadvice ,fn (around window-changing-fn-advice activate)
> >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> >
> >       (sd/advise-window-changing-fn other-window)
> >       (sd/advise-window-changing-fn other-frame)
> >       (sd/advise-window-changing-fn next-buffer)
> >       (sd/advise-window-changing-fn previous-buffer)
> >       (sd/advise-window-changing-fn quit-window)
> >       (sd/advise-window-changing-fn mouse-select-window))
>
> Interesting idea.
>
> Some observations (in case you already are interested on bugs &
> enhancements):
>
> Newly created windows doesn't show the effect (to replicate just do M-x
> 2). It is necessary to have different buffers on each window and move
> the cursor form one to another one time to trigger the background
> change.
>
> When the other window contains several backgrounds, the effect is
> displeasing.
>
> Instead of picking a hard-coded background for the other windows, maybe
> the current default background should be probed and a transformation
> (darken, etc) applied to it. This would be most useful for users who
> change themes from time to time.
>
>
>

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

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

[Óscar Fuentes]

Steven Degutis <sbdegutis@gmail.com> writes:

> Thanks for the ideas.
>
> I've made an official github repo here:
> https://github.com/sdegutis/auto-dim-other-buffers.el/
>
> The face is now customizable, with the black-background one being a dumb
> default. This way, everyone can choose for themselves what will look right,
> whether the background should get lighter or darker or maybe the text color
> should instead.

After trying your code from github, I have to ask: what is its purpose?
I thought that it is used for easily locating the window where the
cursor is. If that's true, you need to work with windows instead of
buffers (think of two windows showing the same buffer: as the buffer for
both is the "current" one, neither window is considered as "other" by
your code as long as the cursor is in one of them.)

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

[Steven Degutis]

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

Originally I wanted to make it change the face per-window, so I could
easily know which window I'm editing in. I even named it
auto-dim-other-windows at first.

Then I realized emacs only allows us to set per-buffer faces. It doesn't
allow us to set per-window faces. Please file a bug asking for the feature
to set per-window faces. For now, this is the best we can do with what
emacs gives us.

-Steven


On Tue, Apr 2, 2013 at 6:14 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> > Thanks for the ideas.
> >
> > I've made an official github repo here:
> > https://github.com/sdegutis/auto-dim-other-buffers.el/
> >
> > The face is now customizable, with the black-background one being a dumb
> > default. This way, everyone can choose for themselves what will look
> right,
> > whether the background should get lighter or darker or maybe the text
> color
> > should instead.
>
> After trying your code from github, I have to ask: what is its purpose?
> I thought that it is used for easily locating the window where the
> cursor is. If that's true, you need to work with windows instead of
> buffers (think of two windows showing the same buffer: as the buffer for
> both is the "current" one, neither window is considered as "other" by
> your code as long as the cursor is in one of them.)
>
>
>

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

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

[Michael Heerdegen]

Steven Degutis <sbdegutis@gmail.com> writes:

> Originally I wanted to make it change the face per-window, so I could
> easily know which window I'm editing in. I even named it
> auto-dim-other-windows at first.
>
> Then I realized emacs only allows us to set per-buffer faces. It
> doesn't allow us to set per-window faces. Please file a bug asking
> for the feature to set per-window faces. For now, this is the best we
> can do with what emacs gives us.

You can use the `window' overlay property for that - see (elisp) Overlay
Properties.

Apropos color: To get a dim color that is always derived live from the
current background color, you can (optionally) use "hexrgb" by Drew
Adam's for color transformation.  I can help with the coding if you are
interested.


Regards,

Michael.

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

[Michael Heerdegen]

Óscar Fuentes <ofv@wanadoo.es> writes:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> >     (defun auto-dim-other-windows ()
> >       (make-face 'sd/dimmed-font)
> >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> >
> >       (defun sd/prominantize-current-buffer (fn)
> >         (buffer-face-set 'sd/dimmed-font)
> >         (funcall fn)
> >         (buffer-face-set nil))
> >
> >       (defmacro sd/advise-window-changing-fn (fn)
> >         `(defadvice ,fn (around window-changing-fn-advice activate)
> >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> >
> >       (sd/advise-window-changing-fn other-window)
> >       (sd/advise-window-changing-fn other-frame)
> >       (sd/advise-window-changing-fn next-buffer)
> >       (sd/advise-window-changing-fn previous-buffer)
> >       (sd/advise-window-changing-fn quit-window)
> >       (sd/advise-window-changing-fn mouse-select-window))
>
> Interesting idea.
>
> Some observations (in case you already are interested on bugs &
> enhancements):
>
> Newly created windows doesn't show the effect (to replicate just do M-x
> 2). It is necessary to have different buffers on each window and move
> the cursor form one to another one time to trigger the background
> change.

One could use `window-configuration-change-hook' for that.

In general, I don't think it's a good idea to advice Emacs primitives
for that purpose.  And probably it will be hard to find all necessary
functions to advice.  What if the user has defined own commands to
select windows?  Or uses other packages that do so, e.g. winner?
That's why I suggested using `post-command-hook' instead.


Regards,

Michael.

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

[Steven Degutis]

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

Thanks. `post-command-hook` works better than
`window-configuration-change-hook`.

-Steven


On Wed, Apr 3, 2013 at 8:11 AM, Michael Heerdegen
<michael_heerdegen@web.de>wrote:

> Óscar Fuentes <ofv@wanadoo.es> writes:
>
> > Steven Degutis <sbdegutis@gmail.com> writes:
> >
> > >     (defun auto-dim-other-windows ()
> > >       (make-face 'sd/dimmed-font)
> > >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> > >
> > >       (defun sd/prominantize-current-buffer (fn)
> > >         (buffer-face-set 'sd/dimmed-font)
> > >         (funcall fn)
> > >         (buffer-face-set nil))
> > >
> > >       (defmacro sd/advise-window-changing-fn (fn)
> > >         `(defadvice ,fn (around window-changing-fn-advice activate)
> > >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> > >
> > >       (sd/advise-window-changing-fn other-window)
> > >       (sd/advise-window-changing-fn other-frame)
> > >       (sd/advise-window-changing-fn next-buffer)
> > >       (sd/advise-window-changing-fn previous-buffer)
> > >       (sd/advise-window-changing-fn quit-window)
> > >       (sd/advise-window-changing-fn mouse-select-window))
> >
> > Interesting idea.
> >
> > Some observations (in case you already are interested on bugs &
> > enhancements):
> >
> > Newly created windows doesn't show the effect (to replicate just do M-x
> > 2). It is necessary to have different buffers on each window and move
> > the cursor form one to another one time to trigger the background
> > change.
>
> One could use `window-configuration-change-hook' for that.
>
> In general, I don't think it's a good idea to advice Emacs primitives
> for that purpose.  And probably it will be hard to find all necessary
> functions to advice.  What if the user has defined own commands to
> select windows?  Or uses other packages that do so, e.g. winner?
> That's why I suggested using `post-command-hook' instead.
>
>
> Regards,
>
> Michael.
>
>

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

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

[Steven Degutis]

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

The source code is on github:
https://github.com/sdegutis/auto-dim-other-buffers.el

Window overlays seem inefficient here, given this line in the docs: "due to
a different implementation, overlays generally don't scale well (many
operations take a time that is proportional to the number of overlays in
the buffer)" and the following recommendation to avoid them when dealing
with "the visual appearance of many portions of the buffer". I don't quite
know if that applies here since I'm actually affecting the entire portion
of every buffer extremely often. I would assume so.

Then again, I don't really know elisp. And I only just started using emacs
a few months ago. So who knows, maybe I'm way off.

-Steven


On Wed, Apr 3, 2013 at 8:03 AM, Michael Heerdegen
<michael_heerdegen@web.de>wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> > Originally I wanted to make it change the face per-window, so I could
> > easily know which window I'm editing in. I even named it
> > auto-dim-other-windows at first.
> >
> > Then I realized emacs only allows us to set per-buffer faces. It
> > doesn't allow us to set per-window faces. Please file a bug asking
> > for the feature to set per-window faces. For now, this is the best we
> > can do with what emacs gives us.
>
> You can use the `window' overlay property for that - see (elisp) Overlay
> Properties.
>
> Apropos color: To get a dim color that is always derived live from the
> current background color, you can (optionally) use "hexrgb" by Drew
> Adam's for color transformation.  I can help with the coding if you are
> interested.
>
>
> Regards,
>
> Michael.
>
>

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

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

[Steven Degutis]

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

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

There's one bug left that I don't know how to fix: for some reason,
anything echoed in the echo area is dimmed. Not really sure why or even how.

Why didn't anything like this exist all this time? I've checked
stackoverflow for something like this months ago and the "chosen answer"
was to just use a more distinct modeline. But this is much better.

-Steven


On Tue, Apr 2, 2013 at 4:06 PM, Steven Degutis <sbdegutis@gmail.com> wrote:

>     (defun auto-dim-other-windows ()
>       (make-face 'sd/dimmed-font)
>       (set-face-attribute 'sd/dimmed-font nil :background "black")
>
>       (defun sd/prominantize-current-buffer (fn)
>         (buffer-face-set 'sd/dimmed-font)
>         (funcall fn)
>         (buffer-face-set nil))
>
>       (defmacro sd/advise-window-changing-fn (fn)
>         `(defadvice ,fn (around window-changing-fn-advice activate)
>            (sd/prominantize-current-buffer (lambda () ad-do-it))))
>
>       (sd/advise-window-changing-fn other-window)
>       (sd/advise-window-changing-fn other-frame)
>       (sd/advise-window-changing-fn next-buffer)
>       (sd/advise-window-changing-fn previous-buffer)
>       (sd/advise-window-changing-fn quit-window)
>       (sd/advise-window-changing-fn mouse-select-window))
>
> -Steven
>

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

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

[Mark Skilbeck]

On Wed, Apr 03, 2013 at 09:44:07AM -0500, Steven Degutis wrote:
> 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
> 
> There's one bug left that I don't know how to fix: for some reason,
> anything echoed in the echo area is dimmed. Not really sure why or even how.
> 
> Why didn't anything like this exist all this time? I've checked
> stackoverflow for something like this months ago and the "chosen answer"
> was to just use a more distinct modeline. But this is much better.

You're a real hero.

> 
> -Steven
> 
> 
> On Tue, Apr 2, 2013 at 4:06 PM, Steven Degutis <sbdegutis@gmail.com> wrote:
> 
> >     (defun auto-dim-other-windows ()
> >       (make-face 'sd/dimmed-font)
> >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> >
> >       (defun sd/prominantize-current-buffer (fn)
> >         (buffer-face-set 'sd/dimmed-font)
> >         (funcall fn)
> >         (buffer-face-set nil))
> >
> >       (defmacro sd/advise-window-changing-fn (fn)
> >         `(defadvice ,fn (around window-changing-fn-advice activate)
> >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> >
> >       (sd/advise-window-changing-fn other-window)
> >       (sd/advise-window-changing-fn other-frame)
> >       (sd/advise-window-changing-fn next-buffer)
> >       (sd/advise-window-changing-fn previous-buffer)
> >       (sd/advise-window-changing-fn quit-window)
> >       (sd/advise-window-changing-fn mouse-select-window))
> >
> > -Steven
> >

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

[Steven Degutis]

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

Okay okay I admit, that was an arrogant and pointless thing to say. Forgive
me.

-Steven


On Wed, Apr 3, 2013 at 9:47 AM, Mark Skilbeck <m@iammark.us> wrote:

> On Wed, Apr 03, 2013 at 09:44:07AM -0500, Steven Degutis wrote:
> > 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
> >
> > There's one bug left that I don't know how to fix: for some reason,
> > anything echoed in the echo area is dimmed. Not really sure why or even
> how.
> >
> > Why didn't anything like this exist all this time? I've checked
> > stackoverflow for something like this months ago and the "chosen answer"
> > was to just use a more distinct modeline. But this is much better.
>
> You're a real hero.
>
> >
> > -Steven
> >
> >
> > On Tue, Apr 2, 2013 at 4:06 PM, Steven Degutis <sbdegutis@gmail.com>
> wrote:
> >
> > >     (defun auto-dim-other-windows ()
> > >       (make-face 'sd/dimmed-font)
> > >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> > >
> > >       (defun sd/prominantize-current-buffer (fn)
> > >         (buffer-face-set 'sd/dimmed-font)
> > >         (funcall fn)
> > >         (buffer-face-set nil))
> > >
> > >       (defmacro sd/advise-window-changing-fn (fn)
> > >         `(defadvice ,fn (around window-changing-fn-advice activate)
> > >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> > >
> > >       (sd/advise-window-changing-fn other-window)
> > >       (sd/advise-window-changing-fn other-frame)
> > >       (sd/advise-window-changing-fn next-buffer)
> > >       (sd/advise-window-changing-fn previous-buffer)
> > >       (sd/advise-window-changing-fn quit-window)
> > >       (sd/advise-window-changing-fn mouse-select-window))
> > >
> > > -Steven
> > >
>

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

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

[Mark Skilbeck]

Apologies for being an ass in response.

- mgsks (a new auto-dim-other-buffers user)

On Wed, Apr 03, 2013 at 09:52:22AM -0500, Steven Degutis wrote:
> Okay okay I admit, that was an arrogant and pointless thing to say. Forgive
> me.
> 
> -Steven
> 
> 
> On Wed, Apr 3, 2013 at 9:47 AM, Mark Skilbeck <m@iammark.us> wrote:
> 
> > On Wed, Apr 03, 2013 at 09:44:07AM -0500, Steven Degutis wrote:
> > > 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
> > >
> > > There's one bug left that I don't know how to fix: for some reason,
> > > anything echoed in the echo area is dimmed. Not really sure why or even
> > how.
> > >
> > > Why didn't anything like this exist all this time? I've checked
> > > stackoverflow for something like this months ago and the "chosen answer"
> > > was to just use a more distinct modeline. But this is much better.
> >
> > You're a real hero.
> >
> > >
> > > -Steven
> > >
> > >
> > > On Tue, Apr 2, 2013 at 4:06 PM, Steven Degutis <sbdegutis@gmail.com>
> > wrote:
> > >
> > > >     (defun auto-dim-other-windows ()
> > > >       (make-face 'sd/dimmed-font)
> > > >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> > > >
> > > >       (defun sd/prominantize-current-buffer (fn)
> > > >         (buffer-face-set 'sd/dimmed-font)
> > > >         (funcall fn)
> > > >         (buffer-face-set nil))
> > > >
> > > >       (defmacro sd/advise-window-changing-fn (fn)
> > > >         `(defadvice ,fn (around window-changing-fn-advice activate)
> > > >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> > > >
> > > >       (sd/advise-window-changing-fn other-window)
> > > >       (sd/advise-window-changing-fn other-frame)
> > > >       (sd/advise-window-changing-fn next-buffer)
> > > >       (sd/advise-window-changing-fn previous-buffer)
> > > >       (sd/advise-window-changing-fn quit-window)
> > > >       (sd/advise-window-changing-fn mouse-select-window))
> > > >
> > > > -Steven
> > > >
> >

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

[Steven Degutis]

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

I forgive you of course. :)

By the way, I announced it too soon: the version in melpa is still a day
old so it's pretty inefficient and buggy and doesn't match up to the one in
github, so you may want to wait an hour or so before installing to let
melpa catch up. :(

-Steven


On Wed, Apr 3, 2013 at 9:55 AM, Mark Skilbeck <m@iammark.us> wrote:

> Apologies for being an ass in response.
>
> - mgsks (a new auto-dim-other-buffers user)
>
> On Wed, Apr 03, 2013 at 09:52:22AM -0500, Steven Degutis wrote:
> > Okay okay I admit, that was an arrogant and pointless thing to say.
> Forgive
> > me.
> >
> > -Steven
> >
> >
> > On Wed, Apr 3, 2013 at 9:47 AM, Mark Skilbeck <m@iammark.us> wrote:
> >
> > > On Wed, Apr 03, 2013 at 09:44:07AM -0500, Steven Degutis wrote:
> > > > 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
> > > >
> > > > There's one bug left that I don't know how to fix: for some reason,
> > > > anything echoed in the echo area is dimmed. Not really sure why or
> even
> > > how.
> > > >
> > > > Why didn't anything like this exist all this time? I've checked
> > > > stackoverflow for something like this months ago and the "chosen
> answer"
> > > > was to just use a more distinct modeline. But this is much better.
> > >
> > > You're a real hero.
> > >
> > > >
> > > > -Steven
> > > >
> > > >
> > > > On Tue, Apr 2, 2013 at 4:06 PM, Steven Degutis <sbdegutis@gmail.com>
> > > wrote:
> > > >
> > > > >     (defun auto-dim-other-windows ()
> > > > >       (make-face 'sd/dimmed-font)
> > > > >       (set-face-attribute 'sd/dimmed-font nil :background "black")
> > > > >
> > > > >       (defun sd/prominantize-current-buffer (fn)
> > > > >         (buffer-face-set 'sd/dimmed-font)
> > > > >         (funcall fn)
> > > > >         (buffer-face-set nil))
> > > > >
> > > > >       (defmacro sd/advise-window-changing-fn (fn)
> > > > >         `(defadvice ,fn (around window-changing-fn-advice activate)
> > > > >            (sd/prominantize-current-buffer (lambda () ad-do-it))))
> > > > >
> > > > >       (sd/advise-window-changing-fn other-window)
> > > > >       (sd/advise-window-changing-fn other-frame)
> > > > >       (sd/advise-window-changing-fn next-buffer)
> > > > >       (sd/advise-window-changing-fn previous-buffer)
> > > > >       (sd/advise-window-changing-fn quit-window)
> > > > >       (sd/advise-window-changing-fn mouse-select-window))
> > > > >
> > > > > -Steven
> > > > >
> > >
>

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

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

[Óscar Fuentes]

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.

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

[Óscar Fuentes]

Steven Degutis <sbdegutis@gmail.com> writes:

> By the way, I announced it too soon: the version in melpa is still a day
> old so it's pretty inefficient and buggy and doesn't match up to the one in
> github, so you may want to wait an hour or so before installing to let
> melpa catch up. :(

You are just being a good Free Software hacker: "Release early and
release often" :-)

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

[Steven Degutis]

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

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: 1564 bytes --]

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

[Ludwig, Mark]

> From: Steven Degutis
> Sent: Wednesday, April 03, 2013 9:44 AM

> Why didn't anything like this exist all this time?

I think you're answering your own question in part by going
through all the variations and challenges with the various
approaches.

Another answer is that many Emacs users have been using it for a
very long time, and the user base is self-selecting
(self-limiting?) by the fundamental nature of the baroque command
set and standard keyboard mappings.  (Only people with certain
kinds of wetware in their heads can handle it successfully.  It's
certainly not for everyone!)  If one can keep track of the
hundreds of key strokes and functions necessary to make using
Emacs really great, it's not usually much of a problem to
remember where the keyboard focus is.

For my part, I rarely lose track of where I am, but when I do, my
fingers reflexively go for ``C-/'' (undo) until the "damage" is
undone, then ``C-x o'' to get focus where I thought it was.
Nowadays, I take advantage of the multiple frame support, which
reduces the need for splitting a single frame into multiple
windows, and most window managers decorate the frame with focus
sufficiently to avoid making a mistake.

I have to confess to never noticing the change in mode line
shading (until this thread)!  What /I/ /usually/ notice is
whether the cursor is a solid or hollow block....

Cheers,
Mark

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

[Steven Degutis]

[-- 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 --]

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

[Steven Degutis]

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

Yes it's true we have the mental capability of holding lots of state in our
heads. But to be efficient, we should be offloading as much of the unneeded
state out of our heads as possible at any given moment. This is one of
those unnecessary state things. It should be visual.

Plus I have a bar cursor, not a box cursor. Plus even as a box, on my 27"
monitor, it's much too small to quickly find subconsciously.

-Steven


On Wed, Apr 3, 2013 at 10:57 AM, Ludwig, Mark <ludwig.mark@siemens.com>wrote:

> > From: Steven Degutis
> > Sent: Wednesday, April 03, 2013 9:44 AM
>
> > Why didn't anything like this exist all this time?
>
> I think you're answering your own question in part by going
> through all the variations and challenges with the various
> approaches.
>
> Another answer is that many Emacs users have been using it for a
> very long time, and the user base is self-selecting
> (self-limiting?) by the fundamental nature of the baroque command
> set and standard keyboard mappings.  (Only people with certain
> kinds of wetware in their heads can handle it successfully.  It's
> certainly not for everyone!)  If one can keep track of the
> hundreds of key strokes and functions necessary to make using
> Emacs really great, it's not usually much of a problem to
> remember where the keyboard focus is.
>
> For my part, I rarely lose track of where I am, but when I do, my
> fingers reflexively go for ``C-/'' (undo) until the "damage" is
> undone, then ``C-x o'' to get focus where I thought it was.
> Nowadays, I take advantage of the multiple frame support, which
> reduces the need for splitting a single frame into multiple
> windows, and most window managers decorate the frame with focus
> sufficiently to avoid making a mistake.
>
> I have to confess to never noticing the change in mode line
> shading (until this thread)!  What /I/ /usually/ notice is
> whether the cursor is a solid or hollow block....
>
> Cheers,
> Mark
>
>

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

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

[Drew Adams]

> I have to confess to never noticing the change in mode line
> shading (until this thread)!

The default mode-line face difference is not great - not pronounced enough, IMO.

FWIW, I use quite different backgrounds for these two faces:

 mode-line:          PaleGoldenrod
 mode-line-inactive: LightGray

I also have the cursor change automatically to a box (from a bar) when Emacs is
idle (2 sec, by default).  The (trivial) code for this is in oneonone.el.
http://www.emacswiki.org/emacs-en/download/oneonone.el

For even more visibility you can have Emacs show crosshairs (vertical and 
horizontal lines across the window) through the cursor when Emacs is idle.
For this, see library crosshairs.el.  (Here the default is 5 sec.)
http://www.emacswiki.org/emacs-en/download/crosshairs.el

These things can help make the selected window more obvious.  Of course one
person's helpful indication is another person's distraction or annoyance. ;-)

Personally, I do not use the automatic crosshairs-when-idle highlighting.

(I do toggle crosshairs mode on/off by hitting `C-+'.  The crosshairs follow the
cursor.  But this is for a different purpose than just noticing the selected
window.)

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

[Óscar Fuentes]

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.

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

[Steven Degutis]

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

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, Óscar 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
> 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.
>
>
>

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

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

[Óscar Fuentes]

Steven Degutis <sbdegutis@gmail.com> writes:

> Can minor modes be enabled/disabled on a per-window basis? If not, I think
> this doesn't solve the problem.

A minor mode is how this kind of features are usually implemented on
Emacs. Functionally, it is no better than your current approach based on
functions for enabling and disabling. Sorry for the confussion.

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

[Michael Heerdegen]

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

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

[Steven Degutis]

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

So it's more conventional to use a minor-mode to do this than just two
functions?

If so, is it considerably more difficult to implement it as a minor-mode?
And would the code look any cleaner?

-Steven


On Wed, Apr 3, 2013 at 12:17 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> > Can minor modes be enabled/disabled on a per-window basis? If not, I
> think
> > this doesn't solve the problem.
>
> A minor mode is how this kind of features are usually implemented on
> Emacs. Functionally, it is no better than your current approach based on
> functions for enabling and disabling. Sorry for the confussion.
>
>
>

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

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

[Steven Degutis]

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

Hmm, this could work. I mean, it would have to be a separate project since
by definition it dims other windows, not other buffers.

But it sounds like it might be tricky and have some caveats I haven't quite
thought out yet.

-Steven


On Wed, Apr 3, 2013 at 12:20 PM, Michael Heerdegen <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.  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.
>
>

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

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

[Óscar Fuentes]

Steven Degutis <sbdegutis@gmail.com> writes:

> So it's more conventional to use a minor-mode to do this than just two
> functions?
>
> If so, is it considerably more difficult to implement it as a minor-mode?
> And would the code look any cleaner?

From the POV of the user a minor mode is an standard interface for
customizing Emacs with active features. For instance, he can query Emacs
about which modes are active at any moment (M-x describe-mode). Emacs
provides some sugar for making it easy to implement minor modes. A minor
mode for this feature would be quite simple and could be implemented
with something like (not tested):

(define-minor-mode auto-dim-other-windows-mode
  "Dim the background of non-selected windows

  blah, blah, blah (more info here)"

  (if auto-dim-other-windows-mode
      (auto-dim-other-windows-mode-disable)
    (auto-dim-other-windows-mode-enable))

where auto-dim-other-windows-mode-enable/disable are the functions your
current implementation is using.

As you can see, the code overhead is minimal.

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

[Steven Degutis]

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

Seems legit. But then how do users typically install it? It's not like
other minor modes which are part of a hook. Do they just do
"auto-dim-other-buffers-mode" and it's enabled globally until they disable
it the same way or quit emacs?

Funny, melpa *just* updated it a few minutes ago, and it's already about to
be woefully out of date again. At least the version in melpa right now is
much more efficient than the last one.

-Steven


On Wed, Apr 3, 2013 at 1:10 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:

> Steven Degutis <sbdegutis@gmail.com> writes:
>
> > So it's more conventional to use a minor-mode to do this than just two
> > functions?
> >
> > If so, is it considerably more difficult to implement it as a minor-mode?
> > And would the code look any cleaner?
>
> From the POV of the user a minor mode is an standard interface for
> customizing Emacs with active features. For instance, he can query Emacs
> about which modes are active at any moment (M-x describe-mode). Emacs
> provides some sugar for making it easy to implement minor modes. A minor
> mode for this feature would be quite simple and could be implemented
> with something like (not tested):
>
> (define-minor-mode auto-dim-other-windows-mode
>   "Dim the background of non-selected windows
>
>   blah, blah, blah (more info here)"
>
>   (if auto-dim-other-windows-mode
>       (auto-dim-other-windows-mode-disable)
>     (auto-dim-other-windows-mode-enable))
>
> where auto-dim-other-windows-mode-enable/disable are the functions your
> current implementation is using.
>
> As you can see, the code overhead is minimal.
>

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

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

[Steven Degutis]

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

Okay, figured it out.

Now it's a global minor mode.

(But melpa won't catch up for a few hours.)

Thanks guys.

Later, if I can find some time, I might try to make a new similar project
that uses window-overlays via Michael's idea. And I'm going to name it
`tunnel-vision`, since the current project's name is way too long.

-Steven


On Wed, Apr 3, 2013 at 1:54 PM, Steven Degutis <sbdegutis@gmail.com> wrote:

> Seems legit. But then how do users typically install it? It's not like
> other minor modes which are part of a hook. Do they just do
> "auto-dim-other-buffers-mode" and it's enabled globally until they disable
> it the same way or quit emacs?
>
> Funny, melpa *just* updated it a few minutes ago, and it's already about
> to be woefully out of date again. At least the version in melpa right now
> is much more efficient than the last one.
>
> -Steven
>
>
> On Wed, Apr 3, 2013 at 1:10 PM, Óscar Fuentes <ofv@wanadoo.es> wrote:
>
>> Steven Degutis <sbdegutis@gmail.com> writes:
>>
>> > So it's more conventional to use a minor-mode to do this than just two
>> > functions?
>> >
>> > If so, is it considerably more difficult to implement it as a
>> minor-mode?
>> > And would the code look any cleaner?
>>
>> From the POV of the user a minor mode is an standard interface for
>> customizing Emacs with active features. For instance, he can query Emacs
>> about which modes are active at any moment (M-x describe-mode). Emacs
>> provides some sugar for making it easy to implement minor modes. A minor
>> mode for this feature would be quite simple and could be implemented
>> with something like (not tested):
>>
>> (define-minor-mode auto-dim-other-windows-mode
>>   "Dim the background of non-selected windows
>>
>>   blah, blah, blah (more info here)"
>>
>>   (if auto-dim-other-windows-mode
>>       (auto-dim-other-windows-mode-disable)
>>     (auto-dim-other-windows-mode-enable))
>>
>> where auto-dim-other-windows-mode-enable/disable are the functions your
>> current implementation is using.
>>
>> As you can see, the code overhead is minimal.
>>
>
>

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

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

[Stefan Monnier]

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

Auto-adding the overlays can be done in window-configuration-change-hook.
We're talking about N overlays per buffer where N is small (it's number of
windows where the buffer is displayed), so there's no performance
problem there.

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

That would be a lot simpler, indeed, but I think it will be difficult
to make it look good.


        Stefan

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

[Steven Degutis]

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

The problem with `window-configuration-change-hook` is that it isn't called
all the times we would need it. For example, it's not called when you do
`other-window` via `C-x o`.

-Steven


On Wed, Apr 3, 2013 at 3:13 PM, Stefan Monnier <monnier@iro.umontreal.ca>wrote:

> > 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.
>
> Auto-adding the overlays can be done in window-configuration-change-hook.
> We're talking about N overlays per buffer where N is small (it's number of
> windows where the buffer is displayed), so there's no performance
> problem there.
>
> > 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.
>
> That would be a lot simpler, indeed, but I think it will be difficult
> to make it look good.
>
>
>         Stefan
>
>
>

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

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

[Steven Degutis]

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

Never mind, this technique seems much too hard to get right while being
reasonably efficient.

-Steven


On Wed, Apr 3, 2013 at 12:20 PM, Michael Heerdegen <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.  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.
>
>

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

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

[Stefan Monnier]

> The problem with `window-configuration-change-hook` is that it isn't called
> all the times we would need it. For example, it's not called when you do
> `other-window` via `C-x o`.

It's not sufficient, indeed: it's the hook needed to know when an overlay
needs to be added.  But you additionally need a post-command-hook to
disable the overlay of the selected window (and enable the overlay of
the previously selected window).


        Stefan

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

[Joost Kremers]

Steven Degutis wrote:
> --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.

i only skimmed the rest of this thread so perhaps i'm suggesting
something that's already been mentioned, but couldn't you do it the
other way around? instead of dimming all other windows, why not
highlight the selected one? apply some magic to the default font perhaps
and then undo that effect is the selected window. i have no idea if
something like that might work, but it may be worth a look.

another hint might be to look at ace-jump-mode: it dims everything in
the current frame except for a number of jump targets. there might be
some useful ideas in there.

finally, you might want to consider that there are windows whose
contents are meant to be seen even if they're not selected. i don't know
of any good heuristic to find those windows, so you may want to consider
adding a customise option that the user can use to set his or her
favourite "do not dim" buffers, which are not dimmed when displayed in
some non-selected window (preferably a list of regexps, i'd say).


-- 
Joost Kremers                                   joostkremers@fastmail.fm
Selbst in die Unterwelt dringt durch Spalten Licht
EN:SiS(9)

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

[Steven Degutis]

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

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

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

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

[Ludwig, Mark]

> From: Joost Kremers
> Sent: Thursday, April 04, 2013 2:27 AM
> 
> ... you might want to consider that there are windows whose contents are
> meant to be seen even if they're not selected. 

I've been thinking about this too.  What comes to mind immediately is Ediff (which uses multiple windows and frames concurrently).

Cheers,
Mark

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

[Steven Degutis]

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

Crap.

-Steven


On Thu, Apr 4, 2013 at 3:52 PM, Ludwig, Mark <ludwig.mark@siemens.com>wrote:

> > From: Joost Kremers
> > Sent: Thursday, April 04, 2013 2:27 AM
> >
> > ... you might want to consider that there are windows whose contents are
> > meant to be seen even if they're not selected.
>
> I've been thinking about this too.  What comes to mind immediately is
> Ediff (which uses multiple windows and frames concurrently).
>
> Cheers,
> Mark
>
>
>

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

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

[Steven Degutis]

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

Okay this problem is too hard to solve. I just made my hl-line's background
blue. Problem solved :(

-Steven


On Thu, Apr 4, 2013 at 3:53 PM, Steven Degutis <sbdegutis@gmail.com> wrote:

> Crap.
>
> -Steven
>
>
> On Thu, Apr 4, 2013 at 3:52 PM, Ludwig, Mark <ludwig.mark@siemens.com>wrote:
>
>> > From: Joost Kremers
>> > Sent: Thursday, April 04, 2013 2:27 AM
>> >
>> > ... you might want to consider that there are windows whose contents are
>> > meant to be seen even if they're not selected.
>>
>> I've been thinking about this too.  What comes to mind immediately is
>> Ediff (which uses multiple windows and frames concurrently).
>>
>> Cheers,
>> Mark
>>
>>
>>
>

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

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

[Drew Adams]

FWIW, and ignore this if it doesn't help -

1. I suggest you start by asking yourself *why* you want to distinguish the
selected window (or all the non-selected windows, which amounts to the same
thing).

If the answer it just to *make clear which* window is selected, then dimming any
of them is not a great approach, IMHO.  If that's the only reason then
presumably you would want all of the windows to remain easy to read etc.

If the answer is just to more or less remove the non-selected windows from your
attention, then I'd suggest that there are better approaches, including perhaps
scaling their text smaller.

IOW, if you do not really care whether the non-selected windows are as readable
as the selected window, and you do not want to be distracted by them but would
prefer to more or less ignore them temporarily, then why bother wasting so much
screen real estate on them?  Taking up screen space with intentionally dimmed
windows makes little sense to me.


2. Out of the box, text scaling does not free up any screen real estate: when
you shrink text its window does not also shrink.  But if you use library
`face-remap+.el' then non-nil option `text-scale-resize-window' shrinks the
window along with the text.

However, just resizing a window in conjunction with text scaling affects only
the vertical space, not the horizontal space.  And shrinking one window grows
the adjacent windows, so in itself it is not a solution to try shrinking all the
non-selected windows.  The heights and widths of their frames would not change.


3. But you can also thumbify a frame, which is similar but it does shrink the
frame.  It shrinks the text of each of its windows (so you would not want to
thumbify the frame that has the selected window).

You can set the thumbifying shrink factor so that thumbified frames are anything
from tiny (active desktop icons, in essence) to only slightly smaller than
normal.

When you thumbify a frame, it puts its windows and text in the background in
terms of your attention - and it frees up screen space.

But the windows and text are still there and still usable.  Depending on the
shrink factor you choose, this effect is more or less pronounced.

Even very tiny frames whose text is unreadable can be effective in terms of
searching text or monitoring process output.  IOW, for some Emacs operations you
do not actually need to be able to read the text clearly.

(Ordinary frame iconifying is of course another solution to the attention
focus/distraction problem, albeit a somewhat coarse one.  It too gets less
interesting frames out of the way.  But you cannot see their content or interact
with it.)

http://www.emacswiki.org/emacs-en/download/face-remap%2b.el
http://www.emacswiki.org/emacs-en/download/thumb-frm.el

Doc/screenshot of thumbified frames:
http://www.emacswiki.org/FisheyeWithThumbs

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

[Steven Degutis]

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

Thanks.

The goal was to make it more obvious at a really quick glance where the
cursor is.

Thumbifying and iconifying won't suffice because generally I need all my
windows open at once. Maybe I'm abnormal.

For now I just made my hl-line face have a blue background. It's working
well enough for now.

-Steven


On Thu, Apr 4, 2013 at 4:55 PM, Drew Adams <drew.adams@oracle.com> wrote:

> FWIW, and ignore this if it doesn't help -
>
> 1. I suggest you start by asking yourself *why* you want to distinguish the
> selected window (or all the non-selected windows, which amounts to the same
> thing).
>
> If the answer it just to *make clear which* window is selected, then
> dimming any
> of them is not a great approach, IMHO.  If that's the only reason then
> presumably you would want all of the windows to remain easy to read etc.
>
> If the answer is just to more or less remove the non-selected windows from
> your
> attention, then I'd suggest that there are better approaches, including
> perhaps
> scaling their text smaller.
>
> IOW, if you do not really care whether the non-selected windows are as
> readable
> as the selected window, and you do not want to be distracted by them but
> would
> prefer to more or less ignore them temporarily, then why bother wasting so
> much
> screen real estate on them?  Taking up screen space with intentionally
> dimmed
> windows makes little sense to me.
>
>
> 2. Out of the box, text scaling does not free up any screen real estate:
> when
> you shrink text its window does not also shrink.  But if you use library
> `face-remap+.el' then non-nil option `text-scale-resize-window' shrinks the
> window along with the text.
>
> However, just resizing a window in conjunction with text scaling affects
> only
> the vertical space, not the horizontal space.  And shrinking one window
> grows
> the adjacent windows, so in itself it is not a solution to try shrinking
> all the
> non-selected windows.  The heights and widths of their frames would not
> change.
>
>
> 3. But you can also thumbify a frame, which is similar but it does shrink
> the
> frame.  It shrinks the text of each of its windows (so you would not want
> to
> thumbify the frame that has the selected window).
>
> You can set the thumbifying shrink factor so that thumbified frames are
> anything
> from tiny (active desktop icons, in essence) to only slightly smaller than
> normal.
>
> When you thumbify a frame, it puts its windows and text in the background
> in
> terms of your attention - and it frees up screen space.
>
> But the windows and text are still there and still usable.  Depending on
> the
> shrink factor you choose, this effect is more or less pronounced.
>
> Even very tiny frames whose text is unreadable can be effective in terms of
> searching text or monitoring process output.  IOW, for some Emacs
> operations you
> do not actually need to be able to read the text clearly.
>
> (Ordinary frame iconifying is of course another solution to the attention
> focus/distraction problem, albeit a somewhat coarse one.  It too gets less
> interesting frames out of the way.  But you cannot see their content or
> interact
> with it.)
>
> http://www.emacswiki.org/emacs-en/download/face-remap%2b.el
> http://www.emacswiki.org/emacs-en/download/thumb-frm.el
>
> Doc/screenshot of thumbified frames:
> http://www.emacswiki.org/FisheyeWithThumbs
>
>

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

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

[Stefan Monnier]

> The goal was to make it more obvious at a really quick glance where the
> cursor is.

Maybe a different approach would work then: assuming that when actively
using Emacs you know where the cursor is, the problem should mostly be
to find the cursor when coming back to Emacs.

In that case, maybe you could make the cursor in the selected window
"annoyingly" visible (along the lines of hl-line, for example) after
some idle time.


        Stefan "who uses a window manager where the focus always follows
                the mouse, so finding the selected window amounts to
                finding the mouse cursor"

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

[Drew Adams]

> > The goal was to make it more obvious at a really quick 
> > glance where the cursor is.
> 
> Maybe a different approach would work then: assuming that 
> when actively
> using Emacs you know where the cursor is, the problem should mostly be
> to find the cursor when coming back to Emacs.
> 
> In that case, maybe you could make the cursor in the selected window
> "annoyingly" visible (along the lines of hl-line, for example) after
> some idle time.

Which is *exactly* what automatic crosshairs-when-idle highlighting does, as I
reported earlier.

The cursor position is shown with cross-the-window crosshairs, but only after an
idle delay and only until you are no longer idle.

It's simple to try it, to see.  And the code is easy to understand, if you want
to do something different but similar using a timer.

Just load the code and `M-x toggle-crosshairs-when-idle':

code:
http://www.emacswiki.org/emacs-en/download/crosshairs.el

description+screenshot:
http://www.emacswiki.org/emacs/CrosshairHighlighting