On 26 Aug 2019, Drew Adams wrote: >OK. > >(But I can guess the outcome. It's OK; I can always >just add the enhancement to isearch+.el. It won't be >the first time.) Well, I can't say what the outcome would be, but in any case that shouldn't be affected by the order in which we do these things. >FYI, it doesn't do that in the parts that are doc. >Those patch parts still speak of `C-M-c'. Gah -- I rushed. Thank you for noticing that. New patch attached. >> * Make the search for the character case-sensitive. (Seems like a >> pretty obvious improvement, given the use cases: when the goal >> character is a letter at all, one is either looking at that letter on >> the screen *or* the letter is some known syntactic delimiter and its >> case is therefore known as well even if the letter is off the screen >> right now.) > >FWIW, I don't think that's really TRT. > >Personally, I have `case-fold-search' set to nil by >default, so that behavior isn't a problem for me. >But I don't think it should be part of this command. > >Users can toggle case-folding in Isearch easily. > >There's no reason to have this command make an >assumption about whether its char-search should be >case-sensitive. I don't think the either...or >assumption you made above is good for the command >to make. Better to let users control whether to >search for the char case-sensitively. When I think about the circumstances under which this command is actually used, which I tried to characterize above, I couldn't think of any in which case-insensitive matching would make sense -- speaking of just the char-match, of course, not the overall isearch. The overall isearch still obeys `isearch-case-fold-search'. When the user toggles case-folding in isearch, that should and does affect the isearch itself, but that isn't the same as the single-char match-and-yank-into-search-string we're talking about here. For the latter, case-sensitivity makes sense I think. Can you say which part of the assumptions I gave above seems wrong to you? Best regards, -Karl