* bug#8861: 24.0.50; Isearch: Repeating the last search @ 2011-06-14 12:32 Dani Moncayo 2011-06-14 13:11 ` Drew Adams 0 siblings, 1 reply; 10+ messages in thread From: Dani Moncayo @ 2011-06-14 12:32 UTC (permalink / raw) To: 8861 [-- Attachment #1: Type: text/plain, Size: 907 bytes --] Starting from emacs -Q: 1. Go to the beginning of the *scratch* buffer (M-<). 2. Search for "filee" (C-s filee) and type <enter> to accept the current cursor position. 3. Repeat the last search (C-s C-s). After step #3, the minibuffer shows the entire seach string "filee" as unmatched, but the first 4 characters *do* have matching words after the cursor position. So only the last "e" should be displayed as unmatched. IOW, I should get the same result with (C-s C-s) as with (C-s filee) (i.e. retyping the search string). A picture is worth a thousand words. See attached screenshots: * "img-wrong.png": Observed result. * "img-right.png": Expected result. In GNU Emacs 24.0.50.1 (i386-mingw-nt5.1.2600) of 2011-06-07 on 3249CTO Windowing system distributor `Microsoft Corp.', version 5.1.2600 configured using `configure --with-gcc (4.5) --no-opt --cflags -Ic:/build/include' -- Dani Moncayo [-- Attachment #2: img-wrong.png --] [-- Type: image/png, Size: 17708 bytes --] [-- Attachment #3: img-right.png --] [-- Type: image/png, Size: 17820 bytes --] ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 12:32 bug#8861: 24.0.50; Isearch: Repeating the last search Dani Moncayo @ 2011-06-14 13:11 ` Drew Adams 2011-06-14 13:52 ` Dani Moncayo 0 siblings, 1 reply; 10+ messages in thread From: Drew Adams @ 2011-06-14 13:11 UTC (permalink / raw) To: 'Dani Moncayo', 8861 Juri or someone else might give a better or different explanation, but here's mine, FWIW. This behavior is not very clear or intuitive, but (a) there is not much that can be done about it, and (b) it can be argued that it is not really a bug. The highlighting could perhaps be turned off completely in this case, since in does not (cannot) correctly indicate only the part of the search string that is incorrect. (But turning it off completely gives the opposite message that there is no search failure.) The highlighting as it appears is at least consistent with the rest of Isearch behavior in this context. The search string was not sought incrementally; that is, no incremental search built it up. So there is no notion of the increment of it that failed. If you hit `DEL' (Backspace) at that point, it is not just the final `e' that is removed, but all of the search string. IOW, you cannot return to a successful search prefix and return in the buffer to a successful search hit position. In this context, the entire search string _is_ the increment: it is sought as a whole. There is no previous successful state to return to, and that principle extends to the success/failure match highlighting. I know and agree that this might not be what a user expects, especially since this highlighting is something new, but it is consistent. The highlighting here, like all the rest of the searching, is not incremental at that point. The search string as a whole is tested and either succeeds (as a whole) or fails (as a whole). The highlighting reflects that. And it can only reflect that. Perhaps we could remove it, but I'm not sure that would be better. In that case the "bug" or unituitive behavior would be that search fails but the search string is not highlighted at all to show failure. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 13:11 ` Drew Adams @ 2011-06-14 13:52 ` Dani Moncayo 2011-06-14 15:20 ` Drew Adams 2011-06-14 17:33 ` Juri Linkov 0 siblings, 2 replies; 10+ messages in thread From: Dani Moncayo @ 2011-06-14 13:52 UTC (permalink / raw) To: Drew Adams; +Cc: 8861 Hi Drew, > The highlighting could perhaps be turned off completely in this case, since in > does not (cannot) correctly indicate only the part of the search string that is > incorrect. (But turning it off completely gives the opposite message that there > is no search failure.) This doesn't make much sense to me. I expect that, whenever Isearch is active, the search string will always be highlighted to reflect the matched and unmatched parts at every moment, regardless of how that string has been introduced (char by char, by copy&paste, by "C-s C-s", ...) > The highlighting as it appears is at least consistent with the rest of Isearch > behavior in this context. The search string was not sought incrementally; that > is, no incremental search built it up. So there is no notion of the increment > of it that failed. If you hit `DEL' (Backspace) at that point, it is not just > the final `e' that is removed, but all of the search string. I understand you, but I really disagree. As I've said before, I'd expect a consistent behavior with independence of the way the search string has been built. I don't see the need to have that double treatment. IMHO, it is both more consistent and useful to have a single behavior. In the example showed in the OP, if the search string (and the cursor position) was updated as I suggested, I would have had a more complete/precise information, since part of my search string did actually have matches after the point, and that is what I wanted to know. In short: I find my proposed behavior both (a) Simpler (more consistent) and (b) More informative (useful) that the current one. (Just my opinion) -- Dani Moncayo ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 13:52 ` Dani Moncayo @ 2011-06-14 15:20 ` Drew Adams 2011-06-14 17:33 ` Juri Linkov 1 sibling, 0 replies; 10+ messages in thread From: Drew Adams @ 2011-06-14 15:20 UTC (permalink / raw) To: 'Dani Moncayo'; +Cc: 8861 > > The highlighting could perhaps be turned off completely in > > this case, since in does not (cannot) correctly indicate > > only the part of the search string that is incorrect. (But > > turning it off completely gives the opposite message that > > there is no search failure.) > > This doesn't make much sense to me. I expect that, whenever Isearch > is active, the search string will always be highlighted to reflect the > matched and unmatched parts at every moment, regardless of how that > string has been introduced (char by char, by copy&paste, by "C-s C-s", > ...) I already acknowledged such expectations from users. I've had the same expectations myself. Dunno what else to say. The fact is that that is not how incremental search works - so far. Such state - and more than a single state: a history - is not saved. When you are in the middle of an incremental search, some state is saved about the last successful position etc. But once you have exited search there is no way to restore state, other than retrieving the last (or other previous) complete search string to start a new search. We could perhaps save also the last successful prefix of the last search string, as a means to at least make the highlighting reflect that state. But in any case as soon as you reuse the search string (which is complete) it is treated as a whole (e.g. hitting `DEL' deletes it all at once). And you might be reusing a past search string that was completely successful in some different context (e.g. a different buffer or narrowing). Should we record also the current buffer and its restriction as part of the search history? This quickly becomes fairly complex, with design/user intention tradeoffs left and right, I think. Anyway, I cannot really speak to such implementation matters; I'm no expert on them. I'm just giving some background explanation. Perhaps Juri L. has an idea about this he would like to share. But we have discussed the issue before. > > The highlighting as it appears is at least consistent with > > the rest of Isearch behavior in this context. The search > > string was not sought incrementally; that is, no incremental > > search built it up. So there is no notion of the increment > > of it that failed. If you hit `DEL' (Backspace) at that > > point, it is not just the final `e' that is removed, but all > > of the search string. > > I understand you, but I really disagree. As I've said before, I'd > expect a consistent behavior with independence of the way the search > string has been built. There's really nothing to disagree about here. I'm just explaining what happens. You might like Isearch to remember your entire incremental search history (interaction), but it does not do so at present, and it never has. The first question is thus whether what bothers you is just the highlighting. Are you as bothered about the fact that you cannot resume incrementally where you left off anyway, i.e., the fact that `DEL' removes not the final char but the whole search string, and there is thus no saved successful hit to return to by hitting `DEL', as you are bothered about the highlighting (which reflects that fact/behavior consistently)? > I don't see the need to have that double treatment. IMHO, it is both > more consistent and useful to have a single behavior. In the example > showed in the OP, if the search string (and the cursor position) was > updated as I suggested, I would have had a more complete/precise > information, since part of my search string did actually have matches > after the point, and that is what I wanted to know. > > In short: I find my proposed behavior both (a) Simpler (more > consistent) and (b) More informative (useful) that the current one. > > (Just my opinion) Patch welcome, I'm sure. And as I say, perhaps Juri has another idea or a better explanation of the situation. FWIW, one alternative I can imagine, to trying to save enough historical incremental behavior to provide the behavior you expect, would be to have Isearch do something like the following when you hit C-s C-s and there is a mismatch: automatically reproduce the behavior of your manually editing the search string to remove successive rightmost characters and trying to find a match, then proceeding with the longest successful prefix string. IOW, it would then reproduce what you might do manually in this case, which would be the following: 1. M-e, to edit the search string 2. DEL, to delete the rightmost char 3. C-s, to look for a match for the search string minus that char 4. If success, done. Else repeat. That is essentially what I do in the Icicles completion highlighting that this Isearch highlighting was inspired from: try to complete; remove a char; repeat until success; then highlight the part that didn't match. Actually, this is optimized using binary search (split the mismatch in half etc.), instead of proceeding just a char at a time, and the same could be done for Isearch. That would, in effect, put the previous search string in sync with the current context (e.g. buffer). I can see that as one possible approach/"solution". But in that case, Isearch would be automatically discarding all that did not match, so that suffix - and that mismatch information - would in effect be lost to you. And that info about mismatch could be helpful in some contexts. Imagine that you search for `foobar' successfully in buffer A, then want to look for it in buffer `B', where there is `foofizz' but no `foobar'. Maybe in that case you would like to see that `foobar' does not match, and not just see that Isearch transforms your C-s C-s string from `foobar' to `foo' for a successful `foo' search? Sure, you can type `bar' again, or you can yank `foobar' and then search for it, but that's a bit roundabout. If we took this approach, perhaps we should bind a key to retrieving the discarded mismatch suffix? Or provide a way to easily retrieve it a char at a time, to in effect reproduce your typing it incrementally (so you need not know or remember what the mismatch text was). Or perhaps a better approach at that point (after determining the correct mismatch position for the current context) would be to use the whole search string, but (a) highlight the correct mismatch portion, and thus (b) let you, as now, use `M-e C-k' to remove it if you want, and (c) make that the current Isearch state: reset the failure position. IOW, have Isearch automatically run through all the steps that would be needed to get to the state of an incremental search that starts with the successful prefix and proceeds incrementally to the complete (mismatched) search string, reestablishing the correct mismatch position for the current context. This is essentially what you are asking for, I think. Dunno how difficult that would be to implement. I'm guessing it's doable, but Juri or someone else might have more to say about it. The point here is really the question of what it means (what the behavior should be) to return to a previous search that failed. Or for that matter to return to a previous search that succeeded but now fails in a different context (same problem). (And that's why saving a complete previous incremental history is not really a solution to this problem.) Again, I am not saying that the current behavior is better than the one you are expecting. I am saying that what you are expecting is not implemented, and it represents a change in the traditional behavior (wrt DEL etc.). It might be doable, but it would at least represent an enhancement request. Aside from realizing such an enhancement, the highlighting could I think easily be turned off completely in this situation. That would not fix the overall problem/inconsistency, but it would prevent it from being brought to your attention so prominently. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 13:52 ` Dani Moncayo 2011-06-14 15:20 ` Drew Adams @ 2011-06-14 17:33 ` Juri Linkov 2011-06-14 18:41 ` Dani Moncayo 2022-01-27 18:02 ` Lars Ingebrigtsen 1 sibling, 2 replies; 10+ messages in thread From: Juri Linkov @ 2011-06-14 17:33 UTC (permalink / raw) To: Dani Moncayo; +Cc: 8861 > I expect that, whenever Isearch is active, the search string will > always be highlighted to reflect the matched and unmatched parts at > every moment, regardless of how that string has been introduced > (char by char, by copy&paste, by "C-s C-s", Currently it's possible to reproduce the behavior you are asking for, by copy&paste from the system clipboard into Emacs running in xterm (it pastes char by char): 1. emacs -Q -nw 2. M-< 3. C-s S-Ins When trying this, it seems it's worse than the default behavior because treating the search string char by char is useful only when you are typing it because highlighting the failed part helps to correct typos. But when you want to search for the previous search string by `C-s C-s' or by copy&paste from the clipboard/kill-ring it's more useful to treat it as a whole. For instance, often it's necessary to put a string into the search ring (`C-s string RET') and search its exact occurrence in another buffer (`C-x o C-s C-s'). It would be annoying when searching for e.g. "caterpillar" will stop at "cat" and highlight it. However, your idea is not completely useless. Currently isearch mode is interactively incremental but you propose to extend it it into non-interactively incremental (i.e. incremental even when the search string is not composed interactively). Maybe a new option/mode could do that but I think it should not be enabled by default. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 17:33 ` Juri Linkov @ 2011-06-14 18:41 ` Dani Moncayo 2011-06-15 3:11 ` Stefan Monnier 2022-01-27 18:02 ` Lars Ingebrigtsen 1 sibling, 1 reply; 10+ messages in thread From: Dani Moncayo @ 2011-06-14 18:41 UTC (permalink / raw) To: Juri Linkov; +Cc: 8861 Hi Juri, > It would be annoying when searching for e.g. "caterpillar" > will stop at "cat" and highlight it. Well, IMO, it would be TRT. Once you see that result, if you consider it useless, just dismiss it with C-g. Also, think of a situation like having "caterpillars" in the top of the search ring and then doing C-s C-s in a buffer which doesn't have it, but has "caterpillar" (singular). In that case, I would like Isearch to move the point forward to the next occurrence of the second one. Yes, it isn't a full match, but is a _useful_one_ for me. > However, your idea is not completely useless. Currently isearch mode > is interactively incremental but you propose to extend it it into > non-interactively incremental (i.e. incremental even when the search > string is not composed interactively). Maybe a new option/mode > could do that but I think it should not be enabled by default. It would be useful, IMO. Thanks. PS: Currently, my knowledge of Emacs Lips is too basic to been able to contribute anything useful. Maybe in the future. I have the intention of keep learning... :) -- Dani Moncayo ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 18:41 ` Dani Moncayo @ 2011-06-15 3:11 ` Stefan Monnier 0 siblings, 0 replies; 10+ messages in thread From: Stefan Monnier @ 2011-06-15 3:11 UTC (permalink / raw) To: Dani Moncayo; +Cc: 8861 >> It would be annoying when searching for e.g. "caterpillar" >> will stop at "cat" and highlight it. > Well, IMO, it would be TRT. Once you see that result, if you consider > it useless, just dismiss it with C-g. The fact that the whole "filee" is highlighted is not a feature (i.e. patches to change it might be accepted). I'm less sure about the idea to make it jump to the first match of "file", tho I'm not necessarily opposed to it. Oh and BTW, I'm using local patches to make DEL remove only the final char rather than the whole "filee", so I'm not opposed to changing this part of the behavior either. Stefan ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2011-06-14 17:33 ` Juri Linkov 2011-06-14 18:41 ` Dani Moncayo @ 2022-01-27 18:02 ` Lars Ingebrigtsen 2022-01-27 18:15 ` Juri Linkov 1 sibling, 1 reply; 10+ messages in thread From: Lars Ingebrigtsen @ 2022-01-27 18:02 UTC (permalink / raw) To: Juri Linkov; +Cc: 8861, Dani Moncayo Juri Linkov <juri@jurta.org> writes: > When trying this, it seems it's worse than the default behavior because > treating the search string char by char is useful only when you are > typing it because highlighting the failed part helps to correct typos. > But when you want to search for the previous search string by `C-s C-s' > or by copy&paste from the clipboard/kill-ring it's more useful > to treat it as a whole. For instance, often it's necessary to > put a string into the search ring (`C-s string RET') and search > its exact occurrence in another buffer (`C-x o C-s C-s'). > It would be annoying when searching for e.g. "caterpillar" > will stop at "cat" and highlight it. Yes, it would be pretty odd... > However, your idea is not completely useless. Currently isearch mode > is interactively incremental but you propose to extend it it into > non-interactively incremental (i.e. incremental even when the search > string is not composed interactively). Maybe a new option/mode > could do that but I think it should not be enabled by default. ... and in my opinion, I don't think such a would find much use, so I'm closing this issue as "wontfix". -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2022-01-27 18:02 ` Lars Ingebrigtsen @ 2022-01-27 18:15 ` Juri Linkov 2022-01-27 18:58 ` Lars Ingebrigtsen 0 siblings, 1 reply; 10+ messages in thread From: Juri Linkov @ 2022-01-27 18:15 UTC (permalink / raw) To: Lars Ingebrigtsen; +Cc: 8861, Dani Moncayo >> When trying this, it seems it's worse than the default behavior because >> treating the search string char by char is useful only when you are >> typing it because highlighting the failed part helps to correct typos. >> But when you want to search for the previous search string by `C-s C-s' >> or by copy&paste from the clipboard/kill-ring it's more useful >> to treat it as a whole. For instance, often it's necessary to >> put a string into the search ring (`C-s string RET') and search >> its exact occurrence in another buffer (`C-x o C-s C-s'). >> It would be annoying when searching for e.g. "caterpillar" >> will stop at "cat" and highlight it. > > Yes, it would be pretty odd... > >> However, your idea is not completely useless. Currently isearch mode >> is interactively incremental but you propose to extend it it into >> non-interactively incremental (i.e. incremental even when the search >> string is not composed interactively). Maybe a new option/mode >> could do that but I think it should not be enabled by default. > > ... and in my opinion, I don't think such a would find much use, so I'm > closing this issue as "wontfix". Please close also bug#14729 for the same reason, these two requests are about the same fuzzy oddities with no clear solution. ^ permalink raw reply [flat|nested] 10+ messages in thread
* bug#8861: 24.0.50; Isearch: Repeating the last search 2022-01-27 18:15 ` Juri Linkov @ 2022-01-27 18:58 ` Lars Ingebrigtsen 0 siblings, 0 replies; 10+ messages in thread From: Lars Ingebrigtsen @ 2022-01-27 18:58 UTC (permalink / raw) To: Juri Linkov; +Cc: 8861, Dani Moncayo Juri Linkov <juri@jurta.org> writes: > Please close also bug#14729 for the same reason, these two requests > are about the same fuzzy oddities with no clear solution. I think that one could possibly lead to improvement, though. 😀 (I mean, theoretically.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2022-01-27 18:58 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-06-14 12:32 bug#8861: 24.0.50; Isearch: Repeating the last search Dani Moncayo 2011-06-14 13:11 ` Drew Adams 2011-06-14 13:52 ` Dani Moncayo 2011-06-14 15:20 ` Drew Adams 2011-06-14 17:33 ` Juri Linkov 2011-06-14 18:41 ` Dani Moncayo 2011-06-15 3:11 ` Stefan Monnier 2022-01-27 18:02 ` Lars Ingebrigtsen 2022-01-27 18:15 ` Juri Linkov 2022-01-27 18:58 ` Lars Ingebrigtsen
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.