We introduce the h--init-forges-state function in charge of
initializing the forge state and setting all the forges status to
loading. It prevents the forge names to gradually pop-up during a
forge request and instead display them with their appropriate status.
The synchronous git process call was freezing the whole UI for a
*pretty long* time when checking out a big git repository.
We move into using a asynchronous process. This change required quite
a lot of sync-related changes. Both in the h.el codebase as well as in
the test suite.
On top of making the git call asynchronous, we also take advantage of
not freezing the UI anymore to open a window displaying the git clone
progress.
h--pick-relevant-forges is an artifact of a former architecture.
On top of being some useless code, it was brittle and was preventing
us from cloning a repository from savannah.
We use the Gitea API to determine whether or not a given repo exists.
If it does, we use the API response to properly determine the SSH and
HTTPS clone URLs.
We refactor h--draw-ui-buffer by extracting the key binding generator
to its own function. Having it in its own pure function, we're now
able to write some tests for it.
This function used to only return the kind of the query string. This
is not sufficient to properly query the forges. On top of returning
the type of a query string, we want this function to actually parse
the query into a tagged union materialized as a astring.
We update the tests accordingly to this refactoring.
We implement a custom replacement for `directory-files-recursively`
for x reasons:
1. `directory-files-recursively` has been introduced in Emacs 25.1.
Meaning, as it was, h.el couldn't run on a older Emacs.
2. Specializing the code allows us to simplify quite a lot
`directory-files-recursively`. Removing some unnecessary I/O
operations. That's a win performance-wise.
3. We add the git repository detection routine directly into the dir
walker. It reduces the walker complexity from O(2n) to O(n).
So far, I was hoping I could check-in some dummy code-root setups
directly to the git repository as fixtures. Sadly, it's almost
impossible to check-in git repos in a git repo. The only option do to
so would be to setup git subrepo. Needless to say, I *really* don't
want to go down that path.
Instead, I created some infrastructure to create a temp directory in
which we generate the test code-roots on the fly.
This function is meant to retrieve the projects repositories from the
code-root.
This first version is a bit naive in its approach: we consider a
directory to be a git repository as soon as a .git directory is present.
That might be a bit too naive.
Félix Baylac-Jacqué