Feature request: History after exit

[scotthovestadt]

I'd like the history to persist after exiting the shell, so if you re-enter the shell you can hit up arrow to see your previous command. Would you accept this as a PR with a toggle to turn it off? I'm thinking of using the temp dir to persist it (temporarily).

[dthree]

Yeah - I've wanted to do this. I'd love help on it, but want to make sure we do it totally right.

As part of this (and as a first step), I want to make a sturdy, basic API for temp files, as that subject is coming up a lot in Vorpal.

Wat implements a cross-platform temp file solution with a really small module, so perhaps we can do a similar thing and build it in.

[dthree]

Actually, just looked. Looks like I just use os.tmpDir(). I think the directory should be {temp}/.vorpal/hist, and then you can throw in a text file there for persistent history.

---

Then maybe for temp file access, we can have an API like:

vorpal.temp('hist'); // returns the directory string ./tmp/.vorpal/hist
vorpal.temp('hist').clear(); // clears out directory

[scotthovestadt]

Do you think maybe it makes more sense to providing more of an object-oriented API that persists itself automatically to the OS's temp dir? Here's my approach:

var history = vorpal.temp('history');
var commands = history.get('commands', []); // Second argument is default, if doesn't exist
// Last entry: commands[commands.length]
commands.push('command');
history.set('commands', commands); // Persists it
history.set('expires', Date.now() + 60000);

Something along those lines. Thoughts?

[dthree]

I'm totally down with that, which looks a lot like localStorage. We should just mirror the localStorage API in that case, IMO.

However, there should at least be one command that returns the location of a free-for-all localstorage directory, in case the user wants to do fs writes and reads, not just key/value assignments.

[scotthovestadt]

I am working on this and will submit a PR in the next week or so.

[scotthovestadt]

Agree with mirroring the localStorage API. That was actually what I was thinking originally, verbatim.

[dthree]

Nice and thanks for your help! :+1:

[fiatjaf]

I think it makes more sense to implement this as an extension, so the developer will have a chance to use the history matching algorithm he prefers, choose where and how to save history, save different histories for different CLI apps or mix them up etc.

The current history implementation, in https://github.com/dthree/vorpal/blob/6381c2c87081cf4ebaa3b903cc32081614131a5f/lib/session.js, could be removed and rewritten as an extension.

I have written this super naïve history extension that saves to disk a list of newline-separated commands (accepts a filepath, defaults to $HOME/.vorpal_history): https://github.com/fiatjaf/vorpal-history/blob/master/index.js. It works before a command is actually sent, but the default history behavior breaks everything after that.

[scotthovestadt]

@fiatjaf I agree. I didn't think about it in these terms before. We should continue down this path.

[dthree]

Good thinking. :+1:

[dthree]

See PR 68.

Implemented in v1.5.0.