* Re: Interpretation of a space in regexp isearch? @ 2012-08-15 4:40 Dmitry Gutov 2012-08-15 5:27 ` Bastien 0 siblings, 1 reply; 56+ messages in thread From: Dmitry Gutov @ 2012-08-15 4:40 UTC (permalink / raw) To: cyd; +Cc: bzg, emacs-devel Chong Yidong <cyd@gnu.org> writes: > Bastien <bzg@gnu.org> writes: > >> Davis Herring <herring@lanl.gov> writes: >> >>> It's a feature, but I don't remember how to change it at the moment. >>> `search-spaces-regexp' is almost it. >> >> Yep -- it's =CC=80search-whitespace-regexp'. > > FWIW, I've long been of the opinion that this feature is exactly > backward. The `search-whitespace-regexp' whitespace matching feature > should apply to ordinary incremental search, and it should *not* apply > to regexp incremental search. I think that would make more sense, too. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 4:40 Interpretation of a space in regexp isearch? Dmitry Gutov @ 2012-08-15 5:27 ` Bastien 2012-08-15 9:11 ` Dani Moncayo 0 siblings, 1 reply; 56+ messages in thread From: Bastien @ 2012-08-15 5:27 UTC (permalink / raw) To: Dmitry Gutov; +Cc: cyd, emacs-devel Dmitry Gutov <dgutov@yandex.ru> writes: >> FWIW, I've long been of the opinion that this feature is exactly >> backward. The `search-whitespace-regexp' whitespace matching feature >> should apply to ordinary incremental search, and it should *not* apply >> to regexp incremental search. > > I think that would make more sense, too. My opinion too. -- Bastien ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 5:27 ` Bastien @ 2012-08-15 9:11 ` Dani Moncayo 2012-08-15 9:13 ` Dani Moncayo ` (3 more replies) 0 siblings, 4 replies; 56+ messages in thread From: Dani Moncayo @ 2012-08-15 9:11 UTC (permalink / raw) To: Bastien; +Cc: cyd, emacs-devel, Dmitry Gutov >>> FWIW, I've long been of the opinion that this feature is exactly >>> backward. The `search-whitespace-regexp' whitespace matching feature >>> should apply to ordinary incremental search, and it should *not* apply >>> to regexp incremental search. >> >> I think that would make more sense, too. > > My opinion too. +1 IMO, that feature is what the user usually wants in an ordinary search (regardless it's incremental or not; even if that search is part of a ordinary replace command). On the other and, in a rexexp search (or regexp search&replace) I think that the common case is the opposite: the user normally doesn't want that feature. So, what about making that feature optional for these two scenarios? ("on" by default in the regexp case and "off" by default in the normal case). -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 9:11 ` Dani Moncayo @ 2012-08-15 9:13 ` Dani Moncayo 2012-08-15 9:19 ` Dani Moncayo ` (2 subsequent siblings) 3 siblings, 0 replies; 56+ messages in thread From: Dani Moncayo @ 2012-08-15 9:13 UTC (permalink / raw) To: Bastien; +Cc: cyd, emacs-devel, Dmitry Gutov > So, what about making that feature optional for these two scenarios? > ("on" by default in the regexp case and "off" by default in the normal > case). Sorry, obviously I meant "off" for regexp and "on" for the normal search. -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 9:11 ` Dani Moncayo 2012-08-15 9:13 ` Dani Moncayo @ 2012-08-15 9:19 ` Dani Moncayo 2012-08-15 13:59 ` Drew Adams 2012-08-26 4:06 ` Chong Yidong 3 siblings, 0 replies; 56+ messages in thread From: Dani Moncayo @ 2012-08-15 9:19 UTC (permalink / raw) To: Bastien; +Cc: cyd, emacs-devel, Dmitry Gutov >>>> FWIW, I've long been of the opinion that this feature is exactly >>>> backward. The `search-whitespace-regexp' whitespace matching feature >>>> should apply to ordinary incremental search, and it should *not* apply >>>> to regexp incremental search. >>> >>> I think that would make more sense, too. >> >> My opinion too. > > +1 > > IMO, that feature is what the user usually wants in an ordinary search > (regardless it's incremental or not; even if that search is part of a > ordinary replace command). > > On the other and, in a rexexp search (or regexp search&replace) I > think that the common case is the opposite: the user normally doesn't > want that feature. > > So, what about making that feature optional for these two scenarios? > ("off" by default in the regexp case and "on" by default in the normal > case). BTW, but #10885 would be solved with this proposal. -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-15 9:11 ` Dani Moncayo 2012-08-15 9:13 ` Dani Moncayo 2012-08-15 9:19 ` Dani Moncayo @ 2012-08-15 13:59 ` Drew Adams 2012-08-15 14:31 ` Davis Herring 2012-08-15 22:53 ` Dmitry Gutov 2012-08-26 4:06 ` Chong Yidong 3 siblings, 2 replies; 56+ messages in thread From: Drew Adams @ 2012-08-15 13:59 UTC (permalink / raw) To: 'Dani Moncayo', 'Bastien' Cc: cyd, 'Dmitry Gutov', emacs-devel > >>> FWIW, I've long been of the opinion that this feature is > >>> exactly backward. The `search-whitespace-regexp' whitespace > >>> matching feature should apply to ordinary incremental search, > >>> and it should *not* apply to regexp incremental search. > >> > >> I think that would make more sense, too. > > My opinion too. > +1 > > IMO, that feature is what the user usually wants in an ordinary search > (regardless it's incremental or not; even if that search is part of a > ordinary replace command). > > On the other and, in a rexexp search (or regexp search&replace) I > think that the common case is the opposite: the user normally doesn't > want that feature. > > So, what about making that feature optional for these two scenarios? > ("on" by default in the regexp case and "off" by default in the normal > case). +0.2 We've been through this before, I think, but... By default, "magic-space" searching should be OFF for both simple and regexp search. Each SPC you type should search for a single SPC, by default. Simple. No surprise. Others have given reasons for the regexp case (+1). For the simple-search case: I do not think it is appropriate for users, especially newbies, to have to figure out and use `C-q SPC' (WTF?) to search for a single SPC char. I do agree, however, that magic-space searching can be very useful, and it should be easily available, via a toggle key, for both simple and regexp searching. The best approach is to *let users decide*: * Treat both simple and regexp search the same way. * Have a Boolean variable that controls the behavior: literal-SPC or magic-space searching. * Have a toggle key that flips the Boolean value. The new value stays in effect (including in future searches for the same session) until flipped again. (Some candidates for the key: `M-SPC', `M-s SPC'.) * The variable's default value provides literal SPC search as the default (i.e., initial) behavior - for all searches: simple & regexp. * Users can set the variable value in their init files, if they want to change the default (i.e., initial) behavior. (Personally, I would prefer that the variable be a defcustom, but I'm a heretic.) [Even without this proposal, the doc for Isearch (e.g. C-s C-h m) should mention the behavior of SPC in a regexp search - it is currently silent about this. With this proposal, it should mention the two SPC behaviors and the toggle key.] ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 13:59 ` Drew Adams @ 2012-08-15 14:31 ` Davis Herring 2012-08-15 16:43 ` Drew Adams 2012-08-15 22:53 ` Dmitry Gutov 1 sibling, 1 reply; 56+ messages in thread From: Davis Herring @ 2012-08-15 14:31 UTC (permalink / raw) To: Drew Adams Cc: 'Bastien', emacs-devel, cyd, 'Dmitry Gutov', 'Dani Moncayo' > We've been through this before, I think, but... > > By default, "magic-space" searching should be OFF for both simple and regexp > search. Each SPC you type should search for a single SPC, by default. Simple. > No surprise. Unless you filled a paragraph (perhaps via auto-fill-mode) and don't remember doing so. > Others have given reasons for the regexp case (+1). For the simple-search case: > I do not think it is appropriate for users, especially newbies, to have to > figure out and use `C-q SPC' (WTF?) to search for a single SPC char. If you're searching just for a space, the only differences will be that you stop only once at each stretch of whitespace (and that you stop at all at (sequences of) tabs, which, as common as they are, are still almost always rare compared to spaces). Why would you even care? Sure, if you're searching for "a b" you'll find "a b", but when would you search for that, caring about missing the latter, and not be using a regexp (as to find sentences with only one space separating them)? > I do agree, however, that magic-space searching can be very useful, and it > should be easily available, via a toggle key, for both simple and regexp > searching. Is "let's add an isearch toggle key" what you meant by "We've been through this before"? > * Treat both simple and regexp search the same way. In regexp search, you can choose between \s-+ and SPC -- that's why so many have said just now that this magic is appropriate for C-s and not C-M-s. > * Have a toggle key that flips the Boolean value. > The new value stays in effect (including in future > searches for the same session) until flipped again. > (Some candidates for the key: `M-SPC', `M-s SPC'.) How is M-SPC any easier than C-q? (This is an argument for having the default be "on" for this magic; otherwise you need a way to summon it for one use and C-q doesn't fit there.) As always, adding keys to isearch reduces the set you can use on exit (M-SPC is useful here). > * Users can set the variable value in their init files, if > they want to change the default (i.e., initial) behavior. Er, yes? Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-15 14:31 ` Davis Herring @ 2012-08-15 16:43 ` Drew Adams 2012-08-15 17:54 ` Davis Herring 0 siblings, 1 reply; 56+ messages in thread From: Drew Adams @ 2012-08-15 16:43 UTC (permalink / raw) To: 'Davis Herring' Cc: 'Bastien', emacs-devel, cyd, 'Dmitry Gutov', 'Dani Moncayo' > > By default, "magic-space" searching should be OFF for both > > simple and regexp search. Each SPC you type should search > > for a single SPC, by default. Simple. No surprise. > > Unless you filled a paragraph (perhaps via auto-fill-mode) and don't > remember doing so. ? Perhaps you mean filling with justification, so there can be stretches of multiple SPC chars? Or perhaps you are referring to `SPC SPC' after a period? Sorry, I don't see the problem you are hinting at. The behavior of SPC meaning to search for a single SPC char is pretty common in other editors (from TextPad to MS Word). And it has always been the default behavior for simple search in Emacs as well. How is it surprising? > If you're searching just for a space, the only differences > will be... We know what the differences are. > Why would you even care? Sure, if you're searching for > "a b" you'll find "a b", You answered your own question. > but when would you search for that, caring about missing > the latter, and not be using a regexp (as to find sentences > with only one space separating them)? You would search for that anytime you would search for it. ;-) Try searching your own message for `a b', for instance - that's `a', `SPC', `b'. Honestly, it is silly to suppose that users never or rarely want to search for a set number of SPC chars, including for just one SPC. Especially programmers. > Is "let's add an isearch toggle key" what you meant by "We've been > through this before"? No. I have a vague recollection that we have discussed before whether Isearch should search for only a single SPC when you type a SPC. I do not have a reference for you, however. > > * Treat both simple and regexp search the same way. > > In regexp search, you can choose between \s-+ and SPC -- that's why so > many have said just now that this magic is appropriate for C-s and not > C-M-s. Yes, I realize that. And yet we still have SPC being magic for regexp search, don't we? Even though it is simple enough to use \s-+, and it always has been. If people have in the past thought that SPC being magic in regexp search was handy (and yes, it can be easier to hit `SPC' than to type `\s-+', especially for multiple such in a long regexp), then their arguments still apply. And yes, "so many" clearly have thought that in the past, including Richard. The magic-space behavior for regexp search is at least as old as Emacs 20. I recognize that SPC acting "magically" can be useful whatever the search mode. Apparently you do not. * I do not see magic-space SPC as something that is useful ONLY for regexp search (the current and traditional approach). And I do not see it as useful ONLY for simple search (which you seem to be arguing). * I do not see literal-space SPC as something that is useful ONLY for regexp search (which you seem to be arguing). And I do not see it as useful ONLY for simple search (the current and traditional approach). Each SPC-search mode can be useful for both simple and regexp search, IMO. > > * Have a toggle key that flips the Boolean value. > > The new value stays in effect (including in future > > searches for the same session) until flipped again. > > (Some candidates for the key: `M-SPC', `M-s SPC'.) > > How is M-SPC any easier than C-q? No one said it was. But you are comparing apples and orangutans. C-q does not toggle the search mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an otherwise magic-space sea. > (This is an argument for having the default be "on" for this magic; It's not much of an argument, AFAICT. I don't care much whether the _default_ default is on or off. If users can set the default SPC-search mode themselves, and if they have a simple way to toggle the mode, then a discussion about what the _default_ default behavior should be amounts to much ado about nothing. > otherwise you need a way to summon it for one use and C-q > doesn't fit there.) Not sure what you mean by "one use". Do you mean one search or one occurrence in a search string that also has other occurrences of SPC? If the former, then the answer is to toggle (and then toggle again when that one-off search is over). A quick toggle is perfect for a one-off search in the other mode. If the latter, then I guess you are saying that if magic-space search is off (why talk about the _default_ here?) then in simple search it is hard to search for _both_ a contiguous stretch of whitespace and a single SPC (or a given number N of SPC chars) in the same search string. If that's what you're saying, it is a red herring, Mr Herring. That same situation exists both today and with the proposal from Yidong. That is a difficulty for simple search whether magic is off or on: One cannot easily match both a stretch of whitespace and a single SPC (as opposed to a stretch) in the same search string. It is inherent to simple search - that use case cries out for regexp search instead. As such, this has nothing to do with what the default behavior should be. But as I say, I really do not care much what the default behavior is, as long as users can set their own default behavior and toggle the behavior on the fly. > As always, adding keys to isearch reduces the set you can use on exit > (M-SPC is useful here). Blah. > > * Users can set the variable value in their init files, if > > they want to change the default (i.e., initial) behavior. > > Er, yes? Yes? Dunno what is unclear here. The point is that you and I can each start out with the behavior we want. Today, the _code_ decides in a hard-coded way that regexp search uses magic-space and simple search does not. Yidong proposes the opposite - but still hard-coding. And I guess you are agreeing with that proposal. I'm saying let the user decide. Both what the initial behavior is and on the fly. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 16:43 ` Drew Adams @ 2012-08-15 17:54 ` Davis Herring 0 siblings, 0 replies; 56+ messages in thread From: Davis Herring @ 2012-08-15 17:54 UTC (permalink / raw) To: Drew Adams Cc: 'Bastien', emacs-devel, cyd, 'Dmitry Gutov', 'Dani Moncayo' >> Unless you filled a paragraph (perhaps via auto-fill-mode) and don't >> remember doing so. > > ? > > Perhaps you mean filling with justification, so there can be stretches of > multiple SPC chars? Or perhaps you are referring to `SPC SPC' after a period? > Sorry, I don't see the problem you are hinting at. Because you typed a space between two words, but it eventually became a newline (and possibly indentation). > You would search for that anytime you would search for it. ;-) Try searching > your own message for `a b', for instance - that's `a', `SPC', `b'. > > Honestly, it is silly to suppose that users never or rarely want to search for a > set number of SPC chars, including for just one SPC. Especially programmers. What is silly is a file that contains (for a fixed ?a and ?b) so many "a b" substrings that C-s-ing through them to find your desired "a b" instance is troublesome. >> Is "let's add an isearch toggle key" what you meant by "We've been >> through this before"? > > No. I have a vague recollection that we have discussed before whether Isearch > should search for only a single SPC when you type a SPC. I do not have a > reference for you, however. The "through this before" I hinted at was "you often argue for additional toggle keys in isearch". It was a bit of a poke, nothing important. > And yet we still have SPC being magic for regexp search, don't we? Even though > it is simple enough to use \s-+, and it always has been. That's why all the +1s in this thread have been for moving the magic (by default) to the non-regexp case where this trick doesn't work. > I recognize that SPC acting "magically" can be useful whatever the search mode. > Apparently you do not. I see it as so useful in the simple case that it can merely be customizable, not "togglable". In the regexp case, it is not always useful, but it's already easy to change, so I again need no toggle key for it. Either I customize it on, and I can use C-q SPC as needed, or I customize it off, and I can use \s-+ as needed. > But you are comparing apples and orangutans. C-q does not toggle the search > mode wrt SPC; it simply gives a single SPC a literal life raft, to float in an > otherwise magic-space sea. With the default set to "more magic", C-q gets you "no magic", same as your toggle would. Your toggle would work the other way too, but as I said I don't feel the need for the other way (often enough for an isearch key). > If [one occurrence] is what you're saying, it is a red herring, Mr Herring. That same > situation exists both today and with the proposal from Yidong. > > That is a difficulty for simple search whether magic is off or on: One cannot > easily match both a stretch of whitespace and a single SPC (as opposed to a > stretch) in the same search string. It is inherent to simple search - that use > case cries out for regexp search instead. With magic C-s, you can easily match it with appropriate C-q. The toggle would only be a win for a search string like "lots_of_words_like_foo_bar_baz quux quoo frobozz bandersnatch cupcake" where the _ represents a magic space and the spaces are not magic. If the string is instead "alternating words_with different_kinds of_spaces", the toggle will be twice as expensive as C-q. (I have no idea which one of these is more likely; neither seems terribly common.) >>> * Users can set the variable value in their init files, if >>> they want to change the default (i.e., initial) behavior. >> >> Er, yes? > > Yes? > > Dunno what is unclear here. The point is that you and I can each start out with > the behavior we want. That users can customize Emacs is so obvious as to render that text distracting. It's not important. > Today, the _code_ decides in a hard-coded way that regexp search uses > magic-space and simple search does not. Yidong proposes the opposite - but > still hard-coding. And I guess you are agreeing with that proposal. The current code decides that regexp search has a custom option (which is of course much heavier when it is not key-accessible), and that simple search has no choice at all. Yidong's proposal (given obvious backward-compatibility obligations and standard customizability ideas) would surely be to change the default for the existing variable and add `search-search-whitespace-regexp' or so that controlled C-s, defaulted to the current default for `search-whitespace-regexp'. Given the rarity (IMO) of caring about searching for single spaces in a simple search (as would justify having quick access to both modes within simple search), and the relative ease of making a regexp search do whatever you want regardless of the value of `search-whitespace-regexp', I find no problem with this proposal. Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 13:59 ` Drew Adams 2012-08-15 14:31 ` Davis Herring @ 2012-08-15 22:53 ` Dmitry Gutov 2012-08-15 23:21 ` Drew Adams 1 sibling, 1 reply; 56+ messages in thread From: Dmitry Gutov @ 2012-08-15 22:53 UTC (permalink / raw) To: Drew Adams; +Cc: 'Bastien', cyd, emacs-devel, 'Dani Moncayo' On 15.08.2012 17:59, Drew Adams wrote: > By default, "magic-space" searching should be OFF for both simple and regexp > search. Each SPC you type should search for a single SPC, by default. Simple. > No surprise. > > Others have given reasons for the regexp case (+1). For the simple-search case: > I do not think it is appropriate for users, especially newbies, to have to > figure out and use `C-q SPC' (WTF?) to search for a single SPC char. I have had `isearch-forward-regexp' bound to C-s for about as long as I'm using Emacs (thanks to starter-kit.el), and I've never encountered a situation where the current default behavior caused a problem. I never even knew that SPC did something special until I read the doc yesterday. Still, logically, it doesn't make sense since the `-regexp' version is supposed to be fine-controlled by the user, and they can easily write the required regexp. On the flip side, I've seen many times that less-technical users can be sloppy with the amount of whitespace between words. If the non-regexp version is supposed to be easy to use, then `search-whitespace-regexp' behavior might be quite useful there. And `fill-paragraph' behavior adds to that argument, too. ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-15 22:53 ` Dmitry Gutov @ 2012-08-15 23:21 ` Drew Adams 2012-08-16 2:25 ` Dmitry Gutov 0 siblings, 1 reply; 56+ messages in thread From: Drew Adams @ 2012-08-15 23:21 UTC (permalink / raw) To: 'Dmitry Gutov' Cc: 'Bastien', cyd, emacs-devel, 'Dani Moncayo' > On the flip side, I've seen many times that less-technical > users can be sloppy with the amount of whitespace between words. > If the non-regexp version is supposed to be easy to use, then > `search-whitespace-regexp' behavior might be quite useful there. Less-technical users are often used to less-technical editors that do NOT try to be so clever (er, that is, "easy to use"). MS Word, for instance (yes, as far as simple searching is concerned, it can be considered an editor). And typical web browsers (whose simple on-page searching can also be compared here). You type a space to look for a space, two spaces to look for two spaces,... Not every search (or even most searches?) by less-technical users is intended to ignore additional whitespace. Whitespace can matter to less-technical users too. And less-technical does not necessarily mean more sloppy, including about whitespace between words. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 23:21 ` Drew Adams @ 2012-08-16 2:25 ` Dmitry Gutov 2012-08-16 5:37 ` Drew Adams 0 siblings, 1 reply; 56+ messages in thread From: Dmitry Gutov @ 2012-08-16 2:25 UTC (permalink / raw) To: Drew Adams; +Cc: 'Bastien', cyd, emacs-devel, 'Dani Moncayo' On 16.08.2012 3:21, Drew Adams wrote: >> On the flip side, I've seen many times that less-technical >> users can be sloppy with the amount of whitespace between words. >> If the non-regexp version is supposed to be easy to use, then >> `search-whitespace-regexp' behavior might be quite useful there. > > Less-technical users are often used to less-technical editors that do NOT try to > be so clever (er, that is, "easy to use"). Incremental search in Emacs is different enough from the search function in simple editors, I think, that doing things the same way is not very valuable. > Not every search (or even most searches?) by less-technical users is intended to > ignore additional whitespace. Whitespace can matter to less-technical users > too. And less-technical does not necessarily mean more sloppy, including about > whitespace between words. Like I said, the amount of false positives is, in my experience, negligible. But it can prevent some false negatives, in some situations, for certain user expectations. ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-16 2:25 ` Dmitry Gutov @ 2012-08-16 5:37 ` Drew Adams 0 siblings, 0 replies; 56+ messages in thread From: Drew Adams @ 2012-08-16 5:37 UTC (permalink / raw) To: 'Dmitry Gutov' Cc: 'Bastien', cyd, emacs-devel, 'Dani Moncayo' > >> On the flip side, I've seen many times that less-technical > >> users can be sloppy with the amount of whitespace between words. > >> If the non-regexp version is supposed to be easy to use, then > >> `search-whitespace-regexp' behavior might be quite useful there. > > > > Less-technical users are often used to less-technical > > editors that do NOT try to be so clever (er, that is, "easy > > to use"). > > Incremental search in Emacs is different enough from the > search function in simple editors, I think, that doing things > the same way is not very valuable. Oh, we are so smart. How come those who _invented_ incremental search and _invented_ Emacs were not so terribly smart? http://en.wikipedia.org/wiki/Incremental_search Someone should also tell the web browsers that offer incremental search... --- Seriously, I'm convinced of the usefulness of magic-SPC simple search. No one is suggesting that Emacs must "do things the same way" as simple editors. The question about minimizing surprise here is a question about the _default_ behavior: which simple-search behavior is turned on to begin with, with `emacs -Q'. And I don't really care a whole lot whether you make magic-SPC the default behavior. What I care about more is (a) the ability to easily toggle it on/off on the fly and (b) the ability for users to choose their own default (initial) behavior. --- BTW, it just occurred to me that when magic-SPC searching is turned on for simple search, it could help to (optionally) highlight consecutive SPC, and any non-SPC, whitespace chars in search hits (slightly) differently from the normal search-hit highlighting. And within a search hit, non-SPC whitespace chars (e.g. TAB, nobreak space) could be highlighted (slightly) differently from SPC chars. (This is for search hits - not the same thing as `nobreak-char-display'.) This would distinguish search hits with more than one whitespace char, and those with non-SPC whitespace chars, from those with only one SPC char. And it would help users tell which SPC-search mode they are currently in. It might be less surprising for a user who is not expecting (aware of) matching of consecutive whitespace chars and matching of non-SPC whitespace chars when s?he hits SPC, if such matches were more apparent. And that includes not just a newbie but also someone who has forgotten that magic-SPC search is turned on. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-15 9:11 ` Dani Moncayo ` (2 preceding siblings ...) 2012-08-15 13:59 ` Drew Adams @ 2012-08-26 4:06 ` Chong Yidong 2012-08-26 6:59 ` Bastien ` (3 more replies) 3 siblings, 4 replies; 56+ messages in thread From: Chong Yidong @ 2012-08-26 4:06 UTC (permalink / raw) To: Dani Moncayo; +Cc: Bastien, emacs-devel, Dmitry Gutov Dani Moncayo <dmoncayo@gmail.com> writes: > IMO, that feature is what the user usually wants in an ordinary search > (regardless it's incremental or not; even if that search is part of a > ordinary replace command). > > On the other and, in a rexexp search (or regexp search&replace) I > think that the common case is the opposite: the user normally doesn't > want that feature. I committed a change to trunk to make non-regexp isearch match multiple spaces via search-spaces-regexp. As for regexp isearch, it seems disruptive to remove the feature now, since some some users might have grown to rely on it. So I left regexp isearch alone (i.e. it still does the multiple spaces matching). It is now possible to change the variable `search-whitespace-regexp' and give it a cons cell value, which specifies different behaviors for ordinary and regexp isearch. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 4:06 ` Chong Yidong @ 2012-08-26 6:59 ` Bastien 2012-08-26 15:19 ` Dani Moncayo ` (2 subsequent siblings) 3 siblings, 0 replies; 56+ messages in thread From: Bastien @ 2012-08-26 6:59 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel, Dmitry Gutov, Dani Moncayo Chong Yidong <cyd@gnu.org> writes: > Dani Moncayo <dmoncayo@gmail.com> writes: > >> IMO, that feature is what the user usually wants in an ordinary search >> (regardless it's incremental or not; even if that search is part of a >> ordinary replace command). >> >> On the other and, in a rexexp search (or regexp search&replace) I >> think that the common case is the opposite: the user normally doesn't >> want that feature. > > I committed a change to trunk to make non-regexp isearch match multiple > spaces via search-spaces-regexp. Great, thanks. > As for regexp isearch, it seems disruptive to remove the feature now, > since some some users might have grown to rely on it. So I left regexp > isearch alone (i.e. it still does the multiple spaces matching). I think the behavior in regexp isearch will be less surprising now. So keeping the two behaviors (in isearch and regexp isearch) in sync looks okay to me. > It is now possible to change the variable `search-whitespace-regexp' and > give it a cons cell value, which specifies different behaviors for > ordinary and regexp isearch. Even better! Thanks for implementing this, -- Bastien ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 4:06 ` Chong Yidong 2012-08-26 6:59 ` Bastien @ 2012-08-26 15:19 ` Dani Moncayo 2012-08-26 17:31 ` Dani Moncayo 2012-08-27 18:34 ` Johan Bockgård 2012-08-28 8:27 ` Juri Linkov 3 siblings, 1 reply; 56+ messages in thread From: Dani Moncayo @ 2012-08-26 15:19 UTC (permalink / raw) To: Chong Yidong; +Cc: Bastien, emacs-devel, Dmitry Gutov > I committed a change to trunk to make non-regexp isearch match multiple > spaces via search-spaces-regexp. > > As for regexp isearch, it seems disruptive to remove the feature now, > since some some users might have grown to rely on it. So I left regexp > isearch alone (i.e. it still does the multiple spaces matching). > > It is now possible to change the variable `search-whitespace-regexp' and > give it a cons cell value, which specifies different behaviors for > ordinary and regexp isearch. Thank's Chong. While testing your change, I've noticed a couple of things that I'd like to understand: 1. Info mode has its own variable `Info-search-whitespace-regexp'. Why is it necessary? I guess there's a reason (which I don't know by now) so it seems that your change should also affect to this variable. 2. Why don't you include \n and \r by default in the regexp? IMO that'd be TRT for most users. TIA. -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 15:19 ` Dani Moncayo @ 2012-08-26 17:31 ` Dani Moncayo 2012-08-28 8:28 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Dani Moncayo @ 2012-08-26 17:31 UTC (permalink / raw) To: Chong Yidong; +Cc: Bastien, emacs-devel, Dmitry Gutov > While testing your change, I've noticed a couple of things that I'd > like to understand: > > 1. Info mode has its own variable `Info-search-whitespace-regexp'. > Why is it necessary? I guess there's a reason (which I don't know by > now) so it seems that your change should also affect to this variable. > > 2. Why don't you include \n and \r by default in the regexp? IMO > that'd be TRT for most users. 3. Why should this feature be limited to _incremental_ searches? I don't think it should. The documentation states this limitation (see [1][2][3]) but according to the tests I've done, non-incremental searches also take `search-whitespace-regexp' into account. ----------- [1] Docstring of command `isearch-forward'. [2] Docstring of variable `search-whitespace-regexp'. [3] Info node "(emacs) Regexp Search". -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 17:31 ` Dani Moncayo @ 2012-08-28 8:28 ` Juri Linkov 2012-08-28 9:07 ` Dani Moncayo 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-28 8:28 UTC (permalink / raw) To: Dani Moncayo; +Cc: Chong Yidong, emacs-devel > 1. Info mode has its own variable `Info-search-whitespace-regexp'. > Why is it necessary? I guess there's a reason (which I don't know by > now) `Info-search-whitespace-regexp' is used in the regexp-based `Info-search'. Its default value is the same as for `search-whitespace-regexp' (actually it could inherit the default value directly from the value of `search-whitespace-regexp'). > so it seems that your change should also affect to this variable. Yes, these changes affect this variable. The condition that checks for `isearch-regexp' should be removed from `Info-search' like in the patch below (could be installed after resolving other problems). > 2. Why don't you include \n and \r by default in the regexp? IMO > that'd be TRT for most users. The default value of `search-whitespace-regexp' is "\\s-+" that means it matches whitespace including \n and \r by default. However, some modes override this default whitespace syntax where newlines are not whitespace. For example, in Lisp a newline ends a comment. But currently you can't search in comments without regard to line breaks anyway. To implement this, `search-whitespace-regexp' should also ignore the semicolon that starts a comment. > 3. Why should this feature be limited to _incremental_ searches? I > don't think it should. The documentation states this limitation (see > [1][2][3]) but according to the tests I've done, non-incremental > searches also take `search-whitespace-regexp' into account. By the term "non-incremental searches" do you mean `M-x nonincremental-search-forward RET' or `C-s RET'? PS: The patch for info.el: === modified file 'lisp/info.el' --- lisp/info.el 2012-08-25 20:00:40 +0000 +++ lisp/info.el 2012-08-28 08:27:44 +0000 @@ -328,7 +328,7 @@ (defcustom Info-breadcrumbs-depth 4 :type 'integer :group 'info) -(defcustom Info-search-whitespace-regexp "\\s-+" +(defcustom Info-search-whitespace-regexp search-whitespace-regexp "If non-nil, regular expression to match a sequence of whitespace chars. This applies to Info search for regular expressions. You might want to use something like \"[ \\t\\r\\n]+\" instead. @@ -1892,9 +1892,7 @@ (defun Info-search (regexp &optional bou (or (null found) (not (run-hook-with-args-until-failure 'isearch-filter-predicates beg-found found)))) - (let ((search-spaces-regexp - (if (or (not isearch-mode) isearch-regexp) - Info-search-whitespace-regexp))) + (let ((search-spaces-regexp Info-search-whitespace-regexp)) (if (if backward (re-search-backward regexp bound t) (re-search-forward regexp bound t)) @@ -1914,9 +1912,7 @@ (defun Info-search (regexp &optional bou (if (null Info-current-subfile) (if isearch-mode (signal 'search-failed (list regexp "at the end of manual")) - (let ((search-spaces-regexp - (if (or (not isearch-mode) isearch-regexp) - Info-search-whitespace-regexp))) + (let ((search-spaces-regexp Info-search-whitespace-regexp)) (if backward (re-search-backward regexp) (re-search-forward regexp)))) @@ -1975,9 +1971,7 @@ (defun Info-search (regexp &optional bou (or (null found) (not (run-hook-with-args-until-failure 'isearch-filter-predicates beg-found found)))) - (let ((search-spaces-regexp - (if (or (not isearch-mode) isearch-regexp) - Info-search-whitespace-regexp))) + (let ((search-spaces-regexp Info-search-whitespace-regexp)) (if (if backward (re-search-backward regexp nil t) (re-search-forward regexp nil t)) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 8:28 ` Juri Linkov @ 2012-08-28 9:07 ` Dani Moncayo 2012-08-28 23:01 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Dani Moncayo @ 2012-08-28 9:07 UTC (permalink / raw) To: Juri Linkov; +Cc: Chong Yidong, emacs-devel On Tue, Aug 28, 2012 at 10:28 AM, Juri Linkov <juri@jurta.org> wrote: >> 1. Info mode has its own variable `Info-search-whitespace-regexp'. >> Why is it necessary? I guess there's a reason (which I don't know by >> now) > > `Info-search-whitespace-regexp' is used in the regexp-based `Info-search'. OK but why do we need it? I.e, why can't use `search-whitespace-regexp' also in Info mode? > Its default value is the same as for `search-whitespace-regexp' > (actually it could inherit the default value directly from the value of > `search-whitespace-regexp'). > >> so it seems that your change should also affect to this variable. > > Yes, these changes affect this variable. The condition that checks for > `isearch-regexp' should be removed from `Info-search' like in the patch > below (could be installed after resolving other problems). Does your patch makes `Info-search-whitespace-regexp' in Info mode behave like `search-whitespace-regexp' in other modes? >> 2. Why don't you include \n and \r by default in the regexp? IMO >> that'd be TRT for most users. > > The default value of `search-whitespace-regexp' is "\\s-+" > that means it matches whitespace including \n and \r by default. > However, some modes override this default whitespace syntax > where newlines are not whitespace. For example, in Lisp > a newline ends a comment. But currently you can't search > in comments without regard to line breaks anyway. > To implement this, `search-whitespace-regexp' should also > ignore the semicolon that starts a comment. Ok I see it now. >> 3. Why should this feature be limited to _incremental_ searches? I >> don't think it should. The documentation states this limitation (see >> [1][2][3]) but according to the tests I've done, non-incremental >> searches also take `search-whitespace-regexp' into account. > > By the term "non-incremental searches" do you mean > `M-x nonincremental-search-forward RET' or `C-s RET'? I mean `C-s RET' or `C-M-s RET'. -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 9:07 ` Dani Moncayo @ 2012-08-28 23:01 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-28 23:01 UTC (permalink / raw) To: Dani Moncayo; +Cc: Chong Yidong, emacs-devel >> `Info-search-whitespace-regexp' is used in the regexp-based `Info-search'. > > OK but why do we need it? I.e, why can't use > `search-whitespace-regexp' also in Info mode? Maybe we could make `Info-search-whitespace-regexp' obsolete now. > Does your patch makes `Info-search-whitespace-regexp' in Info mode > behave like `search-whitespace-regexp' in other modes? Yes, I see no differences. >>> 3. Why should this feature be limited to _incremental_ searches? I >>> don't think it should. The documentation states this limitation (see >>> [1][2][3]) but according to the tests I've done, non-incremental >>> searches also take `search-whitespace-regexp' into account. >> >> By the term "non-incremental searches" do you mean >> `M-x nonincremental-search-forward RET' or `C-s RET'? > > I mean `C-s RET' or `C-M-s RET'. Then the word "incremental" should be removed from the docstrings of `isearch-forward' and `search-whitespace-regexp' and from the Info node "(emacs) Regexp Search". ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 4:06 ` Chong Yidong 2012-08-26 6:59 ` Bastien 2012-08-26 15:19 ` Dani Moncayo @ 2012-08-27 18:34 ` Johan Bockgård 2012-08-28 8:30 ` Juri Linkov 2012-08-28 8:27 ` Juri Linkov 3 siblings, 1 reply; 56+ messages in thread From: Johan Bockgård @ 2012-08-27 18:34 UTC (permalink / raw) To: emacs-devel Chong Yidong <cyd@gnu.org> writes: > I committed a change to trunk to make non-regexp isearch match multiple > spaces via search-spaces-regexp. The magic of `C-q SPC' is missing for non-regexp searches though. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-27 18:34 ` Johan Bockgård @ 2012-08-28 8:30 ` Juri Linkov 2012-08-28 12:53 ` Stefan Monnier 2012-08-29 6:46 ` Chong Yidong 0 siblings, 2 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-28 8:30 UTC (permalink / raw) To: emacs-devel > The magic of `C-q SPC' is missing for non-regexp searches though. `C-q SPC' inserts "[ ]" in regexp search. The problem for non-regexp search is how to avoid quoting "[ ]" in `regexp-quote'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 8:30 ` Juri Linkov @ 2012-08-28 12:53 ` Stefan Monnier 2012-08-28 22:54 ` Juri Linkov 2012-08-29 6:46 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2012-08-28 12:53 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel I have other things to do, so I haven't participated in this thread, but FWIW, I think that search-whitespace-regexp is not something that should be used by default. Stefan "who also dislikes its internal implementation" >>>>> "Juri" == Juri Linkov <juri@jurta.org> writes: >> The magic of `C-q SPC' is missing for non-regexp searches though. > `C-q SPC' inserts "[ ]" in regexp search. The problem for non-regexp > search is how to avoid quoting "[ ]" in `regexp-quote'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 12:53 ` Stefan Monnier @ 2012-08-28 22:54 ` Juri Linkov 2012-08-28 23:52 ` Drew Adams 2012-08-30 8:19 ` Chong Yidong 0 siblings, 2 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-28 22:54 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel > I have other things to do, so I haven't participated in this thread, > but FWIW, I think that search-whitespace-regexp is not something that > should be used by default. Ignoring whitespace in isearch is a very useful feature. But I agree that its current implementation is far from optimal. It would be better to reimplement it in isearch exactly the same way as `isearch-word' is implemented because these two are similar features. A new `isearch-whitespace' toggled by `M-s SPC' could construct a regexp like in `word-search-regexp' and search it with `re-search-forward' in `isearch-search-fun-default'. This will provide flexibility to solve related problems. To make this feature less "magic" and surprising to users, it could reveal a constructed regexp after switching from ordinary isearch mode to regexp mode. As well as after switching from word mode to regexp mode could also reveal the regexp used to search words ignoring punctuation. Another variant to implement `isearch-toggle-whitespace' is like `isearch-toggle-case-fold' that changes the value of the internal variable `case-fold-search' effective to both regexp and non-regexp searches. But I don't know how difficult is to modify the search engine to ignore whitespace the same way as it ignores case using translation tables. Regarding the need to quote literal spaces in non-regexp search, one example of possible solution is HTML that uses "nobr" for essential whitespace that should not be ignored. Doing the same in isearch for `C-q SPC' would insert "no-break space" to the search string. Then repeating a non-regexp search from the search ring will correctly interpret it as a literal space (as opposed to the normal space character interpreted as whitespace pattern). ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-28 22:54 ` Juri Linkov @ 2012-08-28 23:52 ` Drew Adams 2012-08-29 8:38 ` Juri Linkov 2012-08-30 8:19 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Drew Adams @ 2012-08-28 23:52 UTC (permalink / raw) To: 'Juri Linkov', 'Stefan Monnier'; +Cc: emacs-devel > Regarding the need to quote literal spaces in non-regexp search, > one example of possible solution is HTML that uses "nobr" > for essential whitespace that should not be ignored. > Doing the same in isearch for `C-q SPC' would insert "no-break space" > to the search string. Then repeating a non-regexp search > from the search ring will correctly interpret it as a literal space > (as opposed to the normal space character interpreted as > whitespace pattern). I liked most of what you said up to that point. It generally echoes what I said earlier (including adding a toggle). But I don't agree with this last part. We should not mix nobreak-space with this whitespace-search feature, at all. Users should keep the ability to search for nobreak-space chars and ordinary space chars separately, including in the same search string. The former are perfectly legitimate, normal chars. If you cannot type a nobreak-space char to search literally for such a char, then we're back at square 1. Please do not look for any existing char to signify something special here, thus taking it away from literal search. C-q should be the only char/key that does that kind of thing. It's fine to have keys that toggle different search "modes" (word, case-fold, diff whitespace patterns, etc.). But let's not sacrifice some char (e.g. nobreak-space), so that its use in a search string means something special, not searching for itself. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 23:52 ` Drew Adams @ 2012-08-29 8:38 ` Juri Linkov 2012-08-29 16:01 ` Drew Adams 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-29 8:38 UTC (permalink / raw) To: Drew Adams; +Cc: 'Stefan Monnier', emacs-devel > But let's not sacrifice some char (e.g. nobreak-space), so that its > use in a search string means something special, not searching for itself. The space character is special to indicate whitespace. We need another special character to indicate literal space in non-regexp searches. Could you find a better character than nobreak-space? ^ permalink raw reply [flat|nested] 56+ messages in thread
* RE: Interpretation of a space in regexp isearch? 2012-08-29 8:38 ` Juri Linkov @ 2012-08-29 16:01 ` Drew Adams 2012-08-29 23:49 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Drew Adams @ 2012-08-29 16:01 UTC (permalink / raw) To: 'Juri Linkov'; +Cc: 'Stefan Monnier', emacs-devel > > But let's not sacrifice some char (e.g. nobreak-space), so that its > > use in a search string means something special, not > searching for itself. > > The space character is special to indicate whitespace. > We need another special character IMO, you are too liberal with the "we need"s. > to indicate literal space in non-regexp searches. I don't buy the assumption that we need a "special char" to indicate a literal space in a non-regexp search. Toggling this new mode on/off should suffice for most simple searches where you want to search for literal SPC chars. For the remainder, i.e., simple searches where both literal spaces and magic-whitespace are searched for in the same search string, I would say that users should take one of these approaches: 1. use regexp search instead (seriously) 2. use C-q (or perhaps C-u?) to escape the following character to be treated literally #2 might require some work by Emacs Dev. > Could you find a better character than nobreak-space? Sorry, I don't buy the claim that "we need another special character to indicate literal space in non-regexp searches." --- Look, we could be doing this kind of thing for other magic search strings also. Essentially the idea is to come up with a shortcut (for typing and visibility) for a regexp (or other complex searching pattern/mechanism) that is used often, for common matches. A second part of the idea is to hide the fact that such complex searching is involved - whether for simple or regexp searching. If a user knows that s?he is doing regexp search, then any shortcut "mode" that enables the user to, say, type only `(' instead of `\(', can be turned on/off with a toggle. Yes, sure, we need to define each mode state completely, e.g., how to indicate a literal `(' when `(' means what `\(' means in the opposite mode state. I proposed long ago, for instance, a toggle for a `.' in regexp search to match also newlines, i.e., any character. IOW, `.' in one mode state of the toggle, `.' would be equivalent to "\\(.\\|[\n]\\)" in the other (traditional) state. I still think that particular enhancement would be helpful. I've used it in Icicles for years, and it is very handy, IMO. I use text properties so the user (optionally, and by default) sees only `.' when s?he types `.', but in fact what is used is the regexp that matches also \n. Such a magic, multi-line dot is (optionally) highlighted in the minibuffer, so you can distinguish it. And you can hit a key to toggle the state. And you can hit another key to toggle whether the `.' is shown as `.' or as its underlying regexp. When such a multi-line dot is present in the minibuffer, editing treats it as a single char; e.g., it DTRT when you delete or transpose chars. How do I deal with the case of mixing multi-line and ordinary dots in the same minibuffer input (analog to a search string)? A prefix arg to `.' flips it from its usual behavior (whether multi-line or normal/literal) to the opposite. We _might_ want to do similarly for Isearch. Here is a bit more explanation. http://www.emacswiki.org/emacs/Icicles_-_Dot%2c_Dot%2c_Dot Consider that food for thought. I'm not actively suggesting that the same approach should be used for Isearch, or that it is "the answer". My point here is: 1. The motivation for the current magic whitespace discussion can be generalized to other magic chars or SOMETHING-ignoring modes. So the discussion should perhaps be more general also. 2. Sacrificing a "special char" (e.g. nobreak-space) for this kind of thing is the wrong approach, IMO. I would also add that whenever we do something like this that hides what's really going on from the user, as a convenience, there is the possibility of confusion and complication. So we had better enable users to alternatively SEE what is otherwise hidden. A toggle to show the ugly, underlying stuff as part of the search string is helpful to users. For one thing, it can help them understand why what they think they are searching for might not be what they are really searching for. It gives them a means to investigate and learn more. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 16:01 ` Drew Adams @ 2012-08-29 23:49 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-29 23:49 UTC (permalink / raw) To: Drew Adams; +Cc: Stefan Monnier, emacs-devel > Toggling this new mode on/off should suffice for most simple searches > where you want to search for literal SPC chars. I agree there is less trouble toggling whitespace mode with `M-s SPC' than applying an ugly solution to quote literal spaces with `C-q SPC'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 22:54 ` Juri Linkov 2012-08-28 23:52 ` Drew Adams @ 2012-08-30 8:19 ` Chong Yidong 2012-08-30 8:31 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-30 8:19 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > It would be better to reimplement it in isearch exactly the same way > as `isearch-word' is implemented because these two are similar > features. > > A new `isearch-whitespace' toggled by `M-s SPC' could construct a regexp > like in `word-search-regexp' and search it with `re-search-forward' in > `isearch-search-fun-default'. This will provide flexibility to solve > related problems. I think this is a good idea. I'd like the whitespace munging to be enabled for C-s, unless the user disables it by customizing `search-whitespace-regexp' (or whatever variable we decide on). So `isearch-forward' itself should pass the relevant flag to `isearch-mode'. Instead of adding an `isearch-whitespace' flag, I think this is best implemented as a third possible value for `isearch-word', say the symbol `match-any-whitespace'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 8:19 ` Chong Yidong @ 2012-08-30 8:31 ` Chong Yidong 2012-08-30 8:54 ` Juri Linkov 2012-08-31 0:07 ` Juri Linkov 0 siblings, 2 replies; 56+ messages in thread From: Chong Yidong @ 2012-08-30 8:31 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Chong Yidong <cyd@gnu.org> writes: > Instead of adding an `isearch-whitespace' flag, I think this is best > implemented as a third possible value for `isearch-word', say the > symbol `match-any-whitespace'. Whoops, `isearch-word' already accepts function values, for purposes of symbol searching. The `isearch-toggle-whitespace' command simply needs to set this. Maybe that's is what you already had in mind. Do you want to take a crack at it, or shall I? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 8:31 ` Chong Yidong @ 2012-08-30 8:54 ` Juri Linkov 2012-08-30 14:47 ` Stefan Monnier 2012-08-31 0:07 ` Juri Linkov 1 sibling, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-30 8:54 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel >> Instead of adding an `isearch-whitespace' flag, I think this is best >> implemented as a third possible value for `isearch-word', say the >> symbol `match-any-whitespace'. > > Whoops, `isearch-word' already accepts function values, for purposes of > symbol searching. The `isearch-toggle-whitespace' command simply needs > to set this. Maybe that's is what you already had in mind. The problem is that whitespace mode can be active together with regexp mode and also simultaneously with plain C-s mode. This is different from `isearch-word' that is a separate mode mutually exclusive with C-s and C-M-s. For instance, `isearch-toggle-regexp' sets `isearch-word' to nil, but it should not disable whitespace mode (it should be disabled only with the command `isearch-toggle-whitespace'). This is why I tend to implement it more like `isearch-toggle-case-fold' than `isearch-toggle-word'. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 8:54 ` Juri Linkov @ 2012-08-30 14:47 ` Stefan Monnier 2012-08-31 0:02 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Stefan Monnier @ 2012-08-30 14:47 UTC (permalink / raw) To: Juri Linkov; +Cc: Chong Yidong, emacs-devel > The problem is that whitespace mode can be active together with regexp mode > and also simultaneously with plain C-s mode. I think that combining whitespace mode with regexp mode was a mistake, so I'm not sure how important it is to support it. Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 14:47 ` Stefan Monnier @ 2012-08-31 0:02 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-31 0:02 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel >> The problem is that whitespace mode can be active together with regexp mode >> and also simultaneously with plain C-s mode. > > I think that combining whitespace mode with regexp mode was a mistake, > so I'm not sure how important it is to support it. Disallowing whitespace mode with regexp mode will simplify matters, and if someone still wants this functionality then it could be configured by adding a new user option `regexp-search-whitespace' (like `search-whitespace' but for regexp mode). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 8:31 ` Chong Yidong 2012-08-30 8:54 ` Juri Linkov @ 2012-08-31 0:07 ` Juri Linkov 2012-08-31 5:40 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-31 0:07 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel > Chong Yidong <cyd@gnu.org> writes: > > Do you want to take a crack at it, or shall I? The following patch just echoes what was being said in this discussion so far. Please review it and decide what to do next. === modified file 'lisp/isearch.el' --- lisp/isearch.el 2012-08-27 04:08:32 +0000 +++ lisp/isearch.el 2012-08-31 00:04:17 +0000 @@ -109,6 +109,19 @@ (defcustom search-nonincremental-instead :type 'boolean :group 'isearch) +(defcustom search-whitespace t + "If non-nil, a space will match a sequence of whitespace chars. +When you enter a space or spaces in the incremental search, it +will match any sequence matched by the regexp in the variable +`search-whitespace-regexp'. + +If the value is nil, each space you type matches literally, +against one space." + :type '(choice (const :tag "Treat Spaces Literally" nil) + (const :tag "Match a sequence of whitespace chars" t)) + :group 'isearch + :version "24.3") + (defcustom search-whitespace-regexp (purecopy "\\s-+") "If non-nil, regular expression to match a sequence of whitespace chars. When you enter a space or spaces in the incremental search, it @@ -120,20 +133,10 @@ (defcustom search-whitespace-regexp (pur incremental search. If the value is nil, each space you type matches literally, against one space. -The value can also be a cons cell (REGEXP-1 . REGEXP-2). In that -case, REGEXP-1 is used as the value for ordinary incremental -search, and REGEXP-2 is used for regexp incremental search. - You might want to use something like \"[ \\t\\r\\n]+\" instead. In the Customization buffer, that is `[' followed by a space, a tab, a carriage return (control-M), a newline, and `]+'." :type '(choice (const :tag "Treat Spaces Literally" nil) - (cons (choice :tag "For Ordinary Isearch" - regexp - (const :tag "Treat Spaces Literally" nil)) - (choice :tag "For Regexp Isearch" - regexp - (const :tag "Treat Spaces Literally" nil))) regexp) :group 'isearch :version "24.3") @@ -510,6 +525,7 @@ (defvar isearch-mode-map (define-key map "\M-r" 'isearch-toggle-regexp) (define-key map "\M-e" 'isearch-edit-string) + (define-key map "\M-s " 'isearch-toggle-whitespace) (define-key map "\M-sc" 'isearch-toggle-case-fold) (define-key map "\M-sr" 'isearch-toggle-regexp) (define-key map "\M-sw" 'isearch-toggle-word) @@ -1374,7 +1400,8 @@ (defun isearch-toggle-regexp () ;; The status stack is left unchanged. (interactive) (setq isearch-regexp (not isearch-regexp)) - (if isearch-regexp (setq isearch-word nil)) + (if isearch-regexp (setq isearch-word nil + search-whitespace nil)) (setq isearch-success t isearch-adjusted t) (isearch-update)) @@ -1383,7 +1410,8 @@ (defun isearch-toggle-word () ;; The status stack is left unchanged. (interactive) (setq isearch-word (not isearch-word)) - (if isearch-word (setq isearch-regexp nil)) + (if isearch-word (setq isearch-regexp nil + search-whitespace nil)) (setq isearch-success t isearch-adjusted t) (isearch-update)) @@ -1392,6 +1420,8 @@ (defun isearch-toggle-symbol () (interactive) (setq isearch-word (unless (eq isearch-word 'isearch-symbol-regexp) 'isearch-symbol-regexp)) + (if isearch-word (setq isearch-regexp nil + search-whitespace nil)) (setq isearch-success t isearch-adjusted t) (isearch-update)) @@ -1409,6 +1439,19 @@ (defun isearch-toggle-case-fold () (sit-for 1) (isearch-update)) +(defun isearch-toggle-whitespace () + "Toggle whitespace matching in searching on or off." + (interactive) + (setq search-whitespace (not search-whitespace)) + (let ((message-log-max nil)) + (message "%s%s [whitespace matching %s]" + (isearch-message-prefix nil isearch-nonincremental) + isearch-message + (if search-whitespace "enabled" "disabled"))) + (setq isearch-success t isearch-adjusted t) + (sit-for 1) + (isearch-update)) + \f ;; Word search @@ -1558,15 +1611,6 @@ (defun isearch-query-replace-regexp (&op (list current-prefix-arg)) (isearch-query-replace delimited t)) -(defun isearch-whitespace-regexp () - "Return the value of `search-whitespace-regexp' for the current search." - (cond ((not (consp search-whitespace-regexp)) - search-whitespace-regexp) - (isearch-regexp - (cdr search-whitespace-regexp)) - (t - (car search-whitespace-regexp)))) - (defun isearch-occur (regexp &optional nlines) "Run `occur' using the last search string as the regexp. Interactively, REGEXP is constructed using the search string from the @@ -1606,7 +1650,8 @@ (defun isearch-occur (regexp &optional n ;; Set `search-upper-case' to nil to not call ;; `isearch-no-upper-case-p' in `occur-1'. (search-upper-case nil) - (search-spaces-regexp (isearch-whitespace-regexp))) + (search-spaces-regexp (if search-whitespace + search-whitespace-regexp))) (occur regexp nlines))) (declare-function hi-lock-read-face-name "hi-lock" ()) @@ -2428,6 +2488,8 @@ (defun isearch-search-fun () (defun isearch-search-fun-default () "Return default functions to use for the search." (cond + ((and search-whitespace search-whitespace-regexp (not isearch-regexp)) + (if isearch-forward 'whitespace-search-forward 'whitespace-search-backward)) (isearch-word (lambda (string &optional bound noerror count) ;; Use lax versions to not fail at the end of the word while @@ -2446,12 +2508,12 @@ (defun isearch-search-fun-default () (isearch-regexp (if isearch-forward 're-search-forward 're-search-backward)) (t - (if isearch-forward 'isearch-search-forward 'isearch-search-backward)))) + (if isearch-forward 'search-forward 'search-backward)))) -(defun isearch-search-forward (string &optional bound noerror count) +(defun whitespace-search-forward (string &optional bound noerror count) (re-search-forward (regexp-quote string) bound noerror count)) -(defun isearch-search-backward (string &optional bound noerror count) +(defun whitespace-search-backward (string &optional bound noerror count) (re-search-backward (regexp-quote string) bound noerror count)) (defun isearch-search-string (string bound noerror) @@ -2503,7 +2565,8 @@ (defun isearch-search () search-invisible)) (inhibit-quit nil) (case-fold-search isearch-case-fold-search) - (search-spaces-regexp (isearch-whitespace-regexp)) + (search-spaces-regexp (if search-whitespace + search-whitespace-regexp)) (retry t)) (setq isearch-error nil) (while retry @@ -2805,7 +2912,8 @@ (defvar isearch-lazy-highlight-window-st (defvar isearch-lazy-highlight-window-end nil) (defvar isearch-lazy-highlight-case-fold-search nil) (defvar isearch-lazy-highlight-regexp nil) -(defvar isearch-lazy-highlight-space-regexp nil) +(defvar isearch-lazy-highlight-whitespace nil) +(defvar isearch-lazy-highlight-whitespace-regexp nil) (defvar isearch-lazy-highlight-word nil) (defvar isearch-lazy-highlight-forward nil) (defvar isearch-lazy-highlight-error nil) @@ -2873,7 +2981,8 @@ (defun isearch-lazy-highlight-new-loop ( isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search isearch-lazy-highlight-regexp isearch-regexp - isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp) + isearch-lazy-highlight-whitespace search-whitespace + isearch-lazy-highlight-whitespace-regexp search-whitespace-regexp isearch-lazy-highlight-word isearch-word isearch-lazy-highlight-forward isearch-forward) (unless (equal isearch-string "") @@ -2887,7 +2996,8 @@ (defun isearch-lazy-highlight-search () (condition-case nil (let ((case-fold-search isearch-lazy-highlight-case-fold-search) (isearch-regexp isearch-lazy-highlight-regexp) - (search-spaces-regexp isearch-lazy-highlight-space-regexp) + (search-spaces-regexp (if isearch-lazy-highlight-whitespace + isearch-lazy-highlight-whitespace-regexp)) (isearch-word isearch-lazy-highlight-word) (search-invisible nil) ; don't match invisible text (retry t) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-31 0:07 ` Juri Linkov @ 2012-08-31 5:40 ` Chong Yidong 2012-08-31 9:31 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-31 5:40 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > The following patch just echoes what was being said > in this discussion so far. Please review it and decide > what to do next. Thanks, this mostly looks good. Some comments: - search-whitespace should not be a defcustom, since it is altered by commands like isearch-toggle-whitespace. Users can customize whether to enable the feature by default setting search-whitespace-regexp to either nil or a regexp. I think search-whitespace should be renamed to something more accurate like isearch-lax-space-match, and made into a defvar. - Don't call the functions whitespace-search-forward; the whitespace- prefix should be reserved for whitespace.el. Call it something like isearch-forward-lax-space-match. - Instead of [whitespace matching enabled/disabled], I suggest the messages [strict space matching] and [lax space matching]. Also, I guess it won't be difficult to make M-s SPC work for regexp search too, by making it change search-spaces-regexp. This can be left for later. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-31 5:40 ` Chong Yidong @ 2012-08-31 9:31 ` Juri Linkov 2012-08-31 14:55 ` Chong Yidong 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-31 9:31 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel > - search-whitespace should not be a defcustom, since it is altered by > commands like isearch-toggle-whitespace. Users can customize whether > to enable the feature by default setting search-whitespace-regexp to > either nil or a regexp. I think search-whitespace should be renamed > to something more accurate like isearch-lax-space-match, and made into > a defvar. Like there are two existing variables with similar functionality `compare-windows-whitespace' and `compare-ignore-whitespace', maybe it would be better to have similar names in isearch: the already existing `search-whitespace-regexp' and a new defvar `isearch-ignore-whitespace'. > - Don't call the functions whitespace-search-forward; the whitespace- > prefix should be reserved for whitespace.el. Call it something like > isearch-forward-lax-space-match. The prefix `isearch-' is not quite right because these functions can be used in other packages like replace.el being bound to `replace-search-function'. `search-' seems more right. And when using the suffix `-ignore-whitespace' we could have functions: `search-forward-ignore-whitespace' and `search-backward-ignore-whitespace'. Or do you think `-ignore-whitespace' implies a more general functionality? For instance, instead of the current limited implementation that just turns every space character into a whitespace regexp like in: (defun search-forward-ignore-whitespace (string &optional bound noerror count) (let ((search-spaces-regexp search-whitespace-regexp)) (re-search-forward (regexp-quote string) bound noerror count))) it would be also useful to completely ignore all whitespace differences between the search string and the buffer text with the following implementation: (defun search-whitespace-regexp (string) (replace-regexp-in-string search-whitespace-regexp search-whitespace-regexp string nil t)) (defun search-forward-ignore-whitespace (string &optional bound noerror count) (re-search-forward (search-whitespace-regexp (regexp-quote string)) bound noerror count)) This is truly whitespace ignoring function that is very useful when yanking and searching lines containing a mix of spaces, tabs and newlines. This implementation ignores whitespace in the same way as `word-search-regexp' ignores punctuation. I don't want to complicate this feature, but this possibility for future development could be taken into account when thinking about suitable names for new functions and variables. > Also, I guess it won't be difficult to make M-s SPC work for regexp > search too, by making it change search-spaces-regexp. This can be left > for later. When users bind `isearch-forward-regexp' to C-s and use regexp search as simple search, they will miss this feature. So when leaving it, a separate variable is needed to disable whitespace mode in regexp mode, but to enable it in non-regexp simple mode by default. This requires a new variable `isearch-regexp-ignore-whitespace' but it complicates the functionality, so maybe it should be removed from the next version of the patch? === modified file 'lisp/isearch.el' --- lisp/isearch.el 2012-08-27 04:08:32 +0000 +++ lisp/isearch.el 2012-08-31 09:30:33 +0000 @@ -120,20 +120,10 @@ (defcustom search-whitespace-regexp (pur incremental search. If the value is nil, each space you type matches literally, against one space. -The value can also be a cons cell (REGEXP-1 . REGEXP-2). In that -case, REGEXP-1 is used as the value for ordinary incremental -search, and REGEXP-2 is used for regexp incremental search. - You might want to use something like \"[ \\t\\r\\n]+\" instead. In the Customization buffer, that is `[' followed by a space, a tab, a carriage return (control-M), a newline, and `]+'." :type '(choice (const :tag "Treat Spaces Literally" nil) - (cons (choice :tag "For Ordinary Isearch" - regexp - (const :tag "Treat Spaces Literally" nil)) - (choice :tag "For Regexp Isearch" - regexp - (const :tag "Treat Spaces Literally" nil))) regexp) :group 'isearch :version "24.3") @@ -510,6 +512,7 @@ (defvar isearch-mode-map (define-key map "\M-r" 'isearch-toggle-regexp) (define-key map "\M-e" 'isearch-edit-string) + (define-key map "\M-s " 'isearch-toggle-whitespace) (define-key map "\M-sc" 'isearch-toggle-case-fold) (define-key map "\M-sr" 'isearch-toggle-regexp) (define-key map "\M-sw" 'isearch-toggle-word) @@ -556,6 +564,17 @@ (defvar isearch-word nil The property `isearch-message-prefix' put on this function specifies the prefix string displayed in the search message.") +(defvar isearch-ignore-whitespace t + "If non-nil, a space will match a sequence of whitespace chars. +When you enter a space or spaces in the incremental search, it +will match any sequence matched by the regexp in the variable +`search-whitespace-regexp'. +If the value is nil, each space you type matches literally, +against one space.") + +(defvar isearch-regexp-ignore-whitespace nil + "Like `isearch-ignore-whitespace' but for regexp mode.") + (defvar isearch-cmds nil "Stack of search status sets. Each set is a vector of the form: @@ -1409,6 +1434,24 @@ (defun isearch-toggle-case-fold () (sit-for 1) (isearch-update)) +(defun isearch-toggle-whitespace () + "Toggle whitespace matching in searching on or off." + (interactive) + (if isearch-regexp + (setq isearch-regexp-ignore-whitespace (not isearch-regexp-ignore-whitespace)) + (setq isearch-ignore-whitespace (not isearch-ignore-whitespace))) + (let ((message-log-max nil)) + (message "%s%s [%s]" + (isearch-message-prefix nil isearch-nonincremental) + isearch-message + (if (if isearch-regexp + isearch-regexp-ignore-whitespace + isearch-ignore-whitespace) + "ignore whitespace" + "treat spaces literally"))) + (setq isearch-success t isearch-adjusted t) + (sit-for 1) + (isearch-update)) \f ;; Word search @@ -1507,6 +1561,25 @@ (defun isearch-symbol-regexp (string &op (put 'isearch-symbol-regexp 'isearch-message-prefix "symbol ") \f +;; Search ignoring whitespace + +(defun search-forward-ignore-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-forward (regexp-quote string) bound noerror count))) + +(defun search-backward-ignore-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-backward (regexp-quote string) bound noerror count))) + +(defun re-search-forward-ignore-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-forward string bound noerror count))) + +(defun re-search-backward-ignore-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-backward string bound noerror count))) + +\f (defun isearch-query-replace (&optional delimited regexp-flag) "Start `query-replace' with string to replace from last search string. The arg DELIMITED (prefix arg if interactive), if non-nil, means replace @@ -1522,6 +1595,14 @@ (defun isearch-query-replace (&optional ;; set `search-upper-case' to nil to not call ;; `isearch-no-upper-case-p' in `perform-replace' (search-upper-case nil) + (replace-search-function + (if (and isearch-ignore-whitespace (not regexp-flag)) + #'search-forward-ignore-whitespace + replace-search-function)) + (replace-re-search-function + (if (and isearch-regexp-ignore-whitespace regexp-flag) + #'re-search-forward-ignore-whitespace + replace-re-search-function)) ;; Set `isearch-recursive-edit' to nil to prevent calling ;; `exit-recursive-edit' in `isearch-done' that terminates ;; the execution of this command when it is non-nil. @@ -1558,15 +1639,6 @@ (defun isearch-query-replace-regexp (&op (list current-prefix-arg)) (isearch-query-replace delimited t)) -(defun isearch-whitespace-regexp () - "Return the value of `search-whitespace-regexp' for the current search." - (cond ((not (consp search-whitespace-regexp)) - search-whitespace-regexp) - (isearch-regexp - (cdr search-whitespace-regexp)) - (t - (car search-whitespace-regexp)))) - (defun isearch-occur (regexp &optional nlines) "Run `occur' using the last search string as the regexp. Interactively, REGEXP is constructed using the search string from the @@ -1606,7 +1678,11 @@ (defun isearch-occur (regexp &optional n ;; Set `search-upper-case' to nil to not call ;; `isearch-no-upper-case-p' in `occur-1'. (search-upper-case nil) - (search-spaces-regexp (isearch-whitespace-regexp))) + (search-spaces-regexp + (if (if isearch-regexp + isearch-regexp-ignore-whitespace + isearch-ignore-whitespace) + search-whitespace-regexp))) (occur regexp nlines))) (declare-function hi-lock-read-face-name "hi-lock" ()) @@ -2203,7 +2286,7 @@ (defun isearch-quote-char () ;; Assume character codes 0200 - 0377 stand for characters in some ;; single-byte character set, and convert them to Emacs ;; characters. - (if (and isearch-regexp (= char ?\s)) + (if (and isearch-regexp isearch-regexp-ignore-whitespace (= char ?\s)) (if (subregexp-context-p isearch-string (length isearch-string)) (isearch-process-search-string "[ ]" " ") (isearch-process-search-char char)) @@ -2443,16 +2534,19 @@ (defun isearch-search-fun-default () (funcall isearch-word string lax) (word-search-regexp string lax)) bound noerror count)))) + ((and isearch-regexp isearch-regexp-ignore-whitespace + search-whitespace-regexp) + (if isearch-forward + 're-search-forward-ignore-whitespace + 're-search-backward-ignore-whitespace)) (isearch-regexp (if isearch-forward 're-search-forward 're-search-backward)) + ((and isearch-ignore-whitespace search-whitespace-regexp) + (if isearch-forward + 'search-forward-ignore-whitespace + 'search-backward-ignore-whitespace)) (t - (if isearch-forward 'isearch-search-forward 'isearch-search-backward)))) - -(defun isearch-search-forward (string &optional bound noerror count) - (re-search-forward (regexp-quote string) bound noerror count)) - -(defun isearch-search-backward (string &optional bound noerror count) - (re-search-backward (regexp-quote string) bound noerror count)) + (if isearch-forward 'search-forward 'search-backward)))) (defun isearch-search-string (string bound noerror) "Search for the first occurrence of STRING or its translation. @@ -2503,17 +2597,13 @@ (defun isearch-search () search-invisible)) (inhibit-quit nil) (case-fold-search isearch-case-fold-search) - (search-spaces-regexp (isearch-whitespace-regexp)) (retry t)) (setq isearch-error nil) (while retry @@ -2805,7 +2942,8 @@ (defvar isearch-lazy-highlight-window-st (defvar isearch-lazy-highlight-window-end nil) (defvar isearch-lazy-highlight-case-fold-search nil) (defvar isearch-lazy-highlight-regexp nil) -(defvar isearch-lazy-highlight-space-regexp nil) +(defvar isearch-lazy-highlight-whitespace nil) +(defvar isearch-lazy-highlight-whitespace-regexp nil) (defvar isearch-lazy-highlight-word nil) (defvar isearch-lazy-highlight-forward nil) (defvar isearch-lazy-highlight-error nil) @@ -2847,6 +2985,10 @@ (defun isearch-lazy-highlight-new-loop ( isearch-regexp)) (not (eq isearch-lazy-highlight-word isearch-word)) + (not (eq isearch-lazy-highlight-whitespace + isearch-ignore-whitespace)) + (not (eq isearch-lazy-highlight-whitespace-regexp + search-whitespace-regexp)) (not (= (window-start) isearch-lazy-highlight-window-start)) (not (= (window-end) ; Window may have been split/joined. @@ -2873,7 +3015,8 @@ (defun isearch-lazy-highlight-new-loop ( isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search isearch-lazy-highlight-regexp isearch-regexp - isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp) + isearch-lazy-highlight-whitespace isearch-ignore-whitespace + isearch-lazy-highlight-whitespace-regexp search-whitespace-regexp isearch-lazy-highlight-word isearch-word isearch-lazy-highlight-forward isearch-forward) (unless (equal isearch-string "") @@ -2887,7 +3030,8 @@ (defun isearch-lazy-highlight-search () (condition-case nil (let ((case-fold-search isearch-lazy-highlight-case-fold-search) (isearch-regexp isearch-lazy-highlight-regexp) - (search-spaces-regexp isearch-lazy-highlight-space-regexp) + (search-spaces-regexp (if isearch-lazy-highlight-whitespace + isearch-lazy-highlight-whitespace-regexp)) (isearch-word isearch-lazy-highlight-word) (search-invisible nil) ; don't match invisible text (retry t) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-31 9:31 ` Juri Linkov @ 2012-08-31 14:55 ` Chong Yidong 2012-09-01 0:47 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-31 14:55 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > Or do you think `-ignore-whitespace' implies a more general > functionality? > it would be also useful to completely ignore all whitespace > differences between the search string and the buffer text with the > following implementation: No, ignoring whitespace differences entirely is not desireable. If the user searches for the word "tome" and isearch hits on "to me", that would be annoying. That's why I suggested the suffix -lax-space-match. Or, if that is too wordy, maybe -lax will do (there's already word-search-*-lax but I think that's OK since this feature doesn't overlap with word search). Or maybe -lazy-spaces. Or feel free to suggest something better. The message for isearch-toggle-whitespace should not speak of "ignoring whitespace", for the same reason. > The prefix `isearch-' is not quite right because these functions > can be used in other packages like replace.el being bound to > `replace-search-function'. `search-' seems more right. Using the search- prefix for the functions is OK. Apart from the above terminology issues, the rest of the patch also looks OK. > When users bind `isearch-forward-regexp' to C-s and use regexp search > as simple search, they will miss this feature. So when leaving it, a > separate variable is needed to disable whitespace mode in regexp mode, > but to enable it in non-regexp simple mode by default. This requires > a new variable `isearch-regexp-ignore-whitespace' but it complicates > the functionality, so maybe it should be removed from the next version > of the patch? I think the simplest, most backward compatible solution is simply to allow search-whitespace-regexp to take a cons cell value :-P Sure, a cons cell is not extensible, but is there any forseeable way in which we'd want to extend this beyond simply distinguishing ordinary and regexp isearch? The feature does not overlap with word search, so that seems pretty irrelevant. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-31 14:55 ` Chong Yidong @ 2012-09-01 0:47 ` Juri Linkov 2012-09-01 3:15 ` Chong Yidong 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-09-01 0:47 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel > No, ignoring whitespace differences entirely is not desireable. > If the user searches for the word "tome" and isearch hits on "to me", > that would be annoying. It doesn't ignore empty whitespace differences because `search-whitespace-regexp' matches non-empty strings as a 1+ sequence of whitespace with "\\s-+". Of course, changing it to "\\s-*" would be annoying. But what I meant is that the current C implementation of `search-spaces-regexp' can be converted to Lisp as: (defun search-forward-ignore-whitespace (string &optional bound noerror count) (re-search-forward (search-whitespace-regexp (regexp-quote string)) bound noerror count)) (defun search-whitespace-regexp (string) (replace-regexp-in-string " +" search-whitespace-regexp string nil t)) whereas it would be also very useful to have (defun search-whitespace-regexp (string) (replace-regexp-in-string "\\s-+" search-whitespace-regexp string nil t)) that matches a non-empty sequence of whitespace, not just spaces. So what I think is that this matching regexp could be configurable with the default value " +". > That's why I suggested the suffix -lax-space-match. Or, if that is too > wordy, maybe -lax will do (there's already word-search-*-lax but I think > that's OK since this feature doesn't overlap with word search). Or > maybe -lazy-spaces. Or feel free to suggest something better. The reason why I think that related function and variable names should contain the word `whitespace' is because it will connect it with the already existing `search-whitespace-regexp'. OTOH, the suffix `-lax' is short and has no limited meaning, so maybe it would be good to have names like: (defcustom search-whitespace-regexp (defvar isearch-whitespace-lax (defun isearch-toggle-whitespace-lax (defun search-forward-whitespace-lax (defun search-backward-whitespace-lax > The message for isearch-toggle-whitespace should not speak of "ignoring > whitespace", for the same reason. One message for `isearch-toggle-whitespace' was taken from the defcustom definition of `search-whitespace-regexp' to display the same meaning as "treat spaces literally". Another message to enable this feature could display something more meaningful too like "space matches a sequence of whitespace chars". > I think the simplest, most backward compatible solution is simply to > allow search-whitespace-regexp to take a cons cell value :-P I meant that supporting lax whitespace in regexp mode makes functionality more complicated because of adding special conditions in `isearch-toggle-whitespace', `isearch-query-replace', `isearch-occur', `isearch-search-fun-default'. But configuring it with a cons cell makes it more complicated. So the question was rather do we need to support lax whitespace in regexp mode at all? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-09-01 0:47 ` Juri Linkov @ 2012-09-01 3:15 ` Chong Yidong 2012-09-01 11:50 ` Juri Linkov 0 siblings, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-09-01 3:15 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > It doesn't ignore empty whitespace differences because > `search-whitespace-regexp' matches non-empty strings as a 1+ sequence > of whitespace with "\\s-+". Of course, changing it to "\\s-*" would > be annoying. Right, but the phrase "ignore whitespace" seems to indicate completely ignoring whitespace differences *in the search string*, including empty whitespace differences. So it is a poor name. > The reason why I think that related function and variable names > should contain the word `whitespace' is because it will connect it > with the already existing `search-whitespace-regexp'. I see your point. The naming system for `search-spaces-regexp' and `search-whitespace-regexp' is badly muddled, but I guess we have to live with it. How about -lazy-whitespace or -lax-whitespace? Then the command would be isearch-toggle-lazy-whitespace or isearch-toggle-lax-whitespace. > One message for `isearch-toggle-whitespace' was taken from the defcustom > definition of `search-whitespace-regexp' to display the same meaning as > "treat spaces literally". Instead of "treat spaces literally", I think "match spaces literally" would be more accurate. The opposite message could be "match spaces loosely", which is about the best we can do in a short message, I think. > So the question was rather do we need to support lax whitespace in > regexp mode at all? I don't think we should remove the feature outright, so there ought to be some way to enable it for regexp mode. Adding some complication to the code for this purpose is fine. That is to say, even if we change things so that C-M-s does not do lax space matching by default, it should be easy to get the feature back (by customizing a variable), just in case some user somewhere depends on the feature. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-09-01 3:15 ` Chong Yidong @ 2012-09-01 11:50 ` Juri Linkov 2012-09-01 16:02 ` Chong Yidong 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-09-01 11:50 UTC (permalink / raw) To: Chong Yidong; +Cc: Stefan Monnier, emacs-devel > Right, but the phrase "ignore whitespace" seems to indicate completely > ignoring whitespace differences *in the search string*, including empty > whitespace differences. So it is a poor name. In Diff this option is called --ignore-space-change that ignores changes in the amount of white space, but this name is too long. > How about -lazy-whitespace or -lax-whitespace? Then the command would > be isearch-toggle-lazy-whitespace or isearch-toggle-lax-whitespace. Then the names of search functions would be: lax-whitespace-search-forward - for simple search, and re-lax-whitespace-search-forward - for regexp search. And "re-lax" is not a synonym for "lazy" :-) In programming "lazy" means delayed evaluation, so it's not applicable here (but isearch-lazy-highlight fits this definition because it delays the evaluation of highlighting for other matches). Using the same naming convention as in word-search-forward-lax like whitespace-search-forward-lax or whitespace-lax-search-forward is also not possible because as you said the whitespace- prefix is reserved for whitespace.el. Thus the remaining possibility is to add -lax-whitespace as the suffix like: search-forward-lax-whitespace re-search-forward-lax-whitespace that is implemented in the patch below. If it's basically OK then I'd like to install it, so you could make more necessary changes. >> So the question was rather do we need to support lax whitespace in >> regexp mode at all? > > I don't think we should remove the feature outright, so there ought to > be some way to enable it for regexp mode. Adding some complication to > the code for this purpose is fine. > > That is to say, even if we change things so that C-M-s does not do lax > space matching by default, it should be easy to get the feature back (by > customizing a variable), just in case some user somewhere depends on the > feature. With a separate variable for regexp lax matching like `isearch-regexp-lax-whitespace' it will be easy to enable/disable it and also easier to mark it obsolete later before removing the feature. === modified file 'lisp/isearch.el' --- lisp/isearch.el 2012-08-27 04:08:32 +0000 +++ lisp/isearch.el 2012-09-01 11:47:01 +0000 @@ -120,20 +120,10 @@ (defcustom search-whitespace-regexp (pur incremental search. If the value is nil, each space you type matches literally, against one space. -The value can also be a cons cell (REGEXP-1 . REGEXP-2). In that -case, REGEXP-1 is used as the value for ordinary incremental -search, and REGEXP-2 is used for regexp incremental search. - You might want to use something like \"[ \\t\\r\\n]+\" instead. In the Customization buffer, that is `[' followed by a space, a tab, a carriage return (control-M), a newline, and `]+'." :type '(choice (const :tag "Treat Spaces Literally" nil) - (cons (choice :tag "For Ordinary Isearch" - regexp - (const :tag "Treat Spaces Literally" nil)) - (choice :tag "For Regexp Isearch" - regexp - (const :tag "Treat Spaces Literally" nil))) regexp) :group 'isearch :version "24.3") @@ -510,6 +512,7 @@ (defvar isearch-mode-map (define-key map "\M-r" 'isearch-toggle-regexp) (define-key map "\M-e" 'isearch-edit-string) + (define-key map "\M-s " 'isearch-toggle-lax-whitespace) (define-key map "\M-sc" 'isearch-toggle-case-fold) (define-key map "\M-sr" 'isearch-toggle-regexp) (define-key map "\M-sw" 'isearch-toggle-word) @@ -556,6 +564,17 @@ (defvar isearch-word nil The property `isearch-message-prefix' put on this function specifies the prefix string displayed in the search message.") +(defvar isearch-lax-whitespace t + "If non-nil, a space will match a sequence of whitespace chars. +When you enter a space or spaces in the incremental search, it +will match any sequence matched by the regexp in the variable +`search-whitespace-regexp'. +If the value is nil, each space you type matches literally, +against one space.") + +(defvar isearch-regexp-lax-whitespace nil + "Like `isearch-lax-whitespace' but for regexp mode.") + (defvar isearch-cmds nil "Stack of search status sets. Each set is a vector of the form: @@ -1409,6 +1434,24 @@ (defun isearch-toggle-case-fold () (sit-for 1) (isearch-update)) +(defun isearch-toggle-lax-whitespace () + "Toggle whitespace matching in searching on or off." + (interactive) + (if isearch-regexp + (setq isearch-regexp-lax-whitespace (not isearch-regexp-lax-whitespace)) + (setq isearch-lax-whitespace (not isearch-lax-whitespace))) + (let ((message-log-max nil)) + (message "%s%s [%s]" + (isearch-message-prefix nil isearch-nonincremental) + isearch-message + (if (if isearch-regexp + isearch-regexp-lax-whitespace + isearch-lax-whitespace) + "match spaces loosely" + "match spaces literally"))) + (setq isearch-success t isearch-adjusted t) + (sit-for 1) + (isearch-update)) \f ;; Word search @@ -1506,6 +1560,24 @@ (defun isearch-symbol-regexp (string &op (put 'isearch-symbol-regexp 'isearch-message-prefix "symbol ") +;; Search with lax whitespace + +(defun search-forward-lax-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-forward (regexp-quote string) bound noerror count))) + +(defun search-backward-lax-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-backward (regexp-quote string) bound noerror count))) + +(defun re-search-forward-lax-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-forward string bound noerror count))) + +(defun re-search-backward-lax-whitespace (string &optional bound noerror count) + (let ((search-spaces-regexp search-whitespace-regexp)) + (re-search-backward string bound noerror count))) + \f (defun isearch-query-replace (&optional delimited regexp-flag) "Start `query-replace' with string to replace from last search string. @@ -1522,6 +1594,14 @@ (defun isearch-query-replace (&optional ;; set `search-upper-case' to nil to not call ;; `isearch-no-upper-case-p' in `perform-replace' (search-upper-case nil) + (replace-search-function + (if (and isearch-lax-whitespace (not regexp-flag)) + #'search-forward-lax-whitespace + replace-search-function)) + (replace-re-search-function + (if (and isearch-regexp-lax-whitespace regexp-flag) + #'re-search-forward-lax-whitespace + replace-re-search-function)) ;; Set `isearch-recursive-edit' to nil to prevent calling ;; `exit-recursive-edit' in `isearch-done' that terminates ;; the execution of this command when it is non-nil. @@ -1558,15 +1638,6 @@ (defun isearch-query-replace-regexp (&op (list current-prefix-arg)) (isearch-query-replace delimited t)) -(defun isearch-whitespace-regexp () - "Return the value of `search-whitespace-regexp' for the current search." - (cond ((not (consp search-whitespace-regexp)) - search-whitespace-regexp) - (isearch-regexp - (cdr search-whitespace-regexp)) - (t - (car search-whitespace-regexp)))) - (defun isearch-occur (regexp &optional nlines) "Run `occur' using the last search string as the regexp. Interactively, REGEXP is constructed using the search string from the @@ -1606,7 +1677,11 @@ (defun isearch-occur (regexp &optional n ;; Set `search-upper-case' to nil to not call ;; `isearch-no-upper-case-p' in `occur-1'. (search-upper-case nil) - (search-spaces-regexp (isearch-whitespace-regexp))) + (search-spaces-regexp + (if (if isearch-regexp + isearch-regexp-lax-whitespace + isearch-lax-whitespace) + search-whitespace-regexp))) (occur regexp nlines))) (declare-function hi-lock-read-face-name "hi-lock" ()) @@ -2203,7 +2285,7 @@ (defun isearch-quote-char () ;; Assume character codes 0200 - 0377 stand for characters in some ;; single-byte character set, and convert them to Emacs ;; characters. - (if (and isearch-regexp (= char ?\s)) + (if (and isearch-regexp isearch-regexp-lax-whitespace (= char ?\s)) (if (subregexp-context-p isearch-string (length isearch-string)) (isearch-process-search-string "[ ]" " ") (isearch-process-search-char char)) @@ -2443,16 +2533,19 @@ (defun isearch-search-fun-default () (funcall isearch-word string lax) (word-search-regexp string lax)) bound noerror count)))) + ((and isearch-regexp isearch-regexp-lax-whitespace + search-whitespace-regexp) + (if isearch-forward + 're-search-forward-lax-whitespace + 're-search-backward-lax-whitespace)) (isearch-regexp (if isearch-forward 're-search-forward 're-search-backward)) + ((and isearch-lax-whitespace search-whitespace-regexp) + (if isearch-forward + 'search-forward-lax-whitespace + 'search-backward-lax-whitespace)) (t - (if isearch-forward 'isearch-search-forward 'isearch-search-backward)))) - -(defun isearch-search-forward (string &optional bound noerror count) - (re-search-forward (regexp-quote string) bound noerror count)) - -(defun isearch-search-backward (string &optional bound noerror count) - (re-search-backward (regexp-quote string) bound noerror count)) + (if isearch-forward 'search-forward 'search-backward)))) (defun isearch-search-string (string bound noerror) "Search for the first occurrence of STRING or its translation. @@ -2503,17 +2596,13 @@ (defun isearch-search () search-invisible)) (inhibit-quit nil) (case-fold-search isearch-case-fold-search) - (search-spaces-regexp (isearch-whitespace-regexp)) (retry t)) (setq isearch-error nil) (while retry @@ -2805,7 +2941,8 @@ (defvar isearch-lazy-highlight-window-st (defvar isearch-lazy-highlight-window-end nil) (defvar isearch-lazy-highlight-case-fold-search nil) (defvar isearch-lazy-highlight-regexp nil) -(defvar isearch-lazy-highlight-space-regexp nil) +(defvar isearch-lazy-highlight-lax-whitespace nil) +(defvar isearch-lazy-highlight-regexp-lax-whitespace nil) (defvar isearch-lazy-highlight-word nil) (defvar isearch-lazy-highlight-forward nil) (defvar isearch-lazy-highlight-error nil) @@ -2847,6 +2984,10 @@ (defun isearch-lazy-highlight-new-loop ( isearch-regexp)) (not (eq isearch-lazy-highlight-word isearch-word)) + (not (eq isearch-lazy-highlight-lax-whitespace + isearch-lax-whitespace)) + (not (eq isearch-lazy-highlight-regexp-lax-whitespace + isearch-regexp-lax-whitespace)) (not (= (window-start) isearch-lazy-highlight-window-start)) (not (= (window-end) ; Window may have been split/joined. @@ -2873,7 +3014,8 @@ (defun isearch-lazy-highlight-new-loop ( isearch-lazy-highlight-last-string isearch-string isearch-lazy-highlight-case-fold-search isearch-case-fold-search isearch-lazy-highlight-regexp isearch-regexp - isearch-lazy-highlight-space-regexp (isearch-whitespace-regexp) + isearch-lazy-highlight-lax-whitespace isearch-lax-whitespace + isearch-lazy-highlight-regexp-lax-whitespace isearch-regexp-lax-whitespace isearch-lazy-highlight-word isearch-word isearch-lazy-highlight-forward isearch-forward) (unless (equal isearch-string "") @@ -2887,7 +3029,6 @@ (defun isearch-lazy-highlight-search () (condition-case nil (let ((case-fold-search isearch-lazy-highlight-case-fold-search) (isearch-regexp isearch-lazy-highlight-regexp) - (search-spaces-regexp isearch-lazy-highlight-space-regexp) (isearch-word isearch-lazy-highlight-word) (search-invisible nil) ; don't match invisible text (retry t) ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-09-01 11:50 ` Juri Linkov @ 2012-09-01 16:02 ` Chong Yidong 0 siblings, 0 replies; 56+ messages in thread From: Chong Yidong @ 2012-09-01 16:02 UTC (permalink / raw) To: Juri Linkov; +Cc: Stefan Monnier, emacs-devel Juri Linkov <juri@jurta.org> writes: > search-forward-lax-whitespace > re-search-forward-lax-whitespace > > that is implemented in the patch below. > > If it's basically OK then I'd like to install it, > so you could make more necessary changes. This patch looks fine, please go ahead. Thanks for writing it. > With a separate variable for regexp lax matching like > `isearch-regexp-lax-whitespace' it will be easy to enable/disable it > and also easier to mark it obsolete later before removing the feature. I'm fine with that. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 8:30 ` Juri Linkov 2012-08-28 12:53 ` Stefan Monnier @ 2012-08-29 6:46 ` Chong Yidong 2012-08-29 8:28 ` Juri Linkov 1 sibling, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-29 6:46 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov <juri@jurta.org> writes: >> The magic of `C-q SPC' is missing for non-regexp searches though. > > `C-q SPC' inserts "[ ]" in regexp search. The problem for non-regexp > search is how to avoid quoting "[ ]" in `regexp-quote'. Good point. Here's how to handle this: when isearch-regexp is nil, make isearch-process-search-string call regexp-quote for each addition to the search string; then have isearch-quote-char suppress quoting by passing an optional arg to isearch-process-search-string. Then in isearch-search-fun-default, we can use re-search-forward for plain isearch as well, since the search string will have been appropriately quoted when processed. See attached patch. *** lisp/isearch.el 2012-08-26 04:08:32 +0000 --- lisp/isearch.el 2012-08-29 06:38:42 +0000 *************** *** 2200,2217 **** "Quote special characters for incremental search." (interactive) (let ((char (read-quoted-char (isearch-message t)))) ! ;; Assume character codes 0200 - 0377 stand for characters in some ! ;; single-byte character set, and convert them to Emacs ! ;; characters. ! (if (and isearch-regexp (= char ?\s)) ! (if (subregexp-context-p isearch-string (length isearch-string)) ! (isearch-process-search-string "[ ]" " ") ! (isearch-process-search-char char)) (and enable-multibyte-characters (>= char ?\200) (<= char ?\377) (setq char (unibyte-char-to-multibyte char))) ! (isearch-process-search-char char)))) (defun isearch-printing-char () "Add this ordinary printing character to the search string and search." --- 2200,2222 ---- "Quote special characters for incremental search." (interactive) (let ((char (read-quoted-char (isearch-message t)))) ! (cond ! ((/= char ?\s) ! ;; Assume character codes 0200 - 0377 stand for characters in ! ;; some single-byte character set, and convert them to Emacs ! ;; characters. (and enable-multibyte-characters (>= char ?\200) (<= char ?\377) (setq char (unibyte-char-to-multibyte char))) ! (isearch-process-search-char char)) ! ((and isearch-regexp ! (null (subregexp-context-p isearch-string ! (length isearch-string)))) ! (isearch-process-search-char char)) ! ;; Handle C-q SPC by disabling `search-whitespace-regexp' match. ! (t ! (isearch-process-search-string "[ ]" " " t))))) (defun isearch-printing-char () "Add this ordinary printing character to the search string and search." *************** *** 2239,2245 **** (char-to-string char) (isearch-text-char-description char)))) ! (defun isearch-process-search-string (string message) (setq isearch-string (concat isearch-string string) isearch-message (concat isearch-message message)) (isearch-search-and-update)) --- 2244,2252 ---- (char-to-string char) (isearch-text-char-description char)))) ! (defun isearch-process-search-string (string message &optional no-quote) ! (unless (or isearch-regexp no-quote) ! (setq string (regexp-quote string))) (setq isearch-string (concat isearch-string string) isearch-message (concat isearch-message message)) (isearch-search-and-update)) *************** *** 2443,2458 **** (funcall isearch-word string lax) (word-search-regexp string lax)) bound noerror count)))) - (isearch-regexp - (if isearch-forward 're-search-forward 're-search-backward)) (t ! (if isearch-forward 'isearch-search-forward 'isearch-search-backward)))) ! ! (defun isearch-search-forward (string &optional bound noerror count) ! (re-search-forward (regexp-quote string) bound noerror count)) ! ! (defun isearch-search-backward (string &optional bound noerror count) ! (re-search-backward (regexp-quote string) bound noerror count)) (defun isearch-search-string (string bound noerror) "Search for the first occurrence of STRING or its translation. --- 2450,2457 ---- (funcall isearch-word string lax) (word-search-regexp string lax)) bound noerror count)))) (t ! (if isearch-forward 're-search-forward 're-search-backward)))) (defun isearch-search-string (string bound noerror) "Search for the first occurrence of STRING or its translation. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 6:46 ` Chong Yidong @ 2012-08-29 8:28 ` Juri Linkov 2012-08-29 13:55 ` Stefan Monnier 0 siblings, 1 reply; 56+ messages in thread From: Juri Linkov @ 2012-08-29 8:28 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel >>> The magic of `C-q SPC' is missing for non-regexp searches though. >> >> `C-q SPC' inserts "[ ]" in regexp search. The problem for non-regexp >> search is how to avoid quoting "[ ]" in `regexp-quote'. > > Good point. Here's how to handle this: when isearch-regexp is nil, make > isearch-process-search-string call regexp-quote for each addition to the > search string; then have isearch-quote-char suppress quoting by passing > an optional arg to isearch-process-search-string. > > Then in isearch-search-fun-default, we can use re-search-forward for > plain isearch as well, since the search string will have been > appropriately quoted when processed. See attached patch. Unfortunately, this will expose the regexp used in non-regexp search in such cases as editing the search string with M-e or repeating the previous search from the search ring. All special regexp characters will be displayed as quoted with \. This will mean that there is no more plain non-regexp search from the user's point of view. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 8:28 ` Juri Linkov @ 2012-08-29 13:55 ` Stefan Monnier 2012-08-29 15:11 ` Dani Moncayo 2012-08-29 23:51 ` Juri Linkov 0 siblings, 2 replies; 56+ messages in thread From: Stefan Monnier @ 2012-08-29 13:55 UTC (permalink / raw) To: Juri Linkov; +Cc: Chong Yidong, emacs-devel > Unfortunately, this will expose the regexp used in non-regexp search > in such cases as editing the search string with M-e or repeating > the previous search from the search ring. All special regexp characters > will be displayed as quoted with \. This will mean that there is no more > plain non-regexp search from the user's point of view. Agreed. It will also show up when you hit M-% or similarly reuse the last search string in things like occur. It can all be fixed with more code, but it complicates everything for very little benefit. I'd rather we just don't bother with search-whitespace-regexp in the default isearch behavior, especially since nobody actually requested it, AFAICT (at best, people pointed out that it seems counterintuitive to have it in regexp-search but not in the normal search). Stefan ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 13:55 ` Stefan Monnier @ 2012-08-29 15:11 ` Dani Moncayo 2012-08-29 23:51 ` Juri Linkov 1 sibling, 0 replies; 56+ messages in thread From: Dani Moncayo @ 2012-08-29 15:11 UTC (permalink / raw) To: Stefan Monnier; +Cc: Juri Linkov, Chong Yidong, emacs-devel > I'd rather we just don't bother with search-whitespace-regexp in the > default isearch behavior, especially since nobody actually requested > it, AFAICT (at best, people pointed out that it seems counterintuitive > to have it in regexp-search but not in the normal search). FWIW, I am _very_ interested in this feature. Having the ability of using it at will both in basic and regexp search (and replace) commands is a very useful feature which I'll use everyday. And I'm convinced many other people will use it too. -- Dani Moncayo ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 13:55 ` Stefan Monnier 2012-08-29 15:11 ` Dani Moncayo @ 2012-08-29 23:51 ` Juri Linkov 1 sibling, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-29 23:51 UTC (permalink / raw) To: Stefan Monnier; +Cc: Chong Yidong, emacs-devel > It will also show up when you hit M-% or similarly reuse the > last search string in things like occur. Bug#10885 should be fixed anyway even for the old functionality of using whitespace in isearch-regexp because currently when replacement is started from isearch-regexp it doesn't find the same matches as isearch. > It can all be fixed with more code, but it complicates everything for > very little benefit. I believe adding whitespace mode (implemented like `isearch-toggle-word' or `isearch-toggle-case-fold') and without quoting literal spaces will simplify existing functionality that is currently inconsistent and hardly customizable. Other related programs have two counterpart options to ignore case and ignore whitespace like e.g. Diff with --ignore-case and --ignore-all-space or in Emacs two options `compare-ignore-case' and `compare-ignore-whitespace'. The functionality to ignore case is well supported in search and replace with the command `isearch-toggle-case-fold' and the user options `search-upper-case' in isearch, and `case-replace' in replace. But ignoring whitespace is underdeveloped in search and replace. I think just replicating the same options for whitespace will fill this gap in functionality. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-26 4:06 ` Chong Yidong ` (2 preceding siblings ...) 2012-08-27 18:34 ` Johan Bockgård @ 2012-08-28 8:27 ` Juri Linkov 2012-08-29 6:59 ` Chong Yidong 2012-08-30 9:01 ` Chong Yidong 3 siblings, 2 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-28 8:27 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > It is now possible to change the variable `search-whitespace-regexp' and > give it a cons cell value, which specifies different behaviors for > ordinary and regexp isearch. I think a cons cell is an unsuitable data structure for this customization. It has no room for extension. For example, it makes sense to add a value for word search that currently is hard-coded in `word-search-regexp' as "\\W+", but there is no clean way to add it to this user option. A better approach is to have two separate user options for ordinary and regexp search whitespace like: (defcustom search-whitespace-regexp "\\s-+" ... (defcustom re-search-whitespace-regexp search-whitespace-regexp ... `re-search-whitespace-regexp' inheriting its default value from `search-whitespace-regexp' will provide backward-compatibility for users who already customized the old variable. Then later a new user option could be easily added for `word-search-regexp' like: (defcustom word-search-whitespace-regexp "\\W+" ... Also I'm concerned about `re-search-forward' being slower than `search-forward' for plain strings. Could it be optimized to use `search-forward' instead of `re-search-backward' in non-regexp isearch at least in these three cases: 1. When there are no spaces in the search string; 2. When the user typed `C-q SPC'; 3. When the user option `search-whitespace-regexp' is nil? ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 8:27 ` Juri Linkov @ 2012-08-29 6:59 ` Chong Yidong 2012-08-29 8:34 ` Juri Linkov 2012-08-30 9:01 ` Chong Yidong 1 sibling, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-29 6:59 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov <juri@jurta.org> writes: > A better approach is to have two separate user options > for ordinary and regexp search whitespace like: > > (defcustom search-whitespace-regexp "\\s-+" > ... > > (defcustom re-search-whitespace-regexp search-whitespace-regexp > ... I'm OK with having two options, but the trouble is finding the right names: they need to have the right prefix. I don't like re-search-whitespace-regexp, because the name seems to indicate that it affects re-search-forward the Lisp function, rather than the incremental regexp search user-level feature. (Note that search-whitespace-regexp is similarly poorly named). Maybe isearch-spaces-regexp and isearch-regexp-spaces-regexp, with search-whitespace-regexp an obsolete alias for the latter? Though isearch-regexp-spaces-regexp sounds a bit weird. > Also I'm concerned about `re-search-forward' being slower than > `search-forward' for plain strings. Someone mentioned that he had replaced C-s with isearch-forward-regexp for a long time, without any ill effects. Let's revisit the speed issue iff it actually bites in practice. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-29 6:59 ` Chong Yidong @ 2012-08-29 8:34 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-29 8:34 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > I'm OK with having two options, but the trouble is finding the right > names: they need to have the right prefix. I don't like > re-search-whitespace-regexp, because the name seems to indicate that it > affects re-search-forward the Lisp function, rather than the incremental > regexp search user-level feature. (Note that search-whitespace-regexp > is similarly poorly named). > > Maybe isearch-spaces-regexp and isearch-regexp-spaces-regexp, with > search-whitespace-regexp an obsolete alias for the latter? Though > isearch-regexp-spaces-regexp sounds a bit weird. There are other variables that have the `search-' prefix instead of `isearch-'. I don't know why. But when using the same naming convention as is used in `search-ring' and `regexp-search-ring', or in `search-ring-max' and `regexp-search-ring-max', or in `search-ring-yank-pointer' and `regexp-search-ring-yank-pointer' etc. then the variable names would be: `search-whitespace-regexp' and `regexp-search-whitespace-regexp'. I have no opinion about the `isearch-' prefix but at least these names will be consistent with other search variable names. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-28 8:27 ` Juri Linkov 2012-08-29 6:59 ` Chong Yidong @ 2012-08-30 9:01 ` Chong Yidong 2012-08-30 9:18 ` Juri Linkov 1 sibling, 1 reply; 56+ messages in thread From: Chong Yidong @ 2012-08-30 9:01 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel Juri Linkov <juri@jurta.org> writes: > (defcustom search-whitespace-regexp "\\s-+" > ... > > (defcustom re-search-whitespace-regexp search-whitespace-regexp > ... > > `re-search-whitespace-regexp' inheriting its default value > from `search-whitespace-regexp' will provide backward-compatibility > for users who already customized the old variable. This trick to preserve backward compatibility doesn't work for isearch.el's defcustoms, because they are loaded by default. So if the user customizes `search-whitespace-regexp', a new `regexp-search-whitespace-regexp' in isearch.el would end up with the default value of s-w-r, not the customized value. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-30 9:01 ` Chong Yidong @ 2012-08-30 9:18 ` Juri Linkov 0 siblings, 0 replies; 56+ messages in thread From: Juri Linkov @ 2012-08-30 9:18 UTC (permalink / raw) To: Chong Yidong; +Cc: emacs-devel > This trick to preserve backward compatibility doesn't work for > isearch.el's defcustoms, because they are loaded by default. So if the > user customizes `search-whitespace-regexp', a new > `regexp-search-whitespace-regexp' in isearch.el would end up with the > default value of s-w-r, not the customized value. Actually I see no need to have two separate values of whitespace regexps. What is needed more is a new option to enable/disable this feature without changing the value of `search-whitespace-regexp'. Then its default value could depend on the major mode. For instance, the users might want to enable whitespace mode in Text mode, Help mode and Info mode, but not in other modes. This will be easy to do in hooks setting a buffer-local value of the new variable `search-whitespace' (or `whitespace-search'). So it will have the same flexibility as its counterpart option `case-fold-search' (but its isearch implementation will be different because currently whitespace mode is applicable only to regexp search). ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? @ 2012-08-14 23:45 Dmitry Gutov 0 siblings, 0 replies; 56+ messages in thread From: Dmitry Gutov @ 2012-08-14 23:45 UTC (permalink / raw) To: bzg; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: > I just found out that > > C-u C-s [a-z]\. [A-Z] > > matches more than one space character. > > Is this a bug? > > How can I search only one space character? The docstring for `isearch-forward-regexp' says: In regexp incremental searches, a space or spaces normally matches any whitespace (the variable `search-whitespace-regexp' controls precisely what that means). If you want to search for a literal space and nothing else, enter C-q SPC. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Interpretation of a space in regexp isearch? @ 2012-08-14 23:03 Bastien 2012-08-14 23:45 ` Davis Herring 0 siblings, 1 reply; 56+ messages in thread From: Bastien @ 2012-08-14 23:03 UTC (permalink / raw) To: emacs-devel Hi, I just found out that C-u C-s [a-z]\. [A-Z] matches more than one space character. Is this a bug? How can I search only one space character? Thanks! -- Bastien ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-14 23:03 Bastien @ 2012-08-14 23:45 ` Davis Herring 2012-08-14 23:53 ` Bastien 0 siblings, 1 reply; 56+ messages in thread From: Davis Herring @ 2012-08-14 23:45 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel > I just found out that > > C-u C-s [a-z]\. [A-Z] > > matches more than one space character. > > Is this a bug? It's a feature, but I don't remember how to change it at the moment. `search-spaces-regexp' is almost it. > How can I search only one space character? > > Thanks! Put it in a character class ("[ ]"). Davis -- This product is sold by volume, not by mass. If it appears too dense or too sparse, it is because mass-energy conversion has occurred during shipping. ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-14 23:45 ` Davis Herring @ 2012-08-14 23:53 ` Bastien 2012-08-15 3:42 ` Chong Yidong 0 siblings, 1 reply; 56+ messages in thread From: Bastien @ 2012-08-14 23:53 UTC (permalink / raw) To: Davis Herring; +Cc: emacs-devel Davis Herring <herring@lanl.gov> writes: > It's a feature, but I don't remember how to change it at the moment. > `search-spaces-regexp' is almost it. Yep -- it's ̀search-whitespace-regexp'. Dmitry Gutov <dgutov@yandex.ru> writes: > The docstring for `isearch-forward-regexp' says: > > In regexp incremental searches, a space or spaces normally matches any > whitespace (the variable `search-whitespace-regexp' controls precisely > what that means). If you want to search for a literal space and > nothing else, enter C-q SPC. That's it, thanks! -- Bastien ^ permalink raw reply [flat|nested] 56+ messages in thread
* Re: Interpretation of a space in regexp isearch? 2012-08-14 23:53 ` Bastien @ 2012-08-15 3:42 ` Chong Yidong 0 siblings, 0 replies; 56+ messages in thread From: Chong Yidong @ 2012-08-15 3:42 UTC (permalink / raw) To: Bastien; +Cc: emacs-devel Bastien <bzg@gnu.org> writes: > Davis Herring <herring@lanl.gov> writes: > >> It's a feature, but I don't remember how to change it at the moment. >> `search-spaces-regexp' is almost it. > > Yep -- it's ̀search-whitespace-regexp'. FWIW, I've long been of the opinion that this feature is exactly backward. The `search-whitespace-regexp' whitespace matching feature should apply to ordinary incremental search, and it should *not* apply to regexp incremental search. ^ permalink raw reply [flat|nested] 56+ messages in thread
end of thread, other threads:[~2012-09-01 16:02 UTC | newest] Thread overview: 56+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-08-15 4:40 Interpretation of a space in regexp isearch? Dmitry Gutov 2012-08-15 5:27 ` Bastien 2012-08-15 9:11 ` Dani Moncayo 2012-08-15 9:13 ` Dani Moncayo 2012-08-15 9:19 ` Dani Moncayo 2012-08-15 13:59 ` Drew Adams 2012-08-15 14:31 ` Davis Herring 2012-08-15 16:43 ` Drew Adams 2012-08-15 17:54 ` Davis Herring 2012-08-15 22:53 ` Dmitry Gutov 2012-08-15 23:21 ` Drew Adams 2012-08-16 2:25 ` Dmitry Gutov 2012-08-16 5:37 ` Drew Adams 2012-08-26 4:06 ` Chong Yidong 2012-08-26 6:59 ` Bastien 2012-08-26 15:19 ` Dani Moncayo 2012-08-26 17:31 ` Dani Moncayo 2012-08-28 8:28 ` Juri Linkov 2012-08-28 9:07 ` Dani Moncayo 2012-08-28 23:01 ` Juri Linkov 2012-08-27 18:34 ` Johan Bockgård 2012-08-28 8:30 ` Juri Linkov 2012-08-28 12:53 ` Stefan Monnier 2012-08-28 22:54 ` Juri Linkov 2012-08-28 23:52 ` Drew Adams 2012-08-29 8:38 ` Juri Linkov 2012-08-29 16:01 ` Drew Adams 2012-08-29 23:49 ` Juri Linkov 2012-08-30 8:19 ` Chong Yidong 2012-08-30 8:31 ` Chong Yidong 2012-08-30 8:54 ` Juri Linkov 2012-08-30 14:47 ` Stefan Monnier 2012-08-31 0:02 ` Juri Linkov 2012-08-31 0:07 ` Juri Linkov 2012-08-31 5:40 ` Chong Yidong 2012-08-31 9:31 ` Juri Linkov 2012-08-31 14:55 ` Chong Yidong 2012-09-01 0:47 ` Juri Linkov 2012-09-01 3:15 ` Chong Yidong 2012-09-01 11:50 ` Juri Linkov 2012-09-01 16:02 ` Chong Yidong 2012-08-29 6:46 ` Chong Yidong 2012-08-29 8:28 ` Juri Linkov 2012-08-29 13:55 ` Stefan Monnier 2012-08-29 15:11 ` Dani Moncayo 2012-08-29 23:51 ` Juri Linkov 2012-08-28 8:27 ` Juri Linkov 2012-08-29 6:59 ` Chong Yidong 2012-08-29 8:34 ` Juri Linkov 2012-08-30 9:01 ` Chong Yidong 2012-08-30 9:18 ` Juri Linkov -- strict thread matches above, loose matches on Subject: below -- 2012-08-14 23:45 Dmitry Gutov 2012-08-14 23:03 Bastien 2012-08-14 23:45 ` Davis Herring 2012-08-14 23:53 ` Bastien 2012-08-15 3:42 ` Chong Yidong
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.