Kurtis Rader

@brunoroque06: I don't see the point in switching to `nutsdb` since it doesn't support multiple processes simultaneously accessing its database. Thus, we'd still need the Elvish daemon. There are well...

There is one notable difference between the Elvish and Fish shell command history model. The Fish shell history **does not** assign a unique sequence number to each command. The Fish...

> I think nutsdb supports multiple processes simultaneously: https://github.com/nutsdb/nutsdb/issues/100 . Yesterday I only saw that it has transactions, so I assumed it supports concurrent access. I have not tested it...

> Why can't we just have a simple file? We can. It's just that no one has invested the time to design an implementation and write the code. Not to...

@prologic: Note that [shared variables](https://elv.sh/ref/store.html#store:set-shared-var) depends on the current database mechanism. Even if you ignore that feature you still need to deal with location history, not just command history. The...

> The Elvish community needs to decide whether the "shared var" mechanism should be retained. Eliminating the shared var mechanism will make it orders of magnitude easier to replace the...

Per discussion on the IM channels the project owner agrees that support for shared vars can be dropped. So I'll create a pull-request to do so. That simplifies the problem...

> This should be a separate command. No need to cram as much functionality as possible to a single command. Doing so certainly makes it much easier to provide more...

@xiaq: Please take another look. I've introduced a `benchmark` command and also made the associated unit tests more robust.

I was waiting for my earlier change to support comparing boolean values to be merged before creating a pull-request for this feature. Now that comparing booleans is possible (see issue...