Import history from other browsers #3077

hgluka · 2023-07-11T18:35:34Z

Description

This PR aims to add commands for importing history from other browsers that use sqlite for data storage.
Some browsers that are on the docket:

Resolves #2435

Discussion

I'm not sure if reordering the components in nyxt.asd was the right way to go, but I needed to use nyxt/mode/file-manager:file-source in my function because the places.sqlite file is user-supplied.
The idea is to make the command search all the usual places and find it automatically, so I might be able to revert the order in nyxt.asd when that's done.

As for the actual history side of things, this imports everything as separate entries with htree:add-entry, but maybe we want a different structure?

Checklist:

Everything in this checklist is required for each PR. Please do not approve a PR that does not have all of these items.

Git hygiene:
- I have pulled from master before submitting this PR
- There are no merge conflicts.

I've added the new dependencies as:

ASDF dependencies,

Git submodules,

cd /path/to/nyxt/checkout
git submodule add https://gitlab.common-lisp.net/nyxt/py-configparser _build/py-configparser

and Guix dependencies.

My code follows the style guidelines for Common Lisp code. See:
- Norvig & Pitman's Tutorial on Good Lisp Programming Style (PDF)
- Google Common Lisp Style Guide
I have performed a self-review of my own code.
My code has been reviewed by at least one peer. (The peer review to approve a PR counts. The reviewer must download and test the code.)
Documentation:
- All my code has docstrings and :documentations written in the aforementioned style. (It's OK to skip the docstring for really trivial parts.)
- I have updated the existing documentation to match my changes.
- I have commented my code in hard-to-understand areas.
- I have updated the changelog.lisp with my changes if it's anything user-facing (new features, important bug fix, compatibility breakage).
  - Changelog update should be a separate commit.
- I have added a migration.lisp entry for all compatibility-breaking changes.
- (If this changes something about the features showcased on Nyxt website) I have these changes described in the new/existing article at Nyxt website or will notify one of maintainters to do so.
Compilation and tests:
- My changes generate no new warnings.
- I have added tests that prove my fix is effective or that my feature works. (If possible.)
- I ran the tests locally ((asdf:test-system :nyxt) and (asdf:test-system :nyxt/gi-gtk)) and they pass.

aadcg · 2023-07-12T07:32:07Z

@hgluka I don't know whether you consider it, but you could have added a new mode with its own file (say history-migration-mode). What do you think?

The change in nyxt.asd seems benign at first sight but I'd say we don't stand on such a solid ground to play around with a structure that works for now.

hgluka · 2023-07-12T08:25:39Z

@aadcg I dismissed that idea at first because it seems way too small for its own mode, but if the end goal is 4 or 5 different commands (one for each browser) then maybe it's warranted.

aadcg · 2023-07-12T09:10:26Z

I understand. For the sake of tidiness, I'd suggest creating a mode nonetheless. See no-image.lisp for instance. It's dead simple, right? But it's a self-sufficient part of our codebase and so it deserves it own space - much like the functionality you're adding right now.

aartaka · 2023-07-12T12:47:11Z

I dismissed that idea at first because it seems way too small for its own mode, but if the end goal is 4 or 5 different commands (one for each browser) then maybe it's warranted.

We have modes with 0 commands, so you're safe here!

hgluka · 2023-07-12T13:18:49Z

For the sake of tidiness, I'd suggest creating a mode nonetheless.

Done! But this is my first time adding a mode, so maybe I missed something.
I could also add it as a default mode (maybe for context-buffer) so that the command doesn't have to be global, but I'm not sure if that's necessary/worth it/the right thing to do.

aadcg · 2023-07-12T13:49:17Z

I could also add it as a default mode (maybe for context-buffer) so that the command doesn't have to be global, but I'm not sure if that's necessary/worth it/the right thing to do.

Maybe not so important right now. But I'd suggest setting slots visible-in-status-p and rememberable-p to nil and add option (:toggler-command-p nil). You can see examples in the codebase.

aartaka · 2023-07-12T13:53:03Z

I hate to change the direction, but why not putting it into the history-mode?

We have import-bookmarks-from-html in bookmark-mode, so there's a precedent for import commands belonging to the mode they influence.

hgluka · 2023-07-12T14:19:15Z

I hate to change the direction, but why not putting it into the history-mode?

We have import-bookmarks-from-html in bookmark-mode, so there's a precedent for import commands belonging to the mode they influence.

That was my idea originally. The issue is (or could be) that the command uses nyxt/mode/file-manager:file-source and that isn't loaded until after history-mode. My solution was to just reorder the components in nyxt.asd and while it worked well enough, it might be dangerous later down the line. I assume that there's a reason why history-mode is one of the Core modes (and thus loaded earlier than the Prompter modes).

hgluka · 2023-07-14T11:38:55Z

@aadcg @aartaka I realized that all the commands for different browsers would be very similar in structure, so I made a macro to define them. Is that safe to do?
The only downside I see is that describe-command will show the non-expanded form in the Source section, which obscures things somewhat.

aadcg · 2023-07-14T12:05:09Z

Looks good to me. Maybe the syntax of the macro is a bit unconventional in the sense that the sql query string seems out of place. Perhaps it could be preceded by a keyword. Nonetheless, it's not very important in my opinion. The functionality is the most important thing.

hgluka · 2023-07-14T13:49:10Z

I see your point. I just ordered the parameters by when they appear in the macro.

My thinking right now is that the prompt parameter could be renamed to something like file-path and expanded into a bigger cond expression that tries to find the file in the usual places and only prompts the user if the file isn't found.

In that case, the SQL string should definitely come before it.

aartaka · 2023-07-14T18:39:20Z

> I hate to change the direction, but why not putting it into the `history-mode`? > > We have `import-bookmarks-from-html` in `bookmark-mode`, so there's a precedent for import commands belonging to the mode they influence. That was my idea originally. The issue is (or could be) that the command uses `nyxt/mode/file-manager:file-source` and that isn't loaded until after `history-mode`. My solution was to just reorder the components in `nyxt.asd` and while it worked well enough, it might be dangerous later down the line. I assume that there's a reason why `history-mode` is one of the Core modes (and thus loaded earlier than the Prompter modes).

A bad, but nonetheless working solution could be offloading the symbol reading until file manager mode is available. Something like (read-from-string "nyxt/mode/file-manager:file-source") or (sym:resolve-symbol ...) should be enough. This way, you don't have to reorder files, while having both convenient prompt sources and commands belonging to the right modes.

hgluka · 2023-07-18T10:53:31Z

A bad, but nonetheless working solution could be offloading the symbol reading until file manager mode is available. Something like (read-from-string "nyxt/mode/file-manager:file-source") or (sym:resolve-symbol ...) should be enough. This way, you don't have to reorder files, while having both convenient prompt sources and commands belonging to the right modes.

Perhaps someone else (maybe @Ambrevar or @jmercouris?) can chime in, because I don't really know the pros and cons of using sym:resolve-symbol. I see that it's used in a few places in the project, so maybe it's alright to use here as well?

On the other hand, I think that a separate mode could still be okay. Yes, all the commands would fit very well in
history-mode, but they would also make up a distinct part of it, so at least it's not like we're splitting history-mode down the middle.

Anyway, I'm still working on the feature in the meantime, so feel free to discuss! I have a moderate amount of popcorn at the ready.

jmercouris · 2023-07-18T11:02:29Z

Resolve sym is effectively a hack to defer loading something so the compiler is happy. I would put it in a separate mode for now.

hgluka · 2023-07-19T15:14:47Z

So, it turns out that I don't have access to a Mac to test out an import from Safari. @jmercouris mentioned that it's not a priority. We can add that and Luakit in later.

As far as Chrome and Firefox go, there are a couple of questions regarding them.

In Firefox, it's not easy to determine the default profile is. There is a profiles.ini file, but I found some conflicting information about it. Some people say that the profile with Default = 1 is the default one, but in my case it's the opposite! Although I have a different variable called DefaultProfile in there which is correct. Right now, I left it up to the user to choose a profile by dropping the file source into the "top-level" .mozilla/firefox directory that has all the default profile dirs.
Chrome is easier in that sense because the History file is at .config/google-chrome/Default/History. However, the question here is about other Chromium based browsers (and Chromium itself). They all have the same History file, but the location is not always the same. Should I make a separate command for a couple of them (like Google Chrome, Chromium, Brave, Vivaldi, etc.) or would that introduce too much clutter?

jmercouris · 2023-07-19T16:04:32Z

I think a separate command would be best for the user, otherwise when they search for their browser and don't find it, they will be confused.

aadcg · 2023-07-19T16:24:24Z

If that helps, in my case, Default=1 corresponds to the default profile in Firefox.

hgluka · 2023-07-21T09:33:37Z

@aadcg Interesting. What does your profiles.ini look like?
In any case, I did a bit (a lot) more reading on the issue and it seems overly complicated. Apparently, there should be one default profile per installation of Firefox (Release, Nightly, Beta, etc.) and finding out which is which from the profiles.ini or installs.ini files isn't easy.

Maybe we can work on that after this is merged, but my lazy solution (showing the folder with all the profiles in the prompt buffer) works for now. The only thing I'd add to it is some kind of path-filter for the file-source, so that the irrelevant folders aren't shown.

aadcg · 2023-07-21T10:03:13Z

What does your profiles.ini look like?

It's very simple because I use a single profile.

[Profile0]
Name=aadcg
IsRelative=1
Path=apez2u28.aadcg
Default=1

[General]
StartWithLastProfile=1
Version=2

I'll test your work right now.

aadcg

I've tested by issuing import-history-from-firefox.

I think we must improve the UI, since these commands should be usable by the simplest of users. I don't think path-filter will work, because the predicate will filter given a certain input, i.e. within a folder. I would suggest creating a custom class that inherits from prompter:source or nyxt/mode/file-manager:file-source (probably the former). In the process, you'll get acquainted with one of the key Nyxt classes (those related to the prompt buffer).

The constructor would be set to the output of:

(uiop:run-program (list "find" (uiop:native-namestring "~/") "-name" "places.sqlite") :output t)

This is just a draft idea. What do you think?

Ideally we should also catch errors such as the one below, and tell the user what to do via echo.

Could not open sqlite3 database /home/aadcg/.mozilla/firefox/apez2u28.aadcg/
Code CANTOPEN: no message.
   [Condition of type SQLITE:SQLITE-ERROR]

After closing Firefox and attempting to import history again I was greeted with another error:

The value
  NIL
is not of type
  REAL
   [Condition of type TYPE-ERROR]

Restarts:
 0: [ABORT] abort thread (#<THREAD tid=22714 "Nyxt run-async command" RUNNING {1005CC0AA3}>)

Backtrace:
 0: (LOCAL-TIME:UNIX-TO-TIMESTAMP NIL :NSEC 0)
      Locals:
        NSEC = 0
        UNIX = NIL
 1: ((:METHOD NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX NIL)) [fast-method]
      Locals:
        NYXT/MODE/HISTORY-MIGRATION::CONN = #<DBD.SQLITE3:DBD-SQLITE3-CONNECTION {10095FDF93}>
        NYXT/MODE/HISTORY-MIGRATION::HISTORY = #<HISTORY-TREE:HISTORY-TREE {1005248403}>
 2: (NYXT::RUN-COMMAND #<NYXT:COMMAND NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX (1)> NIL)
      Locals:
        ARGS = NIL
        #:G7 = #<NYXT:COMMAND NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX (1)>
        OLD-%BUFFER = NIL

Have you seen it?

hgluka · 2023-07-21T11:18:18Z

I've tested by issuing import-history-from-firefox.

I think we must improve the UI, since these commands should be usable by the simplest of users. I don't think path-filter will work, because the predicate will filter given a certain input, i.e. within a folder. I would suggest creating a custom class that inherits from prompter:source or nyxt/mode/file-manager:file-source (probably the former). In the process, you'll get acquainted with one of the key Nyxt classes (those related to the prompt buffer).

The constructor would be set to the output of:
(uiop:run-program (list "find" (uiop:native-namestring "~/") "-name" "places.sqlite") :output t)
This is just a draft idea. What do you think?

Interesting! It didn't occur to me to just find the places.sqlite that way. This should work great for Firefox, although Chrome's file is called History and there are a bunch of other applications that use that name.

Ideally we should also catch errors such as the one below, and tell the user what to do via echo.
Could not open sqlite3 database /home/aadcg/.mozilla/firefox/apez2u28.aadcg/
Code CANTOPEN: no message.
   [Condition of type SQLITE:SQLITE-ERROR]

Yeah, I still need to handle some errors and also echo messages at certain steps like "Import started", "Import finished", etc.

After closing Firefox and attempting to import history again I was greeted with another error:

The value
  NIL
is not of type
  REAL
   [Condition of type TYPE-ERROR]

Restarts:
 0: [ABORT] abort thread (#<THREAD tid=22714 "Nyxt run-async command" RUNNING {1005CC0AA3}>)

Backtrace:
 0: (LOCAL-TIME:UNIX-TO-TIMESTAMP NIL :NSEC 0)
      Locals:
        NSEC = 0
        UNIX = NIL
 1: ((:METHOD NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX NIL)) [fast-method]
      Locals:
        NYXT/MODE/HISTORY-MIGRATION::CONN = #<DBD.SQLITE3:DBD-SQLITE3-CONNECTION {10095FDF93}>
        NYXT/MODE/HISTORY-MIGRATION::HISTORY = #<HISTORY-TREE:HISTORY-TREE {1005248403}>
 2: (NYXT::RUN-COMMAND #<NYXT:COMMAND NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX (1)> NIL)
      Locals:
        ARGS = NIL
        #:G7 = #<NYXT:COMMAND NYXT/MODE/HISTORY-MIGRATION:IMPORT-HISTORY-FROM-FIREFOX (1)>
        OLD-%BUFFER = NIL

Have you seen it?

I've never run into this issue. I think it means that there's a row in your moz_places table with an empty last_visit_date. I'll do some testing and see if it's a bug on my end, though.

aadcg · 2023-07-21T11:55:34Z

Chrome's file is called History and there are a bunch of other applications that use that name.

find $HOME -regex ".*chrom.*/History$" may help.

hgluka · 2023-07-24T12:52:14Z

@aadcg I implemented the changes you mentioned. Let me know what you think.

If I didn't miss anything, I think this is pretty much ready to merge. I can squash it into a couple of commits + a changelog commit when someone approves it.

aadcg · 2023-07-24T13:08:33Z

@hgluka will review soon.

aadcg

We're getting there @hgluka.

I've left some comments.

Finally, users may be confused as to what needs to be done for the imported history to be available. Issuing set-url after importing didn't show the entries in the "Global history" source. If restarting Nyxt is required (what I did), it needs to be echoed to the user. If there's an alternative, the user needs to be notified about it as well.

source/mode/history-migration.lisp

hgluka · 2023-07-25T07:46:43Z

Finally, users may be confused as to what needs to be done for the imported history to be available. Issuing set-url after importing didn't show the entries in the "Global history" source. If restarting Nyxt is required (what I did), it needs to be echoed to the user. If there's an alternative, the user needs to be notified about it as well.

That's weird, because for me the imported stuff shows up as entries in the "Global history" source immediately.

aadcg · 2023-07-25T12:05:27Z

That's weird, because for me the imported stuff shows up as entries in the "Global history" source immediately.

Let's not give this too much importance, since the issue may be on my side. I will try to reproduce it in the next review.

.gitmodules

Ambrevar · 2023-07-26T07:13:41Z

source/mode/history-migration.lisp

+                       (str:split #\newline
+                                  (nth-value 0
+                                             (uiop:run-program (list "find" (uiop:native-namestring "~/")
+                                                                     "-regex" (browser-pattern source))


This is OK for a draft, but the final version should not rely on find.
Instead, use uiop:collect-sub*directories to search for files recursively.

Also don't use (user-homedir-pathname) to resolve the HOME dir.

And use a lambda instead of a regex, it's more powerful, readable, and efficient.

@hgluka you may find inspiration to resolve HOME in the nfiles library.

Also don't use (user-homedir-pathname) to resolve the HOME dir.

I'm assuming you mean "don't use ~/" here, because that's what I'm using?
It seems like (user-homedir-pathname) is used in a couple of places in Nyxt as well as to resolve HOME in nfiles.

Oops, sorry, yes, I meant "don't use ~/" :)

I'm having some trouble with collect-sub*directories. I tried this, for example:

(let ((results '())) (uiop:collect-sub*directories (uiop:ensure-directory-pathname (user-homedir-pathname)) (constantly t) (constantly t) (lambda (subdir) (when (uiop:file-exists-p (nfiles:join subdir "places.sqlite")) (push (nfiles:join subdir "places.sqlite") results)))))

And it takes a very long time to run (more than 10 minutes).
Now, my home directory is huge, so restricting the search to ~/.mozilla should be a lot faster (although it might exclude some possible locations).

But I still feel like I must be missing something, since find takes a couple of seconds at most. Any idea why this would happen?

@hgluka Restricting the search to ~/.mozilla may be less future-proof, but it's not critical.

I have never used uiop:collect-sub*directories so I can't provide much insight. Personally, I don't consider the previous solution that used find to be a huge sin since no non-POSIX compliant flag is being used. @Ambrevar can explain why he considers this solution subpar.

Ah, I figured out that the issue is following symlinks (that happen to form a loop). find apparently detects those loops, so I either need to do the same or just avoid all symlinks outright.

Wait, if it loops, then it should not terminate, how come it took "10 minutes"?

source/mode/history-migration.lisp

hgluka · 2023-08-01T11:15:17Z

@Ambrevar @aadcg I managed to get the uiop:collect-sub*directories based file search to run in about 20 seconds on my PC. GNU find is still a lot faster, though, and then there's locate which is even faster than that.

aadcg · 2023-08-01T11:43:27Z

@hgluka since me and @Ambrevar may have different views on this topic, I would suggest that you should follow your own view. After all, you're the one that has been putting the effort on the task.

Ideally this PR should be merged no later than August 11 - the date of the next release is August 13. Also, I'd encourage you to write a small article announcing this feature given its importance to attract new users (https://nyxt.atlas.engineer/articles). CC @jmercouris.

jmercouris · 2023-08-01T12:09:48Z

That's a huge performance penalty. Maybe use UIOP as a fallback when find is not available or something like that. We'll talk about it during our call today :-)

.gitmodules

documents/SOURCES.org

jmercouris · 2023-08-01T17:44:42Z

Please let me know when you have squashed/rebased and are ready to merge this in!

Add history-migration mode with commands for importing history from Firefox and several Chromium-based browsers.

Switch from cl-dbi to cl-sqlite because `mode/history-migration` only works with SQLite databases.

Use `uiop:collect-sub*directories` to search for files, instead of GNU find.

hgluka · 2023-08-02T12:13:44Z

@jmercouris Well, after our talk yesterday, I think it's ready to merge now.
I did a rebase, although I didn't squash it all into one commit. I wanted to leave the ones where I add a dependency separate.

jmercouris · 2023-08-02T12:58:20Z

That's perfectly fine :-)

Ambrevar

You did a great job at switching to uiop:collect-sub*directories, thanks!

Can you open a new pull request to address my review?

Ambrevar · 2023-08-04T09:49:00Z

source/mode/history-migration.lisp

+      (echo "Searching for history file. This may take some time.")
+      (or (let ((results '()))
+            (uiop:collect-sub*directories
+             (user-homedir-pathname)


Don't start from here, as the search space may be much too big.

Instead, start from a collection of well known location for Firefox, Chrome, etc.
Like ~/.mozilla, ~/.config/chromium, etc.

Ambrevar · 2023-08-04T09:49:20Z

source/mode/history-migration.lisp

+             (user-homedir-pathname)
+             (constantly t)
+             (lambda (subdir)
+               (equal (iolib/os:file-kind subdir) :directory))


This is very slow, instead use uiop:directory-pathname-p.

But I'm not sure what you are trying to do here, since it looks like this does nothing more than (constantly t).

Probably related to an earlier comment.

This is for avoiding symbolic links, since uiop:directory-pathname-p doesn't detect them.
I could change it to (not (equal (iolib/os:file-kind subdir) :symbolic-link))) to make that clear.

Still, no need for iolib just for this. You can use uiop:truename*, or uiop:resolve-symlinks. To avoid cycling, you can push each directory to a hash-table and check if the next subdir was visited already.

Ambrevar · 2023-08-04T09:51:15Z

source/mode/history-migration.lisp

+
+(define-class external-browser-history-source (prompter:source)
+  ((prompter:name "History files")
+   (browser-lambda :accessor browser-lambda :initarg :browser-lambda)


This name is much too generic:

It's not clear if "browser" refers to the browser class or third-party web browsers like Firefox.

lambda is too vague: here it is about a "history-finder" or something like that.

Ambrevar · 2023-08-04T09:52:13Z

source/mode/history-migration.lisp

+               (equal (iolib/os:file-kind subdir) :directory))
+             (lambda (subdir)
+               (let ((browser-history-file (funcall* (browser-lambda source) subdir)))
+                 (when browser-history-file


Style: Replace this (let ... (when by alex:when-let.

Ambrevar · 2023-08-04T09:52:58Z

source/mode/history-migration.lisp

+               (let ((browser-history-file (funcall* (browser-lambda source) subdir)))
+                 (when browser-history-file
+                   (push browser-history-file results)))))
+            results)


Nit: You may want to reverse (nreverse results) instead, if you care about the ordering. (May not be significant anyways.)

Ambrevar · 2023-08-04T09:59:06Z

source/mode/history-migration.lisp

+                      :sources (make-instance 'external-browser-history-source
+                                              :browser-lambda (lambda (subdir)
+                                                                (when (uiop:file-exists-p (uiop:merge-pathnames* "places.sqlite" subdir))
+                                                                  (uiop:merge-pathnames* "places.sqlite" subdir))))))


You're calling uiop:merge-pathnames* twice. Let-bind it to save this extra call.

Ambrevar · 2023-08-04T09:59:41Z

source/mode/history-migration.lisp

+                                                                (when (and (string= "google-chrome"
+                                                                                    (nfiles:basename (nfiles:parent subdir)))
+                                                                           (uiop:file-exists-p (uiop:merge-pathnames* "History" subdir)))
+                                                                  (uiop:merge-pathnames* "History" subdir))))))


Ambrevar · 2023-08-04T09:59:49Z

source/mode/history-migration.lisp

+                                                                (when (and (string= "chromium"
+                                                                                    (nfiles:basename (nfiles:parent subdir)))
+                                                                           (uiop:file-exists-p (uiop:merge-pathnames* "History" subdir)))
+                                                                  (uiop:merge-pathnames* "History" subdir))))))


Ambrevar · 2023-08-04T10:00:01Z

source/mode/history-migration.lisp

+                                                                (when (and (string= "Brave-Browser"
+                                                                                    (nfiles:basename (nfiles:parent subdir)))
+                                                                           (uiop:file-exists-p (uiop:merge-pathnames* "History" subdir)))
+                                                                  (uiop:merge-pathnames* "History" subdir))))))


Ambrevar · 2023-08-04T10:00:13Z

source/mode/history-migration.lisp

+                                                                (when (and (str:starts-with-p "vivaldi"
+                                                                                              (nfiles:basename (nfiles:parent subdir)))
+                                                                           (uiop:file-exists-p (uiop:merge-pathnames* "History" subdir)))
+                                                                  (uiop:merge-pathnames* "History" subdir))))))


jmercouris · 2023-08-04T10:13:03Z

I don't think it's important to address those points now. I've assigned Luka higher priorities right now. Those changes are easy enough to make, but i don't think the context switch is good.

hgluka · 2023-08-04T10:38:53Z

I don't mind context switching every once in a while! Plus, there aren't any big changes to make. I'll do this when I have the time (and need a break from looking at common-settings).

aadcg · 2023-08-04T10:43:42Z

Would be a good idea to wait for user feedback too. The next release featuring this change lands on August 14.

Ambrevar · 2023-08-07T09:48:01Z

Those changes are easy enough to make, but i don't think the context switch is good.

Considering this was just merged, I would argue the other way around: better address this now that the code is fresh, instead of coming back to it weeks later when it looks like a stranger wrote it.

Ambrevar · 2023-08-07T09:53:14Z

Most of it are trivial changes. The main significant change is the home-dir traversal, still, it's an easy fix.

aadcg reviewed Jul 21, 2023

View reviewed changes

aadcg requested changes Jul 24, 2023

View reviewed changes

Ambrevar reviewed Jul 26, 2023

View reviewed changes

hgluka force-pushed the import-history branch from f77a73a to 26c3791 Compare July 27, 2023 10:14

Add cl-dbi as a dependency.

199a229

hgluka force-pushed the import-history branch from de4432b to a3508a0 Compare August 1, 2023 11:04

jmercouris reviewed Aug 1, 2023

View reviewed changes

.gitmodules Outdated Show resolved Hide resolved

jmercouris reviewed Aug 1, 2023

View reviewed changes

documents/SOURCES.org Outdated Show resolved Hide resolved

hgluka added 4 commits August 2, 2023 13:14

Add history-migration mode for importing history.

ea54516

Add history-migration mode with commands for importing history from Firefox and several Chromium-based browsers.

Switch from cl-dbi to cl-sqlite.

a702a01

Switch from cl-dbi to cl-sqlite because `mode/history-migration` only works with SQLite databases.

mode/history-migration: Use uiop to search for files.

1a5ddc7

Use `uiop:collect-sub*directories` to search for files, instead of GNU find.

changelog: Mention new history import feature.

20a3fda

hgluka force-pushed the import-history branch from 214e516 to 20a3fda Compare August 2, 2023 12:05

hgluka requested review from Ambrevar and aadcg August 2, 2023 12:13

jmercouris merged commit bbf8d8f into atlas-engineer:master Aug 2, 2023

hgluka deleted the import-history branch August 2, 2023 14:39

Ambrevar reviewed Aug 4, 2023

View reviewed changes

Import history from other browsers #3077

Import history from other browsers #3077

Conversation

hgluka commented Jul 11, 2023 • edited Loading

Description

Discussion

Checklist:

aadcg commented Jul 12, 2023

hgluka commented Jul 12, 2023

aadcg commented Jul 12, 2023

aartaka commented Jul 12, 2023 via email

hgluka commented Jul 12, 2023

aadcg commented Jul 12, 2023

aartaka commented Jul 12, 2023

hgluka commented Jul 12, 2023

hgluka commented Jul 14, 2023

aadcg commented Jul 14, 2023

hgluka commented Jul 14, 2023

aartaka commented Jul 14, 2023 via email • edited Loading

hgluka commented Jul 18, 2023

jmercouris commented Jul 18, 2023

hgluka commented Jul 19, 2023 • edited Loading

jmercouris commented Jul 19, 2023

aadcg commented Jul 19, 2023

hgluka commented Jul 21, 2023

aadcg commented Jul 21, 2023

aadcg left a comment • edited Loading

Choose a reason for hiding this comment

hgluka commented Jul 21, 2023 • edited Loading

aadcg commented Jul 21, 2023

hgluka commented Jul 24, 2023

aadcg commented Jul 24, 2023

aadcg left a comment • edited Loading

Choose a reason for hiding this comment

hgluka commented Jul 25, 2023

aadcg commented Jul 25, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hgluka commented Aug 1, 2023

aadcg commented Aug 1, 2023

jmercouris commented Aug 1, 2023

jmercouris commented Aug 1, 2023

hgluka commented Aug 2, 2023

jmercouris commented Aug 2, 2023

Ambrevar left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jmercouris commented Aug 4, 2023

hgluka commented Aug 4, 2023

aadcg commented Aug 4, 2023

Ambrevar commented Aug 7, 2023

Ambrevar commented Aug 7, 2023

hgluka commented Jul 11, 2023 •

edited

Loading

aartaka commented Jul 14, 2023 via email •

edited

Loading

hgluka commented Jul 19, 2023 •

edited

Loading

aadcg left a comment •

edited

Loading

hgluka commented Jul 21, 2023 •

edited

Loading

aadcg left a comment •

edited

Loading