RE: should search ring contain duplicates?

["Drew Adams" <drew.adams@oracle.com>]

        BTW, is there any reason why history-delete-duplicates
        defaults to nil?

      I agree it should be t.

      I didn't even realize that variable existed when I started this
      thread, which is why I asked - why not (always) remove duplicates?
      I still wonder what the nil use case is - why would anyone want to
      keep duplicates?

    See the thread at
    http://lists.gnu.org/archive/html/emacs-devel/2004-09/msg00038.html

Thx. The only argument I see in that thread for ever allowing duplicates is
the point RMS raised about a command history. I can see that that might make
some sense in a shell interaction (although there are better ways to see the
shell history with duplicates). I don't see where it makes sense for, say,
the Emacs command history (and certainly not for histories like the
search-ring). But perhaps I'm missing something.

I think that for most uses of a history it makes no sense to keep
duplicates. I'd vote for making the default value be t and letting those few
modes where duplicates might make sense (e.g. shell-mode?) bind it to nil
unless the user has explicitly specified otherwise.

IOW the option values could be:

 nil            - means never remove duplicates
 t (default)    - means remove duplicates, but this can be
                  overridden by a mode (e.g. shell-mode)
 non-nil, non-t - means always remove duplicates (never override)

This would require code changes only for those few modes that want to
override the default (t). Plus a change to the defcustom.