feat: Use ::ratatui instead of ratatui

[kdheepak]

This PR uses ::ratatui to ensure it doesn't clash with a module named ratatui in an app, per comment #52 (comment)

This PR also refactors some tests.

[kdheepak]

Should this be a breaking change?

[joshka]

Should this be a breaking change?

no

[kdheepak]

Can you elaborate on why this is not a breaking change? Just trying to understand.

Currently, if a macro like this is defined in this crate:

#[macro_export]
macro_rules! my_custom_macro {
    () => {
        foobar::test()
    };
}

Even if the foobar is not defined in this crate, this crate will compile fine. Then, a user can use this macro by defining a foobar module in their code and calling the macro:

mod foobar {
    pub fn test() -> String {
        String::default()
    }
}

fn test_function() {
  let s = my_custom_macro!();
}

i.e. the current behavior is to call functions from the ratatui module in the macro expansion scope or calling scope, or the ratatui dependency that they choose to add into their project.

But with this PR, the behavior is to call functions from the ::ratatui module that is a dependency of the ratatui-macros crate.

So technically this could be breaking, right?

[joshka]

Can you elaborate on why this is not a breaking change? Just trying to understand.

Currently, if a macro like this is defined in this crate:

#[macro_export]
macro_rules! my_custom_macro {
    () => {
        foobar::test()
    };
}

Even if the foobar is not defined in this crate, this crate will compile fine. Then, a user can use this macro by defining a foobar module in their code and calling the macro:

mod foobar {
    pub fn test() -> String {
        String::default()
    }
}

fn test_function() {
  let s = my_custom_macro!();
}

i.e. the current behavior is to call functions from the ratatui module in the macro expansion scope or calling scope, or the ratatui dependency that they choose to add into their project.

But with this PR, the behavior is to call functions from the ::ratatui module that is a dependency of the ratatui-macros crate.

So technically this could be breaking, right?

Technically yes, but this is the opposite of Unicode-width crate mess that wasn't a "breaking change" despite it being a "change that broke things". This is a "breaking change" that "doesn't break anything". There's 19 results in https://github.com/search?q=ratatui_macros&type=code and none of them define a ratatui module in their code that would be impacted by this. I wouldn't sweat this.

[EdJoPaTo]

A breaking change is when the intended behaviour changes. This PR ensures that the intended behaviour always works. It’s a fix to ensure it actually works as it should. That’s the same of what unicode-width did: ensuring that it does what it should.

---

This PR seems to also include unrelated changes?

[kdheepak]

This PR seems to also include unrelated changes?

It was refactoring of the tests, I guess that should have gone in a separate PR?

[joshka]

Not a big deal in this lib.