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.

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.

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

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.

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.

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

Applied your suggestions!

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

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)

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.