Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot implement custom History: ReedlineError is private #545

Closed
ClementNerma opened this issue Mar 8, 2023 · 4 comments · Fixed by #661
Closed

Cannot implement custom History: ReedlineError is private #545

ClementNerma opened this issue Mar 8, 2023 · 4 comments · Fixed by #661
Labels
A-API Area: Changes to the consumer facing API enhancement New feature or request

Comments

@ClementNerma
Copy link
Contributor

Currently you can't implement your own History type as multiple trait functions return a Result<_, ReedlineError>, but ReedlineError (which comes from the private result module) is not available to use outside of the crate.

Would it be possible to make it available publicly?

Thanks!

@ClementNerma ClementNerma added the enhancement New feature or request label Mar 8, 2023
@sholderbach
Copy link
Member

Yes I think there is nothing speaking against that in my view. The trait should be implementation agnostic/tolerant.

While we are at it, it might make sense to make it either more general or replace it with a more specific name, as most of reedline just returns std::io::errors for the fallible interactions with the terminal. (Most of the reedline errors at the moment don't seem to actionable for the library users)

@sholderbach sholderbach added the A-API Area: Changes to the consumer facing API label Mar 8, 2023
@ClementNerma
Copy link
Contributor Author

I just opened a PR for this at #661

@sholderbach
Copy link
Member

Looking at the current state of the history system, I think we still have some serious gremlins lurking there.

See the unfinished error handling around how we deal with the different capabilities of SqliteHistory and FileBackedHistory (.expect("TODO: error handling") doesn't sound like a long term solution). Also assumptions around how big the history minimally is seem to pop up as nushell/nushell#10826. We have some work to do here to make things more robust and easier to understand.

So I don't want to give any stability promises with regards to the API of the History trait and related parts.

I don't want to discourage you from experimenting with implementing your own History and reporting what pops up.
But keep in mind that we may be a moving target or prioritize robustness over total flexibility in the future (as some of the issues we see right now may be due to premature flexibility)

@ClementNerma
Copy link
Contributor Author

I'm actually building a shell on top of reedline. But it's a personal project that isn't designed for public use before it's entirely finished and heavily tested, so even if there are major API breakages it's not a problem for me :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-API Area: Changes to the consumer facing API enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants