How to proceed ?

[brotzeit]

I'd really love to see this repo being used. Do you see any chance we can make progress here ? Are there any issues or obstacles ?

[TheBB]

As far as I can remember, this library has plenty enough functionality already to be useful in magit, it just has to be implemented there. Some skeleton work for an interface is already in place by @tarsius, but progress has stalled since then.

[tarsius]

Some skeleton work for an interface is already in place by @tarsius, but progress has stalled since then.

Yeah, sorry about that. Not sure how soon I will get back to that. Pretty sure it will be this year though. 😁

@TheBB could you please deal with #92 though?

[TheBB]

Oh, no need to apologize. I'll get to #92.

[brotzeit]

@tarsius maybe we can split up the work somehow or do you want to do it alone ? Or maybe you need some more motivation like a few years ago ;)

[asavonic]

FWIW, I started enabling some of magit functions to libgit a while back, but haven't finished this properly. See https://github.com/asavonic/magit/blob/master/libgit-progress.org (and related commits).

[tarsius]

@asavonic Great! @brotzeit No, I don't have to do this myself. Please coordinate with one another.

I don't want to merge anything into master until all the functions (except maybe some difficult cases) are ready. And I also want to release 3.0.0 first (late summer?). Ideally we would also add tests for all these functions at the same time.

I have been thinking about tests a bit and my current idea is to use git's testing framework. If someone wanted to work on that, that would be great as well, but I understand if that is even less appealing. On the other hand if there is someone out there who likes doing this sort of thing... 😀

[seagle0128]

Any update for this, please?

[tarsius]

And I also want to release 3.0.0 first (late summer?).

Winter, still 2020.

[bqv]

Please coordinate with one another.

@asavonic @brotzeit did this happen or are we still waiting on tarsius?

[brotzeit]

@bqv I have to make a confession. I already planned to reach out to @tarsius to apologize that I didn't continue the work from libegit2. There is a possibility to avoid C and the emacs module system by using rust instead(which I prefer) and that's emacs-ng. I couldn't motivate myself to continue the work from this repository for these reasons. Funny that you are asking now because I just started to work on it. I already got a working solution for magit-blame but unfortunately the related libgit code isn't as fast as I hoped(libgit2/libgit2#3027).

I will experiment with other commands because it's really fun to implement it this way. But I don't know if I will be able to make substantial improvements(I'm not a very experienced programmer).

[tarsius]

No need to apologize I certainly haven't been prioritizing this either...

There is a possibility to avoid C and the emacs module system by using rust instead(which I prefer) and that's emacs-ng.

Using rust instead of c but sticking to the emacs module system also was an option we considered. I guess we could reconsider that, but a lot of work went into the c implementation so I wouldn't want to throw that out without a very good reason. (Such as someone having finished an implementation that uses rust.)

But that's not what you are talking about. Howe does emacs-ng relate to remacs? Could emacs-ng at least theoretically become emacs (i.e., willing to assign copyright to fsf)? In any case I want to support the emacs that people actually use, so depending on remacs, emacs-ng, guile-emacs ... are not really options.

[brotzeit]

No need to apologize I certainly haven't been prioritizing this either...

I just felt bad because you helped me with my package and now I choose to extend your work with a toolset I knew you wouldn't/can't use.

In any case I want to support the emacs that people actually use, so depending on remacs, emacs-ng, guile-emacs ... are not really options.

That's the right thing to do, if I would maintain magit I would have a tough decision. I see what I'm doing more as an experiment that might show the emacs community that different ways of doing things might be better than what we are doing now(or at least that trying new things is a good thing). But since emacs-ng is just a superset of emacs, it probably should rather be considered as something like doom-emacs or spacemacs and not remacs and guile-emacs.

[bqv]

Just FYI, I'm in that crowd of not being interested in emacs-ng at all. I'm not trying to discourage you @brotzeit, just giving validity to @tarsius's thoughts