* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text @ 2011-11-06 14:22 Dani Moncayo 2011-11-06 14:37 ` Juri Linkov 0 siblings, 1 reply; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 14:22 UTC (permalink / raw) To: 9972 Hi, Try this from "emacs -Q": 1. Type "C-x C-f". 2. Type "C-s" (or "C-r"). In step #2, the minibuffer prompt changes from "Find file" to "I-search", but the buffer's default directory is not cleared. Instead, it becomes read-only like the prompt text, so that I have to type the Isearch input after it. This is quite confusing. The minibuffer should be cleared, like "M-s" and "M-r" commands do. In GNU Emacs 24.0.90.1 (i386-mingw-nt6.1.7601) of 2011-10-27 on DANI-PC Windowing system distributor `Microsoft Corp.', version 6.1.7601 configured using `configure --with-gcc (4.5)' -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 14:22 bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text Dani Moncayo @ 2011-11-06 14:37 ` Juri Linkov 2011-11-06 14:47 ` Dani Moncayo 0 siblings, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-11-06 14:37 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9972 > Try this from "emacs -Q": > 1. Type "C-x C-f". > 2. Type "C-s" (or "C-r"). > > In step #2, the minibuffer prompt changes from "Find file" to > "I-search", but the buffer's default directory is not cleared. > Instead, it becomes read-only like the prompt text, so that I have to > type the Isearch input after it. > > This is quite confusing. The minibuffer should be cleared, like "M-s" > and "M-r" commands do. ??? This is the essential behavior of Isearch, so you can search in existing text. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 14:37 ` Juri Linkov @ 2011-11-06 14:47 ` Dani Moncayo 2011-11-06 15:10 ` Juri Linkov 0 siblings, 1 reply; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 14:47 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 > ??? This is the essential behavior of Isearch, so you can search in > existing text. ??? I don't understand you, and I guess you've not understood me. Please, try the recipe, and compare the behavior of C-s inside the minibuffer wrt the behavior of M-s. Isearch should be activated always with a clear prompt "I-search: ", not with garbage "I-search: blablabla". -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 14:47 ` Dani Moncayo @ 2011-11-06 15:10 ` Juri Linkov 2011-11-06 15:57 ` Dani Moncayo 0 siblings, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-11-06 15:10 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9972 > Isearch should be activated always with a clear prompt "I-search: ", > not with garbage "I-search: blablabla". It seems you are confused that blablabla is not garbage, but text that you can search, i.e. try to type `C-r bla'. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 15:10 ` Juri Linkov @ 2011-11-06 15:57 ` Dani Moncayo 2011-11-06 16:04 ` Dani Moncayo 2011-11-06 16:16 ` Juri Linkov 0 siblings, 2 replies; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 15:57 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 Severity: wishlist stop >> Isearch should be activated always with a clear prompt "I-search: ", >> not with garbage "I-search: blablabla". > > It seems you are confused that blablabla is not garbage, > but text that you can search, i.e. try to type `C-r bla'. Ok, I thought that "C-s", when invoked from the minibuffer, was intended to search _only_ through the minibuffer history (like "M-s"/"M-r" do), not also in the current minibuffer text. I should have read info node "(emacs)Isearch Minibuffer" before submitting this bug report, sorry. Now that I understand it, I'd like this bug report to become a feature request: IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in the current minibuffer text, because it is usually small enough not to need that (how often do you use that feature?). I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r: * Focus exclusively in the minibuffer history. * Have a minibuffer-specific prompt ("Next/Previous element matching [regexp]: ") so that it is clear what's going on. * Obviously, clear the minibuffer's previous input. -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 15:57 ` Dani Moncayo @ 2011-11-06 16:04 ` Dani Moncayo 2011-11-06 16:16 ` Juri Linkov 1 sibling, 0 replies; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 16:04 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 > I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r: > * Focus exclusively in the minibuffer history. > * Have a minibuffer-specific prompt ("Next/Previous element matching > [regexp]: ") so that it is clear what's going on. > * Obviously, clear the minibuffer's previous input. ^^^^^^^^ I meant "current input", sorry. I.e. show the new prompt followed by nothing but the cursor. -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 15:57 ` Dani Moncayo 2011-11-06 16:04 ` Dani Moncayo @ 2011-11-06 16:16 ` Juri Linkov 2011-11-06 16:37 ` Dani Moncayo 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-11-06 16:16 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9972 > IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in > the current minibuffer text, because it is usually small enough not to > need that (how often do you use that feature?). I use this feature all the time! > I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r: > * Focus exclusively in the minibuffer history. > * Have a minibuffer-specific prompt ("Next/Previous element matching > [regexp]: ") so that it is clear what's going on. > * Obviously, clear the minibuffer's current input. If you like M-s and M-r, then just use them. They are like non-incremental versions `M-x search-forward RET' and `M-x search-backward RET'. But C-s should work like Isearch, and not clear text before it starts to search in it. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 16:16 ` Juri Linkov @ 2011-11-06 16:37 ` Dani Moncayo 2011-11-06 17:01 ` Juri Linkov 2011-11-06 17:17 ` Drew Adams 0 siblings, 2 replies; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 16:37 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 On Sun, Nov 6, 2011 at 17:16, Juri Linkov <juri@jurta.org> wrote: >> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in >> the current minibuffer text, because it is usually small enough not to >> need that (how often do you use that feature?). > > I use this feature all the time! For searching in the _current_ minibuffer text? How long are such text? >> I'd like these commands (C-s, C-r, C-M-s, C-M-r) to be similar to M-s and M-r: >> * Focus exclusively in the minibuffer history. >> * Have a minibuffer-specific prompt ("Next/Previous element matching >> [regexp]: ") so that it is clear what's going on. >> * Obviously, clear the minibuffer's current input. > > If you like M-s and M-r, then just use them. They are like non-incremental > versions `M-x search-forward RET' and `M-x search-backward RET'. I can use them, of course, but as you've said, they are not incremental. Precisely, as I pointed out, I'd like to adjust C-M-s to be the incremental version of M-s. > But C-s should work like Isearch, and not clear text before it starts to > search in it. Well, think of the advantages and drawbacks. IMHO, my proposal would make the Isearch commands (in the minibuffer): * More useful: what you want is to go straight to the history. * Clearer: The prompt states clearly that you are searching the in history, and nowhere else. * Consistent with M-s and M-r. -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 16:37 ` Dani Moncayo @ 2011-11-06 17:01 ` Juri Linkov 2011-11-06 17:42 ` Dani Moncayo 2011-11-06 17:17 ` Drew Adams 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-11-06 17:01 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9972 >>> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in >>> the current minibuffer text, because it is usually small enough not to >>> need that (how often do you use that feature?). >> >> I use this feature all the time! > > For searching in the _current_ minibuffer text? How long are such text? It doesn't matter how long it is. Just imagine the minibuffer search as continuously searching backward in a buffer with lines: history3 history2 history1 history0 where "history0" is initial text in the minibuffer. What you propose is to delete the line "history0" before running Isearch. This makes no sense at all. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 17:01 ` Juri Linkov @ 2011-11-06 17:42 ` Dani Moncayo 2011-11-06 17:53 ` Dani Moncayo 2011-11-06 18:01 ` Drew Adams 0 siblings, 2 replies; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 17:42 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 >>>> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) look up also in >>>> the current minibuffer text, because it is usually small enough not to >>>> need that (how often do you use that feature?). >>> >>> I use this feature all the time! >> >> For searching in the _current_ minibuffer text? How long are such text? > > It doesn't matter how long it is. > > Just imagine the minibuffer search as continuously searching backward > in a buffer with lines: > > history3 > history2 > history1 > history0 > > where "history0" is initial text in the minibuffer. > > What you propose is to delete the line "history0" before running Isearch. > This makes no sense at all. Like you (and Drew, and I guess everyone in this list), I like consistency and generality. Actually, what I don't like in the current behavior of C-s (and the other 3) when invoked from the minibuffer is the fact that the current minibuffer text remains there after hitting C-s (like if I were typed it, but even being read-only!). That scenario is not like users are used to when the type `C-s'. They expect to see a clean minibuffer prompt "I-search: ", with the cursor after it. So, what about making the Isearch commands start that way, but considering the current minibuffer text (the one present before C-s was invoked) as the first entry for the search, as you pointed out? -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 17:42 ` Dani Moncayo @ 2011-11-06 17:53 ` Dani Moncayo 2011-11-06 18:11 ` Drew Adams 2011-11-06 18:20 ` Juri Linkov 2011-11-06 18:01 ` Drew Adams 1 sibling, 2 replies; 18+ messages in thread From: Dani Moncayo @ 2011-11-06 17:53 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972-done > Like you (and Drew, and I guess everyone in this list), I like > consistency and generality. > > Actually, what I don't like in the current behavior of C-s (and the > other 3) when invoked from the minibuffer is the fact that the current > minibuffer text remains there after hitting C-s (like if I were typed > it, but even being read-only!). That scenario is not like users are > used to when the type `C-s'. They expect to see a clean minibuffer > prompt "I-search: ", with the cursor after it. > > So, what about making the Isearch commands start that way, but > considering the current minibuffer text (the one present before C-s > was invoked) as the first entry for the search, as you pointed out? Forget about this. I now realize what you and Drew meant, and I agree with you. I'm closing this bug report, and sorry for wasting your time. -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 17:53 ` Dani Moncayo @ 2011-11-06 18:11 ` Drew Adams 2011-11-06 18:20 ` Juri Linkov 1 sibling, 0 replies; 18+ messages in thread From: Drew Adams @ 2011-11-06 18:11 UTC (permalink / raw) To: 'Dani Moncayo', 'Juri Linkov'; +Cc: 9972 > Forget about this. I now realize what you and Drew meant, > and I agree with you. > > I'm closing this bug report, and sorry for wasting your time. Don't be sorry. I agree that it might not be obvious to users what is going on here, because of the fact that the minibuffer is doing double duty in this case. The Isearch dialog takes place in the minibuffer, AND in this case it is the minibuffer text that is being searched. That can be confusing. We should perhaps think of a (simple) way to make it more clear to users what's going on. With library mb-depth.el, when there is a recursive minibuffer we make that clear by prepending a recursion-level indicator (e.g. highlighted `[2]'). Perhaps something similar could be done to help indicate what's going on with Isearch in the minibuffer? With this clarification about the problem, perhaps this bug should be turned into a wishlist item rather than closed? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 17:53 ` Dani Moncayo 2011-11-06 18:11 ` Drew Adams @ 2011-11-06 18:20 ` Juri Linkov 2011-11-06 19:07 ` Andreas Schwab 1 sibling, 1 reply; 18+ messages in thread From: Juri Linkov @ 2011-11-06 18:20 UTC (permalink / raw) To: Dani Moncayo; +Cc: 9972 > Forget about this. I now realize what you and Drew meant, > and I agree with you. > > I'm closing this bug report, and sorry for wasting your time. If you have not already seen it, I suggest you try to use C-r in the Bash shell. It works exactly like Isearch in the minibuffer in Emacs. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 18:20 ` Juri Linkov @ 2011-11-06 19:07 ` Andreas Schwab 2011-11-09 15:27 ` Dani Moncayo 0 siblings, 1 reply; 18+ messages in thread From: Andreas Schwab @ 2011-11-06 19:07 UTC (permalink / raw) To: Juri Linkov; +Cc: 9972 Juri Linkov <juri@jurta.org> writes: > If you have not already seen it, I suggest you try to use C-r in the > Bash shell. It works exactly like Isearch in the minibuffer in Emacs. There's one difference in detail though: in readline the text to search is always displayed inside the prompt. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 19:07 ` Andreas Schwab @ 2011-11-09 15:27 ` Dani Moncayo 2011-11-09 16:17 ` Juri Linkov 0 siblings, 1 reply; 18+ messages in thread From: Dani Moncayo @ 2011-11-09 15:27 UTC (permalink / raw) To: Andreas Schwab, Drew Adams, Juri Linkov; +Cc: 9972 BTW, if the minibuffer and the echo area were each in its own window, Isearch could work in the minibuffer *exactly* like it does in any other buffer, i.e.: * Using the echo area to show the Isearch prompt and current search string. * Using the (mini)buffer to show (and navigate through) the matches, without altering its current prompt. Therefore, the fact that the minibuffer and the echo area share the same window is unfortunate in this case. -- Dani Moncayo ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-09 15:27 ` Dani Moncayo @ 2011-11-09 16:17 ` Juri Linkov 0 siblings, 0 replies; 18+ messages in thread From: Juri Linkov @ 2011-11-09 16:17 UTC (permalink / raw) To: Dani Moncayo; +Cc: Andreas Schwab, 9972 > BTW, if the minibuffer and the echo area were each in its own window, > Isearch could work in the minibuffer *exactly* like it does in any > other buffer, i.e.: > * Using the echo area to show the Isearch prompt and current search string. > * Using the (mini)buffer to show (and navigate through) the matches, > without altering its current prompt. > > Therefore, the fact that the minibuffer and the echo area share the > same window is unfortunate in this case. Exactly. There were several discussions about related problems for other similar cases, such as http://thread.gmane.org/gmane.emacs.devel/107802 ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 17:42 ` Dani Moncayo 2011-11-06 17:53 ` Dani Moncayo @ 2011-11-06 18:01 ` Drew Adams 1 sibling, 0 replies; 18+ messages in thread From: Drew Adams @ 2011-11-06 18:01 UTC (permalink / raw) To: 'Dani Moncayo', 'Juri Linkov'; +Cc: 9972 > Actually, what I don't like in the current behavior of C-s (and the > other 3) when invoked from the minibuffer is the fact that the current > minibuffer text remains there after hitting C-s (like if I were typed > it, but even being read-only!). Dunno what you mean about the text being read-only. The reason the minibuffer text remains there is that it is the text to be searched. It is not there as the current search string (or search "entry" as you have referred to it). It is there as the text to be searched. Think of the minibuffer as an ordinary buffer with some text in it. The text that is in the minibuffer is text that you typed. Or it is text that you retrieved from a history cycle or search. Or it is text that you retrieved by cycling among the current completion candidates. However the current minibuffer text got there, it is the text that gets searched by C-s/C-r/C-M-s/C-M-r. > That scenario is not like users are used to when the > type `C-s'. Yes it is. The text you see is _not_ the search string. It is the text to be searched. > They expect to see a clean minibuffer > prompt "I-search: ", with the cursor after it. I agree that things can be a bit confusing because the minibuffer is used for both the Isearch prompt and as the buffer to be searched. Perhaps you or Juri has a suggestion how to make this clearer. But your idea of emptying the minibuffer doesn't fly because it is precisely the minibuffer text that is to be searched. > So, what about making the Isearch commands start that way, but > considering the current minibuffer text (the one present before C-s > was invoked) as the first entry for the search, as you pointed out? The minibuffer content (text) is not an Isearch "entry". It is the text to be searched. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text 2011-11-06 16:37 ` Dani Moncayo 2011-11-06 17:01 ` Juri Linkov @ 2011-11-06 17:17 ` Drew Adams 1 sibling, 0 replies; 18+ messages in thread From: Drew Adams @ 2011-11-06 17:17 UTC (permalink / raw) To: 'Dani Moncayo', 'Juri Linkov'; +Cc: 9972 > >> IMO, It isn't worth making C-s (and C-r, C-M-s, C-M-r) > >> look up also in the current minibuffer text, because > >> it is usually small enough not to need that (how often > >> do you use that feature?). > > > > I use this feature all the time! > > For searching in the _current_ minibuffer text? How long are > such text? 1. Yes, for searching the _current_ minibuffer text. That's what C-s/C-r are for: searching the current buffer. 2. And yes, minibuffer text can be large - as large as you like. The fact that it often is not large with vanilla emacs (-Q) means only that vanilla Emacs does not offer what is needed to really take advantage of large input. It even still binds `SPC' and `?' to completion (except for file names) and help! Vanilla Emacs unnecessarily puts obstacles in the way of editing large portions of text in the minibuffer. That will change (slowly) with time, I have confidence. It took decades to get Emacs Dev to finally allow `SPC' to be self-inserting for file-name input. 3. And if you retrieve a previous minibuffer input, or if you cycle current candidates into the minibuffer, and you want to edit that input, then yes, Isearch (even regexp Isearch) can be very useful. And the larger the previous input or current candidate, the more useful Isearch becomes. FWIW, in Icicles it is not unusual to have large, multi-line candidates in the minibuffer. This includes region text, function definitions, search contexts - what have you. 4. The minibuffer is an _editing_ buffer, among other things. General editing commands, including Isearch, should be available there. 5. If you want a history-search command, then use M-s/M-r. If those do not do what you want, then propose additional *history*-search commands and corresponding keys. But please do not propose to change what C-s/C-r do. What they do is useful, and they are the standard keys for what they do. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-11-09 16:17 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-11-06 14:22 bug#9972: 24.0.90; "C-s/C-r" from the minibuffer don't clear the current text Dani Moncayo 2011-11-06 14:37 ` Juri Linkov 2011-11-06 14:47 ` Dani Moncayo 2011-11-06 15:10 ` Juri Linkov 2011-11-06 15:57 ` Dani Moncayo 2011-11-06 16:04 ` Dani Moncayo 2011-11-06 16:16 ` Juri Linkov 2011-11-06 16:37 ` Dani Moncayo 2011-11-06 17:01 ` Juri Linkov 2011-11-06 17:42 ` Dani Moncayo 2011-11-06 17:53 ` Dani Moncayo 2011-11-06 18:11 ` Drew Adams 2011-11-06 18:20 ` Juri Linkov 2011-11-06 19:07 ` Andreas Schwab 2011-11-09 15:27 ` Dani Moncayo 2011-11-09 16:17 ` Juri Linkov 2011-11-06 18:01 ` Drew Adams 2011-11-06 17:17 ` Drew Adams
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).