bug#68579: [PATCH] Support a local repo as URL in treesit-language-source-alist

[Konstantin Kharlamov]

On Fri, 2024-01-19 at 17:06 +0200, Eli Zaretskii wrote:
> > From: Konstantin Kharlamov <Hi-Angel@yandex.ru>
> > Cc: casouri@gmail.com, 68579@debbugs.gnu.org
> > Date: Fri, 19 Jan 2024 17:33:03 +0300
> > 
> > > > > > -      (when (file-exists-p workdir)
> > > > > > +      (when (and (not url-is-path) (file-exists-p
> > > > > > workdir))
> > > > > >          (delete-directory workdir t)))))
> > > > > 
> > > > > Why?  Does workdir have different semantics in these two use
> > > > > cases?
> > > > > Isn't it the directory where we cloned the repository?
> > > > 
> > > > When an absolute path is passed as URL, that means the user
> > > > have
> > > > cloned
> > > > the repo, not us.
> > > 
> > > But you still clone from it into workdir, no?  treesit--git-
> > > clone-
> > > repo
> > > invokes "git clone" in both cases, according to my reading of the
> > > patch.
> > 
> > No, the `treesit--git-clone-repo` is located on the "else" branch
> > of
> > the `(if url-is-path`. That is, we do not call it when it's a local
> > path
> 
> Then this assumes some kind of workflow, doesn't it?  The user must
> first clone the repository, either via treesit.el or manually, and
> then they can use this new feature, right?  So I guess we should
> document this workflow somewhere?

Well, I can add some docs if you want, but the workflow per se seems
obvious to me: you have a function that accepts a local path to repo
and builds from it. You'd never want someone to delete your repo just
because you asked that someone to compile sources in the repo, because
you might have some local commits in there. Removing it would be a
completely surprising side-effect.

OTOH, when you pass a URL to the same function, you ask "pls build from
the sources, I don't care how", so the function clones it to a
temporary dir. It may or may not remove the dir, it's doesn't matter
that much. But the temporary directory becomes a junk after the build
completed, so why not remove it as well.

To me personally these two workflows is something that immediately
comes to mind when I see that the parameter is a URL or a local path.