> It has support for isearch (use turn-on-fuzzy-isearch).
Thanks, I'll take a look.
In the meantime I came up with a quick and dirty solution to see
how useful a similar feature could be in standard isearch.
It is a simple advice which automatically deletes non matching characters
immediately, so it does not allow building up bad characters
in the search string:
I tried a few searches and it seems useful. Why is the default
implementation leaves bad characters in the search string at all? It is not
very useful, because then you must delete them manually.
> I tried a few searches and it seems useful. Why is the default
> implementation leaves bad characters in the search string at all? It is not
> very useful, because then you must delete them manually.
It occured to me it is useful for overwrapped search when you hit the
end of the file, but then you can press C-s to search for the failed
string from the beginning.
On the other hand the above advice is quite useful when you only
want to search forward in the file without overwrapping, because
in this case collecting the nonmatching characters in the search
string is useless, because you have to delete them to fix the search
string.
So the best solution would be to somehow combine the two. Collect
the failed chars as usual to allow for quick overwrapping search,
but at the same time show those matches until the end of file
which can be found by ignoring the nonmatching chars in the search string, so the user does not have to delete them
manually to correct the search.
On Sat, Aug 25, 2012 at 2:38 AM, Tom <adatgyu...@gmail.com> wrote:
> The asker wants isearch to ignore the nonmatching character if
> a later character can be used for successful matching.
> What do you think? It sounds useful, not having to delete the
> problematic part, but simply typing the correct characters.
It sounds useful only until you actually try something that works that
way. Then you discover that, whenever you make a typo, your fingers
subconsciously press Backspace and correct the typo before your brain
even gets to realize that you “don’t have” to erase the wrong
character.
With the proposed change, the sequence of events becomes:
1. You type the prefix. The editor finds it.
2. You make a typo. The editor does not find the new string and
ignores the last character.
3. You press Backspace. Since your typo character was ignored, you end
up erasing the last character that was correct.
4. You enter the character that would correct the typo, and probably a
few more. For the purposes of isearch, it is added to the prefix
without its last character (which you involuntarily erased at step 3).
Most probably, the editor does not find the new string and drops your
correction character and whatever subsequent characters you enter.
Maybe even beeps at you, too.
5. You say “oh s#!t” and have to look at and think about your current
search string, to resume typing from the correct character.
> It sounds useful only until you actually try something that works that
> way. Then you discover that, whenever you make a typo, your fingers
> subconsciously press Backspace and correct the typo before your brain
> even gets to realize that you “don’t have” to erase the wrong
> character.
Yes, it may not work well, but I come to realize the fixing with
backspace part could be improved anyway.
Isearch should have a binding which deletes all the non-matching
characters from the search string. C-Backspace can be a good candidate
for that.
So instead of typing backspace several times, you could just press
C-Bakspace which would leave only the matching part of the search string.
> Isearch should have a binding which deletes all the non-matching
> characters from the search string. C-Backspace can be a good candidate
> for that.
> > Isearch should have a binding which deletes all the non-matching
> > characters from the search string. C-Backspace can be a good candidate
> > for that.
> It already has - `C-g'.
Cool, thanks. It never occurred to me to use C-g to fix the search
string. It's not a very intuitive binding, because it's usually
associated with aborting operations, not with correcting things.
> -----Original Message-----
> From: Tom
> Sent: Monday, August 27, 2012 8:23 AM
> To: help-gnu-em...@gnu.org
> Subject: Re: New feature idea: isearch with autocorrection
> > > Isearch should have a binding which deletes all the non-matching
> > > characters from the search string. C-Backspace can be a good candidate
> > > for that.
> > It already has - `C-g'.
> Cool, thanks. It never occurred to me to use C-g to fix the search
> string. It's not a very intuitive binding, because it's usually
> associated with aborting operations, not with correcting things.
I learned about this so long ago that my fingers sometimes do it without conscious thought, but I somehow _do_ associate this as an 'abort' of sorts: it's aborting the failing search, returning me to the successful search I had started. (I also agree it's not exactly intuitive, because the I-search itself continues. Pressing Control-G during a successful I-search aborts that too, of course, and at that point, there is no search running.)
> I learned about this so long ago that my fingers sometimes do > it without conscious thought, but I somehow _do_ associate > this as an 'abort' of sorts: it's aborting the failing > search, returning me to the successful search I had started.
> (I also agree it's not exactly intuitive, because the > I-search itself continues. Pressing Control-G during a > successful I-search aborts that too, of course, and at that > point, there is no search running.)
BTW, a related feature from Isearch+ was added to vanilla Emacs also: If you hit
`M-e' (to edit the search string), the cursor is moved to the mismatch position.
This is handy if you want to insert or change a char or two at that position,
for example.
(I took this idea from Icicles, where, when there is a completion mismatch, a
first `C-M-l' puts the cursor at the mismatch position. A second `C-M-l'
removes the mismatched suffix.)
I also have a comment wrt the idea of "autocorrecting" the search string (which
I am not enthusiastic about personally, although I do support encouraging a
hundred flowers to bloom):
Isearch is often started using a previous search string, and sometimes that is
done in a different, but perhaps related, context.
In such a situation, a previous search string, even if it does not match
anything, can be useful if there is a partial match - `M-e' is your friend.
IMO, it is not necessarily desirable to automatically throw away non-matching
chars.
(More generally, I am not a big fan of autocorrection elsewhere either.)
Yuri Khan <yuri.v.k...@gmail.com> writes:
> It sounds useful only until you actually try something that works that
> way. Then you discover that, whenever you make a typo, your fingers
> subconsciously press Backspace and correct the typo before your brain
> even gets to realize that you “don’t have” to erase the wrong
> character.
This is a BS answer. By this reasoning--don't judge a change on its
merits, rather on how I have to change my habits--we'd still be swinging
around in trees like our ancient ancestors.
BTW the link to fuzzy.el doesn't work, must have changed very recently
because even Google points to the incorrect location.
I haven't tried the proposed change but have this question: what about
when you're searching for a string and don't make a typo, rather, the
string isn't there? Isn't that the point of generating some sort of
error, rather than silently "fixing" it for you?
-- They made a wasteland and called it peace.
~ Tacitus
Bug Dout <bugg...@mailinator.com> writes:
> BTW the link to fuzzy.el doesn't work, must have changed very recently
> because even Google points to the incorrect location.
