Re: incr. search: skip duplicates on the same history event

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

On Jun 16,  8:31pm, Frank Terbeck wrote:
}
} Now, the idea is to after searching backwards for the first time
} (^Rmake), hitting ^R again, to go further backwards should ignore any
} other occurrences of 'make' in the current history event and jump
} directly to the next history event containing 'make' ('make depend')
} in the example above.

On Jun 16,  9:03pm, Richard Hartmann wrote:
} 
} I would like to add that, ideally, the ^R should jump to make clean, not
} make install (if possible).

This is very difficult.  There's no non-interactive history-search
operation that leaves the cursor at the word that was found, and the
incremental search won't let you "interrupt" it to force the cursor
farther towards the beginning of the line until the *next* character
is typed *after* it has stopped at the match near the end of the line.

On Jun 16,  8:31pm, Frank Terbeck wrote:
} 
} So, I took another approach and the closest I got (which works) is the
} following. It exists the incremental search and re-enters it if you
} continue typing. That is not an exceptionally nice solution and it
} would require additional tweaking to become usable.

Unfortunately that's probably the best approach to take without a lot
of work.  If history-incremental-search-* were implemented with real
widgets and a named keymap, you could copy the keymap, selectively
replace some widgets, and be on your way; but instead it's implemented
by hijacking specific widget names internally, so replacing them has no
effect within an incremental search in progress.

Another complication is that a wrapper for history-incremental-search-*
has to handle its own looping.  I'm not precisely sure what's going on,
but pressing the key that's bound to incsearch (which would, from the
top level, exit history-incremental-search-backward and execute your
widget) merely interrupts the search and returns control to the wrapper
*unless* the call to the wrapper *is* the first one (from the top level),
in which case one nested call is OK.  Maybe it has something to do with
whether an argument is passed to history-incremental-search-backward.

Then there are the strangenesses of up-line-* and beginning-of-line
behaving differently in multi-line buffers vs. single-line buffers, etc.
Perhaps the most annoying is that if the cursor is already on the first
character of a string matching the argument search pattern, you have
to invoke the search twice to move the cursor to the next occurrence
-- which means that in the wrapper function you *must* move the cursor
before trying another search -- which means moving up a history entry if
you're at the beginning of one -- so it's impossible to leave the buffer
unchanged when the search fails, though you can restore the old buffer
once the search is abandoned.

Having taken about 10 different stabs at this without really getting
any of them working any better than what Frank posted, I'm going to
leave this to someone with the patience to actually populate an entire
keymap.