How to always Paste and Match Style on macOS

Konstantin — Tue, 17 May 2022 17:01:06 +0000

How to always Paste and Match Style on macOS

It’s safe to say that some of us do a lot of copy-pasting during the day. (StackOverflow even sells a dedicated keyboard).

While the ability to copy content from one app and paste it into another is probably in the TOP 3 productivity features of a modern computer, it doesn’t come without its quirks…

Just in case you don’t know what I’m talking about - when you copy some text content from a place with formatting (like custom font, colors, etc.) and then paste it into another app that also supports (to some extent) rich text formatting.

By default, copy-paste (⌘ + C / ⌘ + V) allows an app to capture all available content types when pasting. As a result, copying a snippet from a web page comes in both plain text and rich/formatted text. All worldly computer things have opted to use the richest form of content available in the clipboard when pasting for reasons beyond my understanding 🙄.

Honestly, I can’t remember when (if at all) I needed this behavior. In all cases, I want the source text to match the destination formatting as best as possible. This feature exists; it’s the Edit > Paste and Match Style command.

To fix this in (almost) all apps, you head to System Preferences > Keyboard > Shortcuts > App Shortcuts and then hit the plus button to create a new shortcut with the menu title “Paste and Match Style” and assigning ⌘ + V! That’s it 🎉!

⚠️ This technique does not work in Microsoft apps like Word, which chooses to override and shamelessly disregard the user’s system preferences or (most of) the text services provided by macOS 🤷🏻‍♂️.

Adding an executable target to a Rust library

Konstantin — Mon, 16 May 2022 05:12:36 +0000

Using Cargo, we can easily create a library project with the new command:

cargo new pumpkin-rs --lib

Of course, the primary purpose of libraries is to encapsulate some kind of functionality that can be then exported for use by other libraries or applications.

For the purpose of this post, let’s define a simple function in src/lib.rs which will be the essence of our library. Later we will see how we can use this function from a runnable binary target in the same project.

pub fn say_hello() {
    println!("Hello from the library");
}

You may run cargo build just to double-check everything builds successfully… and voilà!

Cargo Targets

In certain situations, it may be helpful to have a library project include a runnable component - a stand-alone, runnable program that can be executed.

Cargo targets allow us to define different combinations of source files which can be compiled in a project. Targets can specify what part of the source code is a library, binary, example, unit test, or benchmark.

The cool thing is that Cargo also uses folder structure conventions to guess which source file does what. For example, src/lib.rs is where it will look for the library code, executable code is expected in src/main.rs or src/bin/.

Add a default binary target

Following the conventions above, we can add a default executable to a library project by creating src/bin/pumpkin.rs:

use pumpkin_rs::say_hello;

fn main() {
    say_hello()
}

Running cargo run will execute the binary! 🎉

Not only that, but cargo build now also produces 2 separate outputs - we get the compiled binary for the library as well as the executable.

More than one binary targets

We are not limited to a single binary target. There can be more than one!
Let’s create src/bin/tomato.rs

fn main() {
    println!("Hello 🍅")
}

Now, if we just run cargo run like before, we’d get an error message because there are two available binary targets, and cargo doesn’t know which one we want to use. The error message helpfully suggests we can use the target configuration in Cargo.toml to define a default-run key or pass the --bin argument to the run command.

cargo run --bin tomato

DEV Community: Konstantin

How to always Paste and Match Style on macOS