bug#31209: 27.0.50; current-kill calls interprogram-paste-function more than once

[Noam Postavsky]

tags 31209 fixed
close 31209 27.1
quit

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

> The first makes current-kill disable interprogram-paste-function in
> addition to interprogram-cut-function before calling kill-new.

Pushed to master [1: 532f5fb387].

> The second suggests potential clarifications in related documentation,
> both in '(elisp) Low-Level Kill Ring' and simple.el docstrings.
> Hopefully someone can further improve upon these.

Pushed to emacs-26 [2: 343d70b10e].

[1: 532f5fb387]: 2018-04-25 07:37:32 -0400
  Do not call interprogram-paste-function repeatedly
  
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=532f5fb3877ccd535a822f7c3c08d396621b4325

[2: 343d70b10e]: 2018-04-24 20:58:15 -0400
  Improve kill-related documentation (bug#31209)
  
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=343d70b10edbd42ebe49ada3a8ef878b2ee044f0


> I just noticed one more thing.  The docstring of
> interprogram-paste-function ends with:
> 
>   Note that the function should return a string only if a program
>   other than Emacs has provided a string for pasting; if Emacs
>   provided the most recent string, the function should return nil.
>   If it is difficult to tell whether Emacs or some other program
>   provided the current string, it is probably good enough to return
>   nil if the string is equal (according to `string=') to the last
>                                             ^^^^^^^
>   text Emacs provided.
> 
> Would equal-including-properties (as per kill-do-not-save-duplicates) be
> more accurate here, or is string= fine?

I guess if we're talking about strings coming from other programs,
properties are unlikely to show up.