feature: Copy snippet to clipboard in case of single result

[hannotify]

I read through README.md the other day and felt like giving the clipboard feature idea a shot.
Feel free to comment on the implementation. 😉

[hannotify]

So it looks like the hardware that runs the Github Actions for this project has a headless JDK installed that doesn't allow the use of java.awt classes. So I'll try to update the build.yml with support for a dummy display.

[mthmulders]

Thanks for picking this up, @hannotify! I'll make sure to go through the code in more detail later, but I've got one functional issue upfront where I'm a bit in doubt.

Indeed, the README.md suggests copying to the clipboard immediately, but now I'm thinking about that again - does it make sense? It would overwrite something else the user has on their clipboard. Would a -c/--copy switch or similar make sense to address that? The disadvantage of that would of course be that it's easy to "forget" that.

Curious how you think about this.

[hannotify]

Good point, didn't think about that while implementing it. I agree that overwriting the existing contents on the clipboard seems a tad invasive. But if we hide it behide a command line flag it isn't easily discoverable as a new feature.

What if we would suggest the --copy flag each time a single result is found?

❯ mcs search io.github.er1c:scala-stringutils_2.12
Searching for io.github.er1c:scala-stringutils_2.12...

    <dependency>
        <groupId>io.github.er1c</groupId>
        <artifactId>scala-stringutils_2.12</artifactId>
        <version>0.1.0</version>
    </dependency>

(To directly copy this snippet to the clipboard, run mcs with the -c or --copy flag.)

[mthmulders]

What if we would suggest the --copy flag each time a single result is found?

That sounds like a great idea to me!

In the meantime, I've opened #187 to explore ways to solve this in a generic way.

[mthmulders]

Thanks again for picking up this idea, and apologies for reacting with so much delay!

I am very pleased with your approach. Could you please introduce the -c/--copy flag as we've discussed in the conversation?

[hannotify]

I'm about halfway implementing the -c/--copy flag, but I'm battling a nasty rippling effect there (lots of methods that need to pass the value of this copy parameter to each other). I feel like the project could eventually benefit from a lightweight DI framework, to enable injecting values (and names) of command-line parameters anywhere in the code. I'll probably create an issue on the topic somewhere next week.

[hannotify]

Finished the implementation (so please review again! 🙏) and opened #192 to address dependency injection in general.

[mthmulders]

Thanks a lot, @hannotify. Most remaining remarks are about the 'strictness' of tests. One question for the production code, related to #192.

[hannotify]

Applied your suggestions!

[mthmulders]

Thanks a lot for your contribution and your patience, @hannotify!

[mthmulders]

• The failing mutation tests are most likely going to be fixed in chore(build): Upgrade Pitest and friends #226.
• The failure in the macOS-arm64-latest build is caused by a faulty runner (i.e., my Macbook), I'll take care of that.

[mthmulders]

Alas, the macOS-arm64-latest build fails due to

The application is not running in a desktop session,
but this program performed an operation which requires it.

I'll have to figure out how to start that runner in a desktop session (and if I actually want to do that for every build)

[mthmulders]

This is turning out worse than I thought: apparently, GraalVM doesn't support AWT - at least, not on macOS. Maybe the Liberica Native Image Kit (NIK) could be an alternative solution but I haven't yet looked into that.

For now, I am going to revert the changes I've pushed to your branch, @hannotify. This topic clearly needs more attention. Let me be clear: the code looks good, and I'm sure it works in JVM mode, but packaging it to a native executable is going to be another challenge on this road.