History API rewrite (discussion after #680)

[ClementNerma]

This issue is aimed to track all discussions for the rewrite of the history, menu and completer (HMC) API, followed existing decisions and trials in #680 (history only).

Opening message from @stormasm : #680 (comment)

[ClementNerma]

The Big Idea concept is a Complete Refactor / Rewrite of Reedline without having History / Menus / Completer (HMC)
so tightly embedded into the Engine ---- but instead API entry points into the Engine which would enable
decoupled HMC components...

@stormasm what do you mean exactly by that? Given you currently can disable API and completer by simply not providing them when Reedline is created.

[stormasm]

@ClementNerma true, good point !

Think about it then from the point of view of having a History / Menu / Completer (HMC) crate system where developers can come along and have the ability to implement any one of the three components given our fundamental Reedline API into these systems...

In other words vastly loosening the Engine API to be able to accept those components (as Traits)...

Or something to that effect...

From the History API point of view imagine you wanted to use a different persistence database / something different than SQLite (for example)...

[ClementNerma]

Sorry, I don't really get what you're suggesting.

Aren't these three components traits already? PR #680 was about making it more flexible and easier to use, but it was already a trait before.

IIRC I've already implemented a custom completer, and in the current git tree it seems you can make custom menus?

[stormasm]

@ClementNerma going back to your previous PR --- one thing you mentioned in there was to leave the File format of the History API alone ---- that seems critical to me...

The current file format of the History API would remain "untouched".

I really like the way it works for many different reasons...

[stormasm]

@ClementNerma lets just focus on the History API for now...
I went ahead and modified the title of the issue...
It will limit the scope of what we are talking about and probably be more productive in the short term 😄
Plus its what you are most interested in for now (I assume ?) --- and where your coding passion lies based on your
previous PR....

[ClementNerma]

Seems fine to me. For the SQLite database I feel like it could still be useful for programs who'd like to take advantage of it, so I'd like to keep the ID inside. The migration is instant for previous database and 100% compatible with the previous one (the only change to the schema is one new column).

Plus its what you are most interested in for now (I assume ?) --- and where your coding passion lies based on your
previous PR....

Well initially I started the PR to create a path for myself while building my own shell. But now I'd like to think this could help other people as Reedline is the 'de facto' library for this kind of task in Rust. So why not improve it in multiple ways?

I now have a good understanding of how the history API works so that's where I can be the more proficient for now, but I'm absolutely not against helping on other parts if help is required :)

[stormasm]

@ClementNerma sounds good to me ! again, thanks for showing an interest in improving the History API...

[ClementNerma]

I updated the PR, I feel like it should mergeable in its current state. What do you think?

This could be the first brick of a larger API overhaul, but greatly improving the History API and making it entirely implementable for everyone is a major upside IMO.

I think a later step could be to introduce a third builtin history type, which would use all the features from the history. Like SQLite, but using a more performant and compact system like sled for instance.

[stormasm]

@ClementNerma I don't see any new commits in the PR, can you please paste a link to the PR here, if we are talking #680 --- the last commit I see is from awhile ago...

[ClementNerma]

Indeed it doesn't show up in the PR 🤔
Weird, I'll check that later.

[stormasm]

@ClementNerma we are doing a nushell release on Feb 6 so it probably makes sense to hold off on submitting the PR to next week...

Prior to submitting the PR I would recommend NOT changing anything in the Schema file for the SQlite...

I don't think we are going to want to have to run a Migrate script on developers databases...

So I would recommend no changes to the text file or the database file...

#736

Also I would recommend running your ideas by @Hofer-Julian prior to doing any more work on this concept...

They are pretty familiar with the inner workings of how Reedline interacts and works with the History / Database...

And may have some insights on how you can move forward with your intentions of improving History.

Thanks !

[ClementNerma]

Ok so I'll remove the new SQLite schema and wait for people to review it.

cc @Hofer-Julian

[stormasm]

@ClementNerma since the old PR is already closed and it has lots of old stuff in there...

can you please open a new PR so we start from a clean slate...

thanks !