Re: mode-line-inactive and toggle-input-method

[Kim F. Storm]

Al Petrofsky <address@hidden> writes:

> > From: address@hidden (Kim F. Storm)
> 
> > The proper fix is to add a new internal variable (named
> > Vminibuf_selected_window) which is similar to Vminibuf_scroll_window,
> > but which doesn't change after entry to the minibuffer, and which
> > doesn't change if we recursively enter the minibuffer from a selected
> > minibuffer window.  My testing shows this works very well.
> 
> Why the inconsistency for minibuffer entry from the miniwindow?  I
> would find it more informative for all mode-lines to go inactive to
> indicate that this has happened.  I sometimes accidentally hit M-x
> twice in a row.  It would be useful to have immediate feedback that
> this has happened.
> 

The problem that was reported was related to doing "trivial" commands
like C-u C-\ in the minibuffer would turn off the mode line indication
of the selected window.  That is confusing.

As you say, it may be equally confusing that this doesn't happen
if you accidentally hit M-x twice in a row.

I don't know how to solve this.  Any ideas?

We could handle M-x specially, i.e. if this-command is
execute-extended-command and we enter from the minibuffer, then
Vminibuf_selected_window should be set to nil.  But that's a hack!

> 
> As a separate issue, it seems to me that the active mode-line face
> should be used only when the window is actually selected.  When the
> selected window is a miniwindow, I suggest using a separate
> "semi-active" mode-line face for the minibuf-selected-window.  By
> default, this could be the same as the active face if that's what
> people like.
> 

I can see what you mean, but I don't think it is really necessary.
After all, no emacs version prior to 21.3 have been able to differentiate
on the mode line in any way -- compared to that, I think the current
behaviour is already a big advantage.

> I seem to recall the original requester of this feature wanted to be
> able to tell which window was selected by glancing at the frame's
> mode-lines, rather than having to find the cursor.  If moving into the
> miniwindow doesn't change any of the mode-lines, then the feature
> fails to provide that functionality.

I believe that the original requester was me - and I found that I
liked the current behaviour much more than what I had initially
proposed (and implemented).

-- 
Kim F. Storm <address@hidden> http://www.cua.dk