Move border! macro here

[EdJoPaTo]

ratatui has a border! macro behind the macro feature flag. Move this macro here and remove that feature flag from ratatui.

[kdheepak]

I was hoping this crate would be a playground or testing ground for ideas for macros (especially if we want to write proc macros in the future), and if an idea seems interesting we could bring it to core. I suspect most people don't add an additional crate just for a macro.

Is there a reason you want to bring the border! macro here? imo, if it is a declarative macro, the burden of maintaining it in the ratatui crate is low.

[kdheepak]

Alternatively, we can bring the border! macro here, add this as a dependency to the ratatui crate and re-export it.

[EdJoPaTo]

There should be a single place for them. playground and upstream would be also fine.

Compiling ratatui takes ages and splitting it up is likely a good idea. Not entirely sure about it but somehow my memory associates providing macros with added compile time on the crate that provides them. But that might only be the case for proc macros?

[kdheepak]

My understanding is that the extra compile time for ratatui would happen in two cases:

1. If any dependency of ratatui uses proc_macros2 or syn as dependencies: https://reddit.com/r/rust/comments/19dkoj7/psa_prefer_declarative_macros_to_improve_compile/kj6gsdq/
2. If we use the macro in ratatui

I thought users that don't use the macro shouldn't see a difference in compile time, even if it wasn't behind a feature flag.

[EdJoPaTo]

I think there is a mix-up of compile time for a specific crate and total compile time. Once a crate is compiled it's not needed to compile again. The linking process is still needed tho.

Everything that is published from a crate (with the given feature flags) will take time to compile the crate and will take time on linking.

Moving stuff from one crate to a dependency crate results in parallel compilation.

ratatui can only be compiled once all its dependencies are compiled but all the dependencies can be compiled in parallel. Meaning: moving something from ratatui to a dependency of ratatui will speed up the compilation of ratatui and the dependency can be compiled in parallel to other stuff.

When ratatui would move stuff like buffer, widgets, … to their own crates it would speed up compilation as these parts can be built in parallel then. (Widgets require buffer, so there are some sequences.) On the other side, monorepos also annoy me, so sticking with separate repos and clear versions on what is possible to split up is what I prefer personally. Like having unicode-truncate in its own repo and use its functionality rather than building everything in the single ratatui repo.

The mentioned syn for example only needs to be compiled once for multiple crates using it, but all the crates using it will compile slowly as proc macros are hard to compile. Crates depending on proc macro crates can compile way faster as they only need what was published from the dependencies.

So… tldr: I assume keeping it a dependency and reexport stuff in the main crate should result in faster compile times both for users of ratatui and for contributions to ratatui.

[kdheepak]

Thanks for explaining! That makes sense. I didn't know about some of the nuances here.

We should bring this up as a part of a broader discussion with the team to discuss the organization / user experience / compilation time tradeoffs etc.

[EdJoPaTo]

Also… I suspect the use of generics in ratatui is one of the major factors for compile time (compiling ratatui, the crates using these generics and not sure how much that affects linking directly or just by that many functions generated by these generics)

Lists the generic functions: rg --glob '*.rs' 'fn \S+<'