Thank you for the awesome crate. I have been slowly integrating it in a few projects, and it is proving to be incredibly useful.
However, one thing that we are struggling with as this scales up is debugging errors when a variable/functios is renamed or removed. Our solution right now is to panic!("{tera_error}"), rerun the build in CLI, and read through the build logs.
It would be great if we can thread these diagnostics to the editor directly. For example, projects can easily print these errors information (message, file, line, column) on stdout, and VS Code will pick it up and render it diagnostics/squiggly lines. Large projects often define multiple matchers for different frameworks they are using:
But unfortunately doing so for Tera (like the example above) is proving to be difficult, since there is no consistent output format for these errors, and not all of them include the relevant information. I wonder if this is something that can be added/supported in Tera, so that users can propagate it correctly?
For example, file/range information can be added to tera::Error:
#[derive(Debug)]
pub struct Error {
pub kind: ErrorKind,
pub file: Option<PathBuf>,
pub range: Option<Range<LineColumn>>,
source: Option<Box<dyn StdError + Sync + Send>>,
}
Thank you!
Thank you for the awesome crate. I have been slowly integrating it in a few projects, and it is proving to be incredibly useful.
However, one thing that we are struggling with as this scales up is debugging errors when a variable/functios is renamed or removed. Our solution right now is to
panic!("{tera_error}"), rerun the build in CLI, and read through the build logs.It would be great if we can thread these diagnostics to the editor directly. For example, projects can easily print these errors information (message, file, line, column) on stdout, and VS Code will pick it up and render it diagnostics/squiggly lines. Large projects often define multiple matchers for different frameworks they are using:
But unfortunately doing so for Tera (like the example above) is proving to be difficult, since there is no consistent output format for these errors, and not all of them include the relevant information. I wonder if this is something that can be added/supported in Tera, so that users can propagate it correctly?
For example, file/range information can be added to
tera::Error:Thank you!