Dim the minibuffer?

[mentalisttraceur]

I sometimes select another window while the minibuffer remains "in use", and it would be nice if the minibuffer itself got dimmed like other windows in those cases.

Compare these two cases:

1. It is immediately obvious (once you know that black background is active and gray background is dimmed) from just an imprecise glance at either of the windows or the minibuffer if they are active or not:

   

2. It is not immediately obvious from an imprecise glance if the minibuffer is active or if the right window is active:

   

   (Note: this is not due to the (setq auto-dim-other-buffers-dim-on-switch-to-minibuffer nil) line visible in these screenshots - that line was not in effect at the time that I took these screenshots, so auto-dim-other-buffers-dim-on-switch-to-minibuffer was set to t, and in fact it was the right window which was selected, not the minibuffer.)

In fact, in the first picture, we actually can't know from the available visual information if the minibuffer was active - for example, there might be a non-dimmed window in a frame on another monitor.

One example where this comes up: I might be in the middle of writing an M-: line, and then realize I already have some text I want to just reference or copy in a buffer I have open: so I use ace-window (I think plain other-window would work too) to leave the minibuffer, do soomething, and come back.

Another example:

1. consult-line to find text I I want to copy from elsewhere in the file (or consult-ripgrep if that text is in another file),
2. "select' the desired match in the minibuffer (this scrolls the main buffer to center that line in that buffer/file) but don't hit RET in the minuffer
3. switch to the window from the minibuffer (I use ace-window, but I think C-x o/other-window would work) - this leaves the consult function unfinished in the minibuffer, and I can select/edit/copy text in the main buffer which is still "previewing" where the consult search would jump to, and finally
   6.switch back to the minibuffer "window", and abort (C-g), which scrolls the main buffer back to where I was when I started the consult search, so I can paste/etc - so obviously this is faster and less manual hassle than if I had to "finish" the consult search, and then navigate back to where I started.

(That second example can be replaced by getting fluent with the mark/jump ring stuff since then I wouldn't need to leave the minibuffer mid-command, but the first one can't, and the point is that this is a very broadly applicable thing - now that I have good keybinds for jumping out of the minibuffer while it's mid-command and then jumping back into it, I find all sorts of situations where that's enough to improve my workflow without me having to learn/configure anything else.)

[mentalisttraceur]

P.S. Thank you very much for making auto-dim-other-buffers!

I just found it this morning (you saw my youtube comments on your video demoing what it looks like), and there's already been one situation where it helped me more quickly recognize that window selection switched in a way I didn't expect.

[mina86]

Minibuffer is a bit magical in that it never gets dimmed. The assumption being that one doesn’t want echo area to be dimmed. I can take a look into dimming the minibuffer but no promises on ETA.

[mentalisttraceur]

Thanks! At a really quick glance, I think you could just use t for the MINIBUF parameter of the window-list call in adob--rescan-windows and your existing logic seems like it would work fine:

Two things happening in that picture:

1. point and region are on the spot I'm talking about in your code, but also
2. the minibuffer is dimmed! (for now I just manually ran (let ((w (car (window-list nil t)))) (set-window-parameter w 'adob--dim t) (force-window-update)) to see what it looks like and if anything immediately broke)

So maybe we can just add a customizable auto-dim-other-buffers-dim-minibuffer and then use (if auto-dim-other-buffers-dim-minibuffer t 'n) instead of just 'n in that call?

[mentalisttraceur]

Ah, sorry, after a quick test, my suggestion doesn't actually work. I tried:

-      (dolist (wnd (window-list nil 'n))                                                      
+     (dolist (wnd (window-list nil (if auto-dim-other-buffers-dim-minibuffer                  
+                                        t 'n)))

and then manually evaluated (setq auto-dim-other-buffers-dim-minibuffer t).

I don't really understand why it failed to dim the minibuffer (there are actually moments when the minibuffer is inactive during/after echoes where it does dim/undim, so something is happening...). But hopefully it's more obvious to you what's going on there, since you're already familiar with your code.

[mentalisttraceur]

Ahhh, okay I see you've got some window-minibuffer-p checks in a few places. I've started adjust those and things are starting to work better.

[mina86]

adob--update also needs to be changed since it has special handling preventing minibuffer from being dimmed.

[mentalisttraceur]

What about adob--focus-out-hook? It also has a window-minibuffer-p check.

Here's a full diff (including focus-out-hook), which gets me behavior that I'm happy with (also, feel free to let me know if adding the line numbers to the diff is helpful or in-the-way!):

  238⋮ 238│                      (get-buffer-window-list buffer 'n 'visible)))
  239⋮ 239│      (set-window-parameter wnd 'adob--dim (not (eq wnd except-in))))))
  240⋮ 240│
+    ⋮ 241│(defun adob--window-minibuffer-p (window)
+    ⋮ 242│  "Like window-minibuffer-p, but lie and say that the window is
+    ⋮ 243│  not on a minibuffer if auto-dim-other-buffers-dim-minibuffer
+    ⋮ 244│  is true, because that variable means to not treat minibuffers
+    ⋮ 245│  specially and dim them like any other windows."
+    ⋮ 246│  (and (not auto-dim-other-buffers-dim-minibuffer)
+    ⋮ 247│       (window-minibuffer-p window)))
+    ⋮ 248│
  241⋮ 249│(defun adob--update ()
  242⋮ 250│  "Make sure that selected window is not dimmed.
  243⋮ 251│Dim previously selected window if selection has changed."
  244⋮ 252│  (when (or auto-dim-other-buffers-dim-on-switch-to-minibuffer
- 245⋮    │            (not (window-minibuffer-p)))
+    ⋮ 253│            (not (adob--window-minibuffer-p)))
  246⋮ 254│    (let* ((wnd (selected-window))
  247⋮ 255│           (buf (window-buffer wnd)))
  248⋮ 256│


  252⋮ 260│        ;; adow-mode is active and window has changed.  Update the adob--dim
  253⋮ 261│        ;; parameter accordingly.
  254⋮ 262│        (when (and (window-live-p adob--last-window)
- 255⋮    │                   (not (window-minibuffer-p adob--last-window)))
+    ⋮ 263│                   (not (adob--window-minibuffer-p adob--last-window)))
  256⋮ 264│          (set-window-parameter adob--last-window 'adob--dim t)
  257⋮ 265│          (force-window-update adob--last-window))
  258⋮ 266│        (setq adob--last-window wnd)
- 259⋮    │        (unless (window-minibuffer-p adob--last-window)
+    ⋮ 267│        (unless (adob--window-minibuffer-p adob--last-window)
  260⋮ 268│          (set-window-parameter adob--last-window 'adob--dim nil)
  261⋮ 269│          (force-window-update adob--last-window)))
  262⋮ 270│       (t


  266⋮ 274│        ;; while at the same time changing buffer in the old window.  In this
  267⋮ 275│        ;; scenario, we’re never dimming the buffer in the old window.
  268⋮ 276│        (and (window-live-p adob--last-window)
- 269⋮    │             (not (window-minibuffer-p adob--last-window))
+    ⋮ 277│             (not (adob--window-minibuffer-p adob--last-window))
  270⋮ 278│             (let ((old-buf (window-buffer adob--last-window)))
  271⋮ 279│               (unless (or (eq old-buf buf)
  272⋮ 280│                           (eq old-buf adob--last-buffer))


  290⋮ 298│  (let* ((selected-window (selected-window))
  291⋮ 299│         (selected-buffer (window-buffer selected-window)))
  292⋮ 300│    (save-current-buffer
- 293⋮    │      (dolist (wnd (window-list nil 'n))
+    ⋮ 301│      (dolist (wnd (window-list nil (if auto-dim-other-buffers-dim-minibuffer
+    ⋮ 302│                                        t 'n)))
  294⋮ 303│        (let ((buf (window-buffer wnd)))
  295⋮ 304│          (cond (adob--adow-mode
  296⋮ 305│                 ;; Update window’s ‘adob--dim’ parameter.  If it changes set


  325⋮ 334│             (buffer-live-p adob--last-buffer))
  326⋮ 335│    (if adob--adow-mode
  327⋮ 336│        (when (and (window-live-p adob--last-window)
- 328⋮    │                   (not (window-minibuffer-p adob--last-window)))
+    ⋮ 337│                   (not (adob--window-minibuffer-p adob--last-window)))
  329⋮ 338│          (set-window-parameter adob--last-window 'adob--dim t)
  330⋮ 339│          (force-window-update adob--last-window))
  331⋮ 340│      (save-current-buffer

Amusingly, with this patch, the echo area is dimmed only while echoing. When it's empty, it's not dimmed. (For me that aesthetic blemish isn't a deal-breaker, and I'd rather have the feature with that flaw than not at all.)

[mentalisttraceur]

Oh sorry also

(defcustom auto-dim-other-buffers-dim-minibuffer nil
  "Whether to dim minibuffers just like regular windows."
  :type 'boolean
  :group 'auto-dim-other-buffers)

Somewhere up top with the other defcustom.

[mentalisttraceur]

If you're basically happy with this I can roll it into a proper PR. If you have any ideas of how to clean up the remaining blemish (protect the minibuffer from dimming just when it's being used as the echo area) that would be cool - I'm going to slightly poke my mind at that problem but unless I can quickly get traction and speed on it I might have to move on.

[mentalisttraceur]

Ah! It seems like *Minibuf-0* is used for echo, and all the other minibuffer-using commands create/use *Minibuf-{1,2,...}*...

So the quickest-and-dirtiest solution is for that adob--window-minibuffer-p function to have a special case for a minibuffer called *Minibuf-0*. I feel a little uncomfortable with that unless we find guarantees that Emacs will never allow another minibuffer to be given the number zero and that the echo minibuffer will never have any other number. But I'll do a quick test down this path to see if it at least works rather than being totally off-base.

[mentalisttraceur]

[edit: this comment was mistaken and is irrelevant/misleading]

[mentalisttraceur]

Pfft, I'm wrong, echo area also uses *Minibuf-1* for echoes [edit: turned out it was *Echo Area {0,1}*]. I guess Minibuf-0 just hangs around doing literally nothing besides looking pretty when nothing else is going on. (So at least one consistency alternative would be to dim Minibuf-0 - that way the echo area at least doesn't un-dim itself in-between echoes.)

[mentalisttraceur]

Promising tidbit, emphasis added:

The echo area is used for displaying error messages (see Errors), for messages made with the message primitive, and for echoing keystrokes. It is not the same as the minibuffer, despite the fact that the minibuffer appears (when active) in the same place on the screen as the echo area.

• from the Emacs manual.

This is promising because it suggests on some level Emacs recognizes the echo area and the minibuffer as separate concepts, so there's hope that we can figure out how to programmatically detect the difference between normal minibuffer buffers and specifically the "echo area" buffers.

[mentalisttraceur]

Victory!

The magic minibuffer names we need are " *Echo Area {0,1,2,3,...}*".

For some reason my Emacsi all seem to have both Echo Area 0 and Echo Area 1 (and recreate both immediately if I kill those buffers), but just special-casing Echo Area 0 seemed to be enough to keep the echo area from dimming.

[mentalisttraceur]

Okay, so, near as I can tell, there's only *Echo Area 0* and *Echo Area 1* - I guess they're hardcoded? All the code I found floating around either targets just echo area 0 or both 0 and 1, and in 2014, Stefan Monnier (who was head maintainer of Emacs for some time before 2015) assured us that there is never an Echo Area 2 or above.

And it sounds in multiple sources like Emacs alternates between these two buffers as the actual echo area contents?

(What's kinda important and messed up though, is that in manual testing I've noticed it's possible to rename these buffers. So at any time, efforts to detect these buffers by name could be undermined. I guess that's just one of those things we just have to assume for sanity's sake is not our problem - something in the world ought to make sure that the echo area "buffers" are reliably accessible in some way, and the only way we have available is to look for buffers with " Echo Area {0,1}" names - yes it's possible for any package or user to just casually break that "API", but the Right Place(tm) for that problem to be dealt with is not in packages who just need to know if they're looking at one of those buffers or not.)