RE: should search ring contain duplicates?

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

    > 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.

    A related feature that specifies the maximum length of the history list
    uses the `history-length' _property_ of the history list _symbol_
    to override the default value of the _variable_ `history-length'
    for a particular history list.  Exactly the same thing could be
    implemented for `history-delete-duplicates', i.e. the property
    `history-delete-duplicates' would override its default value
    for a particular history list.

Clever, but maybe too clever. Non-lisper end users should be able to easily
change options, and they should be able to do so using Customize (and save
such preferences). Making users use property lists to override default
values is not a good way to go, IMO.