Please document reason for fork

[tarsius]

I am just getting started with Rust and am trying to determine whether to use rust-mode or rustic. From the look of it, it will take quite some time to make an informed choice so I decided to ask you for some clarification to save myself and others in the same position part of the effort.

Your readme mentions some features that rustic has but rust-mode lacks. That's a nice start but many questions come immediately to mind that are not addressed by a simple list of features, such as:

1. Does rust-mode still lack those features?
2. Do you port rust-mode improvements to rustic? Other way around?
3. Why fork in the first place? Conflict?
4. Assuming the fork is due to them wanting to continue to provide just the major-mode and you wanting to do a batteries-including ide: why did you fork rust-mode.el? Couldn't you have contributed to that in the upstream repository and make rustic depend on that?
5. Would it make sense to break up rustic into multiple smaller packages? I had to install quite a few dependencies that I am not actually going to use just so I could compile.
6. What happens if both packages are installed?

Errr.... I just saw that you commented on the issue tracker of the rust-mode repository.
That leaves me more confused than before, but also more hopeful.

[tarsius]

Re #91.
Re rust-lang/rust-mode#353.
😜

[brotzeit]

I'm at work now, but I will answer your questions when I'm home and add it to the readme.

[brotzeit]

I will provide some background to this situation.

About two years ago I started adding some features that I wanted to be in rust-mode(rust-lang/rust-mode#255). Unfortunately rust-mode doesn't have active maintainers for quite a while so it was difficult to get pull requests merged, that were bigger than some lines of code. At some point I was kind of frustrated and somebody, I think it was actually you @tarsius, told me he took over maintainership for a package(I really think it was you, so magit^^) because there was no maintainer.

So I decided to give it a try and created a pull request on melpa. Half a year ago I suggested to also maintain rust-mode (rust-lang/rust-mode#317). The result was that @mookid and I decided to give it a try. I leave out the details because you can read it in the issue.

We discussed how to proceed, via mail. The idea was what you actually mentioned in 4). Due to a lack of time we didn't make those changes.

Actually, I rather wanted to spend my time on projects like remacs and lsp-mode etc., because I thought this was more valuable. And this is still my opinion. I would very much appreciate pull requests or give write access to others, but I won't spend time on this any time soon.

So the answers to your questions would be:

1. AFAIK, yes
2. I did, but maybe not everything. And no, because we decided to keep rust-mode as a lightweight alternative.
3. No conflict. Nobody had the time for it.
4. That was the plan, if feasible.
5. If it makes sense, why not. I planned to at least reduce the number of dependencies. I also don't like that, but it was too convenient at that time...
6. You have to require rust-mode before rustic, so rust-mode can be deleted from auto-mode-alist.
   I guess there will also be problems when you automatically format files on save. There's probably more.

[tarsius]

After reading this and rust-lang/rust-mode#317 I think the consensus is that we should avoid code-duplication, that getting there will be a lot of work, and that there will be complications. 😉

I will try to help out but keep in mind that I am a beginner and that my priorities lay elsewhere too.

Before we can even tackle reconsolidating the two packages in one form or another, I think we first need to cleanup rustic. Emacs byte-compiler doesn't force you to deal with issues, but it would be nice to not ignore it completely either. 😜

Expect pull-requests that fix these errors and do other cleanup shortly.

[brotzeit]

Sounds great =)

[tarsius]

I ended up not really learning rust last year, but I just picked up the book again...
Anyways, for now I have just some rather minor fixes and changes in #237.