On this topic of Isearch vs minibuffer, since it's been broached - I think most people agree that users often mistakenly think they're in the minibuffer during Isearch. That doesn't help anyone. As I've said, I, for one, think it's good that Isearch doesn't use the minibuffer. But I think it might help if there were a visual indication of some kind, to distinguish Isearching from use of the minibuffer, and Isearching from (other) use of the echo area. ___ With my setup there's no such possible confusion, as I use a standalone minibuffer frame (which is of course also used for Isearch and the echo area). The frame background changes hue slightly for Isearch - no possible confusion. And it changes (a different) hue slightly for inactive (no minibuffer) and for each recursive minibuffer (new hue for each, up to a limit, then cycle). I'm not suggesting that vanilla Emacs use a standalone minibuffer frame (!). But I am suggesting that it might help to provide some visual indication of states such as the following: (a) whether Isearch is active, (b) whether the minibuffer is active, and (c) whether a recursive edit is in progress (and what level). ___ We already have [[...]] in the mode-line for (c). My tiny library `rec-edit.el' makes the level more obvious, by optionally highlighting bracket pairs with different faces (different by default). And it gives you the single key `C-M-c' to both enter and exit a recursive edit. (It exits, unless you use a prefix arg.) The behavior is turned on/off with a minor mode. https://www.emacswiki.org/emacs/RecursiveEdit#rec-edit.el ___ _Apart_ from indicating recursive editing and level: I tend to think that indication of the current state of the echo area / minibuffer is better indicated in that area itself. The hue change I mentioned (for a standalone frame) is a good approach, I think. The effect is subtle, not in your face. You sense the change, more than you consciously register it. But it's there, so if you ever do pay attention to it you can tell what state you're in - what you're doing and expected to do or not do. It becomes second nature - you'll never think/feel that you're in a minibuffer when you're isearching, and you can easily sense the difference between a read that doesn't use the minibuffer (it's inactive) and one that does. Dunno whether or how much it would be feasible to make the echo area/minibuffer window have a slight change in hue to reflect state changes. Just a thought. If we did opt for somehow indicating state change for this area, I think the indication should be right there - in that area. And it should remain in effect as long as the particular state does. E.g., it shouldn't consist of a "notification", such as a message or a flash or ding. It should be subtle but perceptive. Thoughts?
> From: Drew Adams <drew.adams@oracle.com>
> Date: Wed, 12 May 2021 23:47:07 +0000
> Cc: Alan Mackenzie <acm@muc.de>, Augusto Stoffel <arstoffel@gmail.com>,
> Stefan Monnier <monnier@iro.umontreal.ca>,
> "emacs-devel@gnu.org" <emacs-devel@gnu.org>
>
> As I've said, I, for one, think it's good that Isearch
> doesn't use the minibuffer. But I think it might help
> if there were a visual indication of some kind, to
> distinguish Isearching from use of the minibuffer, and
> Isearching from (other) use of the echo area.
There is such an indication: the cursor is not in the mini-window.
> > As I've said, I, for one, think it's good that Isearch
> > doesn't use the minibuffer. But I think it might help
> > if there were a visual indication of some kind, to
> > distinguish Isearching from use of the minibuffer, and
> > Isearching from (other) use of the echo area.
>
> There is such an indication: the cursor is not in the mini-window.
Yes, there is indeed an "indication of some kind".
ABut as the Subject says, this is about _better_
indicating such things - being _more_ helpful.
On 5/13/21 4:11 PM, Drew Adams wrote:
>>> As I've said, I, for one, think it's good that Isearch
>>> doesn't use the minibuffer. But I think it might help
>>> if there were a visual indication of some kind, to
>>> distinguish Isearching from use of the minibuffer, and
>>> Isearching from (other) use of the echo area.
>>
>> There is such an indication: the cursor is not in the mini-window.
>
> Yes, there is indeed an "indication of some kind".
>
> ABut as the Subject says, this is about _better_
> indicating such things - being _more_ helpful.
Personally, I would not like to use such a colorful "subtle" indication
in the echo area. To me this seems more like an implementation detail,
which should not be visible to the user.
The echo area/minibuffer distinction comes up from time to time in
discussions with new users. I know that I had been confused for a while
with the Isearch behavior. The Isearch use of the echo area is
unexpected. Users expect to enter a search string into a separate input
form as is common in many other programs. In Emacs this input form is
the minibuffer.
I would welcome the changes by Augusto. The minibuffer-controlled
Isearch makes entering the search string more robust with regards to
various editing commands as mentioned before by Kévin Le Gouguec.
There exists the ctrlf package on MELPA which also uses the minibuffer,
but it feels hardly justified to install an extra package only to get a
minibuffer-controlled search mode. I also don't want to replace such a
tightly integrated component like Isearch with an external package. If a
minibuffer mode can be added to Isearch with small effort and in a
reasonably clean way, why not do that?
Daniel
Hello, Daniel. On Thu, May 13, 2021 at 16:41:10 +0200, Daniel Mendler wrote: > On 5/13/21 4:11 PM, Drew Adams wrote: > >>> As I've said, I, for one, think it's good that Isearch > >>> doesn't use the minibuffer. But I think it might help > >>> if there were a visual indication of some kind, to > >>> distinguish Isearching from use of the minibuffer, and > >>> Isearching from (other) use of the echo area. > >> There is such an indication: the cursor is not in the mini-window. > > Yes, there is indeed an "indication of some kind". > > ABut as the Subject says, this is about _better_ > > indicating such things - being _more_ helpful. > Personally, I would not like to use such a colorful "subtle" indication > in the echo area. To me this seems more like an implementation detail, > which should not be visible to the user. > The echo area/minibuffer distinction comes up from time to time in > discussions with new users. I know that I had been confused for a while > with the Isearch behavior. The Isearch use of the echo area is > unexpected. Users expect to enter a search string into a separate input > form as is common in many other programs. In Emacs this input form is > the minibuffer. That's a rather misleading way of portraying it. Users used to other programs tend not to be familiar with incremental search, where point is not in "a separate input form" but in the buffer they're searching through. There is no "separate input form". Besides, currently isearch can be used in the mini-window, searching through a minibuffer. If we are not to lose this feature, things will get complicated and messy. > I would welcome the changes by Augusto. The minibuffer-controlled > Isearch makes entering the search string more robust with regards to > various editing commands as mentioned before by Kévin Le Gouguec. But it's a gross kludge. The principle behind the minibuffer is that the current edit is suspended, and the current window is switched to a minibuffer window, and (more or less) normal editing happens in that mini-window until the user terminates it. This clashes with the concept of incremental searching, where point stays in the target window at all times, guided by a sequence of commands, there being no recursive edit. > There exists the ctrlf package on MELPA which also uses the minibuffer, > but it feels hardly justified to install an extra package only to get a > minibuffer-controlled search mode. I also don't want to replace such a > tightly integrated component like Isearch with an external package. If a > minibuffer mode can be added to Isearch with small effort and in a > reasonably clean way, why not do that? See above. It would be anything but clean, given the clash between the way the minibuffer works and the way incremental search works. Augusto's original patch was ~500 lines long, which scarcely suggests "reasonably clean". You seem to be asking for an Emacs internal mechanism (the minnibuffer) to be used rather than for particular user visible effects to be seen. Why not concentrate on the latter, so that we can evaluate such suggestions and incorporate them into the current way isearch is implemented? I am worried that these suggestions for using the minibuffer will get implemented, and searching in Emacs will move from the delightfully lightweight feature we have at the moment to something awkward and sluggish, like most other programs' searching is. > Daniel -- Alan Mackenzie (Nuremberg, Germany).
On 5/13/21 5:24 PM, Alan Mackenzie wrote: >> The echo area/minibuffer distinction comes up from time to time in >> discussions with new users. I know that I had been confused for a while >> with the Isearch behavior. The Isearch use of the echo area is >> unexpected. Users expect to enter a search string into a separate input >> form as is common in many other programs. In Emacs this input form is >> the minibuffer. > > That's a rather misleading way of portraying it. Users used to other > programs tend not to be familiar with incremental search, where point is > not in "a separate input form" but in the buffer they're searching > through. There is no "separate input form". I deliberately took the perspective of a new user here and I am convinced that the current behavior is problematic. Incremental search is also present in other programs, where you enter something and "the buffer" updates accordingly. The only difference here is that the cursor stays in the buffer where the search happens. But the location of the actual cursor is not that relevant, it is a technical detail. There are also packages emulating and showing multiple cursors using overlays, e.g., multiple-cursor.el. > Besides, currently isearch can be used in the mini-window, searching > through a minibuffer. If we are not to lose this feature, things will > get complicated and messy. I think it is justified to lose this functionality in the minibuffer-controlled Isearch mode. I never use the Isearch to search or jump in the minibuffer. On the other hand I would like to edit the search string using the normal editing commands which are available in the `fundamental-mode`. >> I would welcome the changes by Augusto. The minibuffer-controlled >> Isearch makes entering the search string more robust with regards to >> various editing commands as mentioned before by Kévin Le Gouguec. > > But it's a gross kludge. The principle behind the minibuffer is that > the current edit is suspended, and the current window is switched to a > minibuffer window, and (more or less) normal editing happens in that > mini-window until the user terminates it. This clashes with the concept > of incremental searching, where point stays in the target window at all > times, guided by a sequence of commands, there being no recursive edit. I am not familiar with the details of the Isearch implementation, but I don't see why it has to be a kludge in principle. If I would start a new search package, I would certainly use the minibuffer in combination with a `post-command-hook` (or an `after-change-function`) to update the buffer incrementally with the search results. It is not difficult to do that as one can see in the ctrlf.el package. Stefan Monnier also stated something along these lines: "I don't know what impacts it might have on the UI, but I've often wished (from an implementation point of view) that Isearch used an actual plain old minibuffer rather than mimicking one..." Therefore I think the characterization of a minibuffer-controlled search as a "kudge" is not balanced. One could as well criticize the Isearch since it does not use the minibuffer and deviates from the behavior of other Emacs commands. >> There exists the ctrlf package on MELPA which also uses the minibuffer, >> but it feels hardly justified to install an extra package only to get a >> minibuffer-controlled search mode. I also don't want to replace such a >> tightly integrated component like Isearch with an external package. If a >> minibuffer mode can be added to Isearch with small effort and in a >> reasonably clean way, why not do that? > > See above. It would be anything but clean, given the clash between the > way the minibuffer works and the way incremental search works. > Augusto's original patch was ~500 lines long, which scarcely suggests > "reasonably clean". I agree that 500 lines is long but the current version only adds ~160 lines. I am not sure at which point you consider this a clean patch. > You seem to be asking for an Emacs internal mechanism (the minnibuffer) > to be used rather than for particular user visible effects to be seen. > Why not concentrate on the latter, so that we can evaluate such > suggestions and incorporate them into the current way isearch is > implemented? I want to use the `fundamental-mode` to edit the search string with all its features. This cannot be achieved by adjusting something in the current Isearch implementation. The only way to achieve this is by using a separate buffer in a recursive editing session. There is already -edit-string` which gives a minibuffer. But then one loses all the incremental search functionality, which makes this uncomfortable to use. From what I've seen, Augusto's patch mostly adjusts this command, which limits the impact of the patch. > I am worried that these suggestions for using the minibuffer will get > implemented, and searching in Emacs will move from the delightfully > lightweight feature we have at the moment to something awkward and > sluggish, like most other programs' searching is. I did not try the current version of the patch but the last time I tried it, I quite liked the result. It didn't feel sluggish and felt natural as long as one accepts that one is typing in the minibuffer. Overall, I understand the resistance against the proposed changes. If one wants to stay in any case within the paradigm of using the echo area, there is no place for a minibuffer controlled Isearch. Nevertheless I found it quite astonishing that Augusto managed to create this relatively small patch (up to debate ;) which substitutes this central part of the Isearch interaction. Daniel
Daniel Mendler <daniel@mendler.net> writes: > > The echo area/minibuffer distinction comes up from time to time in > discussions with new users. I know that I had been confused for a while > with the Isearch behavior. The Isearch use of the echo area is > unexpected. Users expect to enter a search string into a separate input > form as is common in many other programs. In Emacs this input form is > the minibuffer. It's unexpected if you come from other applications, but I don't think it's a bad UX. Once you get used to how Isearch works, in my opinion it's much more efficient than using the minibuffer. For example, it's very common to use incremental search to navigate to a particular place in a buffer, and, once you are in the desired position, do something like C-n, C-v, or C-p to move the point further and end the search at the same time. This use case wouldn't be as convenient if incremental search used the minibuffer. Try it in the CtrlF package, for example. > > I would welcome the changes by Augusto. The minibuffer-controlled > Isearch makes entering the search string more robust with regards to > various editing commands as mentioned before by Kévin Le Gouguec. > I wouldn't like them. If you want to edit the search string, you can just 'M-e' or click on the echo area. You can also type 'C-M-d' to delete individual characters, instead of using 'backspace'. > There exists the ctrlf package on MELPA which also uses the minibuffer, > but it feels hardly justified to install an extra package only to get a > minibuffer-controlled search mode. I also don't want to replace such a > tightly integrated component like Isearch with an external package. If a > minibuffer mode can be added to Isearch with small effort and in a > reasonably clean way, why not do that? > That's the problem. Given the amount of subtle use cases currently supported by Isearch, I think that even adding a separate option to use the minibuffer would not be a simple implementation (for example, you can perform an incremental search in the minibuffer itself, etc.). To be fair, I see some good things about using the minibuffer (for example, it'd be simpler to perform certain actions, like scrolling the window, without exiting the search), but all the things that we'll lose or will change don't quite justify the new feature, IMHO.
> See above. It would be anything but clean, given the clash between the > way the minibuffer works and the way incremental search works. > Augusto's original patch was ~500 lines long, which scarcely suggests > "reasonably clean". My patch is ~200 additions, 50 deletions, and this also includes lazy highlight and lazy count for the good old `isearch-edit-string'. Alan, I am very much looking forward to your critique of my proposal, but up to now I'm having a hard time to relate what you say with what's actually done. May I suggest you to try it out? The standalone package version is very easy to test, just load the .el file and activate `isearch-mb-mode': https://github.com/astoff/isearch-mb/
On 5/13/21 6:16 PM, Daniel Martín wrote: > It's unexpected if you come from other applications, but I don't think > it's a bad UX. Once you get used to how Isearch works, in my opinion > it's much more efficient than using the minibuffer. For example, it's > very common to use incremental search to navigate to a particular place > in a buffer, and, once you are in the desired position, do something > like C-n, C-v, or C-p to move the point further and end the search at > the same time. This use case wouldn't be as convenient if incremental > search used the minibuffer. Try it in the CtrlF package, for example. Yes, of course. But this is where the preferences may differ. Some people prefer to navigate the search string, others may prefer to navigate the buffer and quit the transient Isearch keymap in that case. The patch by Augusto does not remove the current Isearch mode. The default would stay as is. >> There exists the ctrlf package on MELPA which also uses the minibuffer, >> but it feels hardly justified to install an extra package only to get a >> minibuffer-controlled search mode. I also don't want to replace such a >> tightly integrated component like Isearch with an external package. If a >> minibuffer mode can be added to Isearch with small effort and in a >> reasonably clean way, why not do that? > > That's the problem. Given the amount of subtle use cases currently > supported by Isearch, I think that even adding a separate option to use > the minibuffer would not be a simple implementation (for example, you > can perform an incremental search in the minibuffer itself, etc.). The incremental search in the minibuffer is a feature I use rarely. It is okay if this feature is not available if the minibuffer is used itself to control the search. This is not up to me to tell, it seemed the patch by Augusto providing the minibuffer-controlled search is "full featured", such that it works as one would except from Isearch, as long as one accepts that the minibuffer is used for controlling the search. What other subtle edge cases do you have in mind? > To be fair, I see some good things about using the minibuffer (for > example, it'd be simpler to perform certain actions, like scrolling the > window, without exiting the search), but all the things that we'll lose > or will change don't quite justify the new feature, IMHO. Nothing will be lost, except some simplicity. The current Isearch will stay as is. Only the command `isearch-edit-string` will be made more incremental with live updating results. From what I've seen the question is if the "loss in simplicity/purity" is justified since Isearch will get an additional interaction mode, which deviates from the currently existing interaction mode. Daniel Mendler
> Date: Thu, 13 May 2021 15:24:23 +0000 > From: Alan Mackenzie <acm@muc.de> > Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>, > "monnier@iro.umontreal.ca" <monnier@iro.umontreal.ca>, > "kevin.legouguec@gmail.com" <kevin.legouguec@gmail.com>, > Eli Zaretskii <eliz@gnu.org>, "arstoffel@gmail.com" <arstoffel@gmail.com>, > Drew Adams <drew.adams@oracle.com> > > > The echo area/minibuffer distinction comes up from time to time in > > discussions with new users. I know that I had been confused for a while > > with the Isearch behavior. The Isearch use of the echo area is > > unexpected. Users expect to enter a search string into a separate input > > form as is common in many other programs. In Emacs this input form is > > the minibuffer. > > That's a rather misleading way of portraying it. Users used to other > programs tend not to be familiar with incremental search, where point is > not in "a separate input form" but in the buffer they're searching > through. There is no "separate input form". That was true some years ago, but no longer is. Many other editors and browsers support incremental search nowadays, and at least some of them, mostly browsers, indeed expect you to type into a special input widget. > I am worried that these suggestions for using the minibuffer will get > implemented, and searching in Emacs will move from the delightfully > lightweight feature we have at the moment to something awkward and > sluggish, like most other programs' searching is. This alternative UI might indeed be added some day, but only as one option, and most probably not the default. So don't you worry.
It seems that this thread has been knee-jerk hijacked by those intent on pushing a proposal to base Isearch on the minibuffer. That's NOT the intention of this thread. There's another thread for that - please go there for that. This thread is about the current (longstanding) design of Isearch, which is NOT minibuffer-based. And it's also about the echo area and minibuffer (independently of any concern with Isearch). Minibuffer, echo area, and Isearch pattern share the same screen area. This thread is about helping users more easily distinguish the current state of that area. [Those insistent on a minibuffer-based Isearch have been the first to clamor about how confusing it can be, especially for newbies, that Isearch doesn't use the minibuffer but it uses the same screen area. Where are your voices on this other, very different question about trying to prevent or reduce such confusion?] And of course this feature would be _optional_. So comments like this one are irrelevant in this context: > Personally, I would not like to use such a > colorful "subtle" indication in the echo area. That user Jane or Jim might not want any help with this problem isn't a problem for anyone - they just wouldn't turn it on. This isn't about what _you_ might like as a user. It's about how we might help other users - users in general. So far, alas, that comment is the only contribution to this thread that's been (somewhat) on-topic. The rest has all been noise about why we should base Isearch on the minibuffer. And Eli has already said that if _that_ were to be offered it would anyway be optional for users. So this problem remains for Isearch as we've come to know and love it. How about some ideas for making the state of this shared screen area more clear to users? All I've suggested in that regard is that I think a visual, continuing indication, right there, _in that area_ is what's called for. (As opposed to some ephemeral message, ding, or flash.) That's my suggestion on the blue-sky whiteboard. Anyone else have a suggestion?
On 5/13/21 7:41 PM, Drew Adams wrote: > It seems that this thread has been knee-jerk > hijacked by those intent on pushing a proposal to > base Isearch on the minibuffer. > > That's NOT the intention of this thread. > There's another thread for that - please go there > for that. > > This thread is about the current (longstanding) > design of Isearch, which is NOT minibuffer-based. > > And it's also about the echo area and minibuffer > (independently of any concern with Isearch). Of course, my intention was to hijack "your" thread. Just to make it clear - my mail is related to your colorful echo/minibuffer proposal as follows: If Isearch would not use the echo area as it currently does, there would not even exist a need for an indicator to make anything more clear. But please tell me about the different indication modes you have implemented in your packages. You have a color for the minibuffer and a color if Isearch is active? Then you change color based on the recursion level. Are there indicators for other states? I have written a tiny package, which displays a "recursion indicator" in the mode line: https://github.com/minad/recursion-indicator. Currently it displays an arrow per recursion level and a special symbol if a recursive minibuffer session is active. It makes sense to extend this with more states, like Isearch. For Isearch I am using a separate indicator in the mode line: ~~~ (defvar isearch-indicator (concat (propertize "Isearch" 'face 'isearch))) (add-hook 'isearch-mode-hook (lambda () (push isearch-indicator mode-line-misc-info))) (add-hook 'isearch-mode-end-hook (lambda () (setq mode-line-misc-info (delq isearch-indicator mode-line-misc-info)))) ~~~ Daniel
> > This thread is about the current (longstanding) > > design of Isearch, which is NOT minibuffer-based. > > > > And it's also about the echo area and minibuffer > > (independently of any concern with Isearch). > > Of course, my intention was to hijack "your" thread. No, of course not. But the fact is that there was a flood of immediate responses that had nothing to do with the question this thread posed. Those contributions are welcome elsewhere. > Just to make it clear - my mail is related to your colorful > echo/minibuffer proposal as follows: If Isearch would not use the echo > area as it currently does, there would not even exist a need for an > indicator to make anything more clear. Isearch does use the echo area. That's the point. There's a separate thread about a proposal to not have it do so, as a user choice. But given that it does, and it will (at least as a user choice), any ideas? And no, there's still the same need to distinguish the double use of the same area for echo/output and minibuffer/input. Users have been at least as confused about those two sharing the same area as they have been about Isearch sharing it. We have some hacks (`minibuffer-message' for example) that try to finesse that problem. The problem exists independently of Isearch. > But please tell me about the different indication modes you have > implemented in your packages. You have a color for the minibuffer and a > color if Isearch is active? Then you change color based on the > recursion level. Are there indicators for other states? I described what I do, and I mentioned that it's used with a standalone minibuffer frame. I mentioned the possibility of changing the background in some way only as one way to indicate state change in the area itself; that's all. But what I do or don't do is irrelevant. I posed an open question: how might we make more clear to users which state that area is in, to help them? That question is what's raised in this thread. Ideas? > I have written a tiny package, which displays a > "recursion indicator" in the mode line... Great! Welcome. > Currently it displays an arrow per recursion level and a > special symbol if a recursive minibuffer session is active. I mentioned what I have that helps wrt recursive edit levels (library rec-edit.el) - there's no need to repeat that description. And I mentioned what I use to distinguish recursive minibuffer levels - with a standalone minibuffer frame. I suggested that Emacs might do something similar in that screen area somehow (without a standalone frame). I specifically asked for other suggestions. I'm not aware that the problem has been posed or considered directly before. > It makes sense to extend this with more states, like Isearch. > For Isearch I am using a separate indicator in the mode line: > ... That's relevant to this discussion. I gave some reasons why I think it's better to put an indication in the area itself, rather than the mode-line. But your suggestion is appropriate. We of course already have an Isearch indicator in the mode-line. But it's relatively simple (just a minor-mode lighter). For the particular _state_ of Isearch (not just the fact that Isearch is in progress, which I think is better shown somehow in the area itself), and FWIW, I change the mode-line lighter and parts of the prompt in various ways to show that too: * Case-sensitivity is indicated by the lighter changing between all uppercase (insensitive) and capitalized (sensitive). For non-regexp search that's `ISEARCH' versus `Isearch'. * Whether search is literal or regexp is also indicated with the lighter. `R*SEARCH' versus `R*search', for regexp search (instead of `ISEARCH' versus `Isearch'). (`R*' to suggest regexp by `*'. Only 1 char more.) * Wraparound is indicated by the lighter changing face: faces `isearchp-wrapped' and `isearchp-overwrapped'. By default the wrapped face just adds a blue overline, and the overwrapped face uses a red overline and underline, the latter being wavy. (The same faces are used in the prompt.) * Multi-search is indicated by face `isearchp-multi' in the prompt. (Different pieces of the search prompt get different faces. E.g. `failing', `pending', `over', `wrapped', `regexp', `multi'.) None of those mode-line indications is super prominent. They're more there as a reminder, if you bother to look at the mode-line to see the state.
> For Isearch I am using a separate indicator in the mode line:
>
> ~~~
> (defvar isearch-indicator
> (concat (propertize "Isearch" 'face 'isearch)))
> (add-hook 'isearch-mode-hook
> (lambda ()
> (push isearch-indicator mode-line-misc-info)))
> (add-hook 'isearch-mode-end-hook
> (lambda ()
> (setq mode-line-misc-info
> (delq isearch-indicator mode-line-misc-info))))
> ~~~
This displays two isearch indicators. Wouldn't it be simpler to modify
the existing indicator:
#+begin_src emacs-lisp
(add-hook 'isearch-mode-hook
(lambda ()
(put 'isearch-mode 'risky-local-variable t)
(setq isearch-mode (propertize " Isearch" 'face 'isearch))))
#+end_src
Drew, This is just an idea. I am prototyping it but do not have a fully working implementation yet. I use a separate minibuffer frame. The idea is to have a one pixel frame inner border. The border changes from matching the background to some contrasting color when the minibuffer is active. I am not sure what the analog to the inner border should be for the non-separate minibuffer frame scenario. /john
> Drew, > > This is just an idea. I am prototyping it but do not > have a fully working implementation yet. > > I use a separate minibuffer frame. The idea is to > have a one pixel frame inner border. The border > changes from matching the background to some > contrasting color when the minibuffer is active. > > I am not sure what the analog to the inner border > should be for the non-separate minibuffer frame > scenario. Sounds good. And that should be useful also for distinguishing Isearch. But it would be hard to use it to show different recursive-edit levels. One pixel is not much, when it comes to feeling/noticing a difference. But it's worth experimenting. As for trying to apply something like that to an ordinary minibuffer window (not in a separate frame): There are frame parameters with "border" in their name. And there is a `tool-bar-border' variable. But I don't think there is anything concerning windows with "border" in the name. On the other hand, windows have dividers: https://www.gnu.org/software/emacs/manual/html_node/elisp/Window-Dividers.html But it looks like they only apply to the window above or to the left of a given window. For the minibuffer window it sounds like you'd have to apply it to the window above. Doesn't sound too easy. Maybe someone else has an idea about this.
> I use a separate minibuffer frame. The idea is to > have a one pixel frame inner border. The border > changes from matching the background to some > contrasting color when the minibuffer is active. > > I am not sure what the analog to the inner border > should be for the non-separate minibuffer frame > scenario. There is none. The best solution I can think of is to tune the minibuffer window's background. martin
> > I use a separate minibuffer frame. The idea is to
> > have a one pixel frame inner border. The border
> > changes from matching the background to some
> > contrasting color when the minibuffer is active.
> >
> > I am not sure what the analog to the inner border
> > should be for the non-separate minibuffer frame
> > scenario.
>
> There is none. The best solution I can think of
> is to tune the minibuffer window's background.
That was my guess also. But it will be interesting
to see if others come up with some interesting ideas.