Let the current screen win in the fight for dupes

[LSLeary]

windows generates mappings one screen at a time, starting with the
current. Tracking the windows it's already generated mappings for,
it excludes them from the tiles under consideration, hence supporting
window duplication in a first-biased manner. This allows the current
screen to win against any contenders and keep duplicated tiles within
reach.

However, it neglects to extend this treatment to floats; they end up
mapped in a last-biased manner. Consequently, duplicated floats become
very slippery, escaping to any inactive screen they can. This change
rectifies that issue.

See: xmonad/xmonad-contrib#797

Disclaimer: I haven't actually tested this yet, but I'd rather put it up now than let it stagnate until I get around to rebuilding my system xmonad.

It's not clear whether or not this change merits a changelog entry.

Checklist

• I've read CONTRIBUTING.md

• I've confirmed these changes don't belong in xmonad-contrib instead

• I've considered how to best test these changes (property, unit,
  manually, ...) and concluded: XXX

• I updated the CHANGES.md file

[slotThe]

It's not clear whether or not this change merits a changelog entry.

If this really fixed xmonad/xmonad-contrib#797 then I'd say it definitely does. @Robotix-00 care to give this a try?

[geekosaur]

Works here with a quick check.

[Robotix-00]

I can also confirm, that the copied window now appears on the currently selected screen rather than the last rendered one, which was always one of the unselected ones.
Its more pleasant, if the window doesn't try to escape from your cursor.

The change that would make this feature for me perfect would be, if the window were to stay on the screen it was "copied" on and doesn't move, no matter which screen is selected currently. I assume, without any expertise or insights into the code, that this would be a rather complicated change, so I am happy with this solution.
Thank you!

[TheMC47]

The change that would make this feature for me perfect would be, if the window were to stay on the screen it was "copied" on and doesn't move, no matter which screen is selected currently.

That's the reason I'm not using that module. I have a draft for a module that sticks the window on a screen. Though it looks like it should work, the jmplementation fails because I did it as a logHook and called windows inside, which unbeknownst to me, is a big no no. I didn't have time to debug it with the core rewrite (notably #433), but if it works, I'll ping you

[Robotix-00]

That'd be great, thanks and godspeed to you.

[slotThe]

@LSLeary I'd say put it into CHANGES (with perhaps a nod to X.A.CopyToAll) and then feel free to merge

[LSLeary]

@slotThe Amended and rebased. I don't have merge rights for core though, only contrib.

[slotThe]

Perfect, thanks!