Re: should search ring contain duplicates?

[David Kastrup]

"Drew Adams" <address@hidden> writes:

>         > I am not interested in considering such a complex proposal.
>
>         There is nothing complex about it (with the latest add-to-history)
>         version.
>     
>     I was talking about a different proposal, one involving properties to
>     control lengths.  It was very complex.
>     
> To be clear, was it this proposal from Juri:
>
>     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.

I don't know how you gather this when Richard directly replied to the
posting of yours
Message-ID: <address@hidden>
containing the proposal:

    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.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum