New package. Status: experimental. Early feedback is appreciated.

#### Search through the Browser history, in Emacs

Very interesting. Will try it soon. Thanks

see also https://github.com/cireu/counsel-ffdata

Much as I appreciated ivy and counsel, I think this illustrates the technical benefits of the vertico/orderless/marginalia/consult approach. This seems like a very nice counsel package but only applies if you want to use ivy completion.

i don't think it's THAT hard to make changes to the packages making it a universal solution, much easier than write one from scratch P.S. And don't forget that Ivy was written in the times when Emacs completion system was far from what it is now. I just could not be written the other way.

Oh, nice, definitely will try to borrow some ideas. Thank you.

No dis to ivy/counsel - I used and appreciated them for a good while. I didn't realize though that the more recent, 'more native', solutions had required internal changes to allow them to exist. But whatever, the fact that they integrate as well-defined units is great and the way forward. I'm sure many of the current packages have cribbed wholesale from what people have done in counsel/helm etc., as they should.

**PUT THAT IN THE STORY TITLE** ;) BTW, my feedback is that it would be nice to support multiple databases per browser type, in case the user has multiple profiles for a browser. Maybe auto-discovery, too, using common path prefixes, `find`, etc. The user generally shouldn't need to configure that. Also: "Browser history file is usually locked, in order to connect to db, we copy the file." 1) That shouldn't be necessary on non-Windows platforms, and it would be good to skip that step on them; 2) When necessary to copy it, it would be good to do so in RAM if possible. All that extra disk work every time a query is run seems like it should be avoided. Finally, and probably most importantly: You're not actually searching the databases with SQLite--you're just getting *every* history entry and then searching them in Emacs. That's going to be much slower than using the user input to query for matches with SQLite. Interestingly, none of the similar packages I can find do this, either: they all fetch every history entry and use Emacs to filter them. This could be an opportunity for your package to be faster and more efficient.

> would be nice to support multiple databases per browser type Ah, right, I haven't thought about that use case. > Maybe auto-discovery, too I am hoping to add that soon > That shouldn't be necessary on non-Windows platforms, No, it appears locked in OSX. I yet have to test this in Linux. > You're not actually searching the databases with SQLite Yes, I know. I'm hoping to change it at some point so it initially displays the top 10-20 results and when something gets typed, it would delegate the search to sql. -- Thank you for all your suggestions

Cool, keep up the good work.