[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#29323: kill-do-not-save-duplicate, FR
From: |
Drew Adams |
Subject: |
bug#29323: kill-do-not-save-duplicate, FR |
Date: |
Sat, 18 Nov 2017 11:48:07 -0800 (PST) |
> >> Currently variable kill-do-not-save-duplicates checks only the (car
> >> kill-ring) as docu explains: Do not add a new string to ‘kill-ring’
> >> if it duplicates the last one. The comparison is done using
> >> ‘equal-including-properties’. AFAIU it would be trivial replace this
> >> check by a call of "member", thus checking > the whole kill-ring.
> >
> > Why do that? Why not just prevent duplicates in the first place, which
> > is what the option currently does? If you for some reason get
> > duplicate entries somehow, in spite of using the option to prevent
> > them, you can always remove them. I don't understand how that would be
> > something that would happen normally. What is the problem that this
> > would try to solve/prevent? ---
>
> Currently not a check for duplicates is implemented, but for a repeat.
>
> When having alternating strings to copy, they go into the kill-ring one
> after one. That way it ended up having just two strings in the
> kill-ring, and previous content lost.
Sorry; my bad. I don't use that variable. Clearly you
are right. The option should perhaps have 3 values: one
to do nothing special, one to not push when the car is
the same, and one to not push when the same is on the
right somewhere.
> BTW implementing it would be a way more complicated as thought because
> of text properties.
Not a big deal, I think. It just uses predicate
`equal-including-properties', which is coded in C.
But now that this has come up... Perhaps the predicate
to test equality should be the value of a variable, to
give users the ability to control the behavior better.
Or barring that (which I'd prefer), perhaps it could
at least let a user choose whether to distinguish
entries if they are the same other than their properties.
> > BTW - it's a pain to remove all of the formatting of your mails to
> > such lists.
>
> Hmm, don't you see a formatting when sending.
>
> > Please consider using plain text, or at a minimum not using a colored
> > (i.e. non-white) background.
>
> Switched on "Readers Default Colors", which should help.
Whatever you're doing now works, for me at least. Thanks.