bug#29323: kill-do-not-save-duplicate, FR

bug#29323: kill-do-not-save-duplicate, FR

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 379 bytes --]

Feature request:

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.

Thanks,

Andreas



[-- Attachment #2: Type: text/html, Size: 795 bytes --]

bug#29323: kill-do-not-save-duplicate, FR

[Drew Adams]

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

---

BTW - it's a pain to remove all of the formatting of your mails
to such lists.  Please consider using plain text, or at a minimum
not using a colored (i.e. non-white) background.  Just a request
or suggestion.

bug#29323: kill-do-not-save-duplicate, FR

[Andreas Röhler]

On 16.11.2017 23:34, Drew Adams wrote:
>> 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.

BTW implementing it would be a way more complicated as thought because 
of text 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.

> Just a request or suggestion.

bug#29323: kill-do-not-save-duplicate, FR

[Drew Adams]

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

bug#29323: kill-do-not-save-duplicate, FR

[Andreas Röhler]

[-- Attachment #1: Type: text/plain, Size: 3362 bytes --]



On 16.11.2017 20:51, Andreas Röhler wrote:
> Feature request:
>
> 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.
>
> Thanks,
>
> Andreas
>
>

This variant of kill-new should do it. Diff basically at comment " ;; 
delete string from kill-ring"

(defun ar-kill-new (string &optional replace)
   "Make STRING the latest kill in the kill ring.
Set `kill-ring-yank-pointer' to point to it.
If `interprogram-cut-function' is non-nil, apply it to STRING.
Optional second argument REPLACE non-nil means that STRING will replace
the front of the kill ring, rather than being added to the list.

When `save-interprogram-paste-before-kill' and `interprogram-paste-function'
are non-nil, saves the interprogram paste string(s) into `kill-ring' before
STRING.

When the yank handler has a non-nil PARAM element, the original STRING
argument is not used by `insert-for-yank'.  However, since Lisp code
may access and use elements from the kill ring directly, the STRING
argument should still be a \"useful\" string for such uses."
   (let (newring)
     (unless (and kill-do-not-save-duplicates
                  ;; Due to text properties such as 'yank-handler that
                  ;; can alter the contents to yank, comparison using
                  ;; `equal' is unsafe.
                  (equal-including-properties string (car kill-ring)))
       (if (fboundp 'menu-bar-update-yank-menu)
           (menu-bar-update-yank-menu string (and replace (car 
kill-ring)))))
     (when save-interprogram-paste-before-kill
       (let ((interprogram-paste (and interprogram-paste-function
                                      (funcall 
interprogram-paste-function))))
         (when interprogram-paste
           (dolist (s (if (listp interprogram-paste)
                          (nreverse interprogram-paste)
                        (list interprogram-paste)))
             (unless (and kill-do-not-save-duplicates
                          (equal-including-properties s (car kill-ring)))
               (push s kill-ring))))))
     (if (and kill-do-not-save-duplicates
          (member string kill-ring))
     (progn
       ;; delete string from kill-ring
       (dolist (ele kill-ring)
         (unless (equal-including-properties string ele)
           (push ele newring)))
       ;; push the match at top
       (push string newring)
       (setq kill-ring newring))
       (if (and replace kill-ring)
           (setcar kill-ring string)
         (push string kill-ring)
         (if (> (length kill-ring) kill-ring-max)
             (setcdr (nthcdr (1- kill-ring-max) kill-ring) nil))))
     (setq kill-ring-yank-pointer kill-ring)
     (if interprogram-cut-function
         (funcall interprogram-cut-function string))))

[-- Attachment #2: Type: text/html, Size: 4507 bytes --]

bug#29323: kill-do-not-save-duplicate, FR

[Stefan Kangas]

Andreas Röhler <andreas.roehler@easy-emacs.de> writes:

> On 16.11.2017 20:51, Andreas Rvhler wrote:
>
>  Feature request:
>
>  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.
>
>  Thanks,
>
>  Andreas
>
> This variant of kill-new should do it. Diff basically at comment " ;; delete string from kill-ring" 

I personally can't imagine when I would want the behaviour you ask
for, but I think it could make sense to have it as an optional
behaviour.

Drew suggested that this variable should have three possible values,
where 't' and 'nil' stays as they are, but we introduce a new symbol
which means to have the behaviour you want.  I think this is a better
proposal than changing the existing default.

Best regards,
Stefan Kangas

bug#29323: kill-do-not-save-duplicate, FR

[Lars Ingebrigtsen]

Stefan Kangas <stefan@marxist.se> writes:

> I personally can't imagine when I would want the behaviour you ask
> for, but I think it could make sense to have it as an optional
> behaviour.
>
> Drew suggested that this variable should have three possible values,
> where 't' and 'nil' stays as they are, but we introduce a new symbol
> which means to have the behaviour you want.  I think this is a better
> proposal than changing the existing default.

I don't really see this being generally useful even as an option -- it
makes kill/yank into a completely unpredictable pair of commands, and
that sounds really confusing.

So I think if somebody really wants this, they'll just have to advice
the kill command to remove duplicates (or something like that), but I
don't think we should add such a feature to Emacs, and I'm therefore
closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no