Package maintainer

[brotzeit]

Since nobody seems to have time for maintaining the package, I would propose that I take care of this. Rustic now has some users and maybe we should suggest to use it instead of rust-mode for emacs26+. However it would be nice to get some help with this(rust-mode + rustic).

What do you think ?

[phillord]

I think having both rust-mode and https://github.com/brotzeit/rustic sounds like too much effort. As @nikomatsakis has accepted #319, rust-mode is effectively emacs-25, 26 (and plus) which makes sense as emacs-24 is now very old.

So, my question would be, can rustic and rust-mode be merged back, while support emacs-25? Even if some of the parts of the rustic code base are conditional and functionality drops? When Emacs-27 comes out (probably < six months I guess, although it's not in pretest yet, so this is a big guess), then the process of deprecating Emacs-25 support could begin.

https://github.com/brotzeit/rustic is very nice, btw. Hadn't heard about it, till I read your post here. Willing it contribute, although, my contributions are likely to be sparse.

[brotzeit]

Thanks for the feedback. I don't remember which emacs26 functions are used and how much effort it would be to make the package emacs25 compatible. But I can take a look at it when I get a response from the package maintainers. I don't care which repo we use.

[nikomatsakis]

I definitely have neither the time nor expertise to maintain this package. rustic looks great. I personally would be pretty happy to merge, I think, or else just recommend rustic (though it seems better to merge). I think it would be great to have an active maintainer.

[nikomatsakis]

I'd like to hear what @pnkfelix thinks, and I'll forward them this thread, since I suspect that they won't see it via github notifications. =)

[brotzeit]

Is it ok for you to keep the name ?

[pnkfelix]

I, like Niko, do not have the time to give this package the attention it deserves.

I am happy to hand maintenance off to another party.

I however do not understand @brotzeit 's question here (because the phrasing is ambiguous and I am not clear of the overall intent):

Is it ok for you to keep the name ?

Are you asking if this package should keep the name rust-mode, versus renaming the package? Or are you asking if I personally want to keep the name reserved, and let people migrate to a newly named package that has a properly engaged maintainer?

[brotzeit]

I'd like to keep the name rustic, that's all.

[mookid]

I believe that keeping a simple mode that focuses on correct syntax highlighting has value, and I like to use this package for exactly that reason.

Maybe both packages can peacefully coexist, with rustic being an extension of rust-mode?

[pnkfelix]

Now that I understand @brotzeit 's question, I have no problem at all with the idea that they would keep the name rustic and maintain that package itself.

It seems like we have a number of other questions to resolve here.

• Should rustic and rust-mode remain as separate active packages?
  • The most plausible alternative, if they do not remain separate (assuming I understand correctly), would be to effectively discontinue maintenance of rust-mode itself and recommend people switch to rustic or some other alternative.)
  • If they remain separate, should they be revised to at least share code (e.g. make rustic an extension of rust-mode)
  • Who should maintain rust-mode, if it remains as a separate package?

[mookid]

• Who should maintain rust-mode, if it remains as a separate package?

I can maintain if needed.

[brotzeit]

If they remain separate, should they be revised to at least share code (e.g. make rustic an extension of rust-mode)

I think this is not possible. Especially when we keep the names.

[mookid]

I think this is not possible. Especially when we keep the names.

I am not sure to understand why; I did not inspect the rustic codebase, but proper namespacing discipline should allow to work around incompatibilities.

[phillord]

@mookid Because you will have two packages one of which depends on the other (say, for example, rustic is a derived mode from rust-mode). Unless rust-mode keeps to a strong contract, any changes here will potentially break rustic.

Of course, this is true any of any derived mode, but the additional problem here is the lack of a clear delineation between the functionality that should be in one and the other. "Simple things go into rust-mode, complex things into rustic" is very dependent on your definition of simple.

[mookid]

Of course, this is true any of any derived mode, but the additional problem here is the lack of a clear delineation between the functionality that should be in one and the other. "Simple things go into rust-mode, complex things into rustic" is very dependent on your definition of simple.

let's say that the prefix "rust-" is reserved for rust-mode? Should that be more complicated than that?

As for what belongs to where, I think that it is reasonable to keep the behavior of indentation and syntax highlighting to rust-mode (which is historically the scope of major modes) while leaving the integration with cargo, flycheck, lsp... to extension packages.

Of course, this point of view does only make sense if users gain something (in particular, if rustic can reuse rust-mode code and avoid duplication of work between the two). I am just saying that I would volunteer for that work, that's all.

[brotzeit]

Is it only about indentation and syntax highlighting for you ?

There aren't only the rust related external tools. Many users like proper compile.el integration and org babel support for example.

[phillord]

@mookid possibly not, if there is a strong separation between the two. I wonder how many people would use each. It would also be possible to have a single code base with different features (i.e. indentation and syntax highlighting in one, other stuff elsewhere).

@brotzeit is right, though, rust-mode.el as it stands is more than this. It has various tools integration (including rustfmt which arguably obsoletes a lot of the indentation functionality), playpen integration and so on.

[mookid]

@phillord traditionally indentation in emacs does not rely on external processes; some users don't use rustfmf at all.
I think that tool integration should in principle move to either rustic or other packages as part of the merge ; if limitation is very simple, it can be kept for backward compatibility.

[brotzeit]

@mookid Many users want 1 package for most rust related stuff. I think it's a lot easier for new users. That's the reason why I also added lsp-mode support out of the box. But if you only want basic stuff it shouldn't be too hard to maintain rust-mode as a leightweight alternative.

[phillord]

@mookid Yes, I agree, Emacs usually indents for itself. But the world is changing -- languages are getting these formatters (rust has one, go also, probably others). There is a good case to say that, with the presence of rustfmt, just using might make sense -- there is a risk that Emacs is going to indent in ways different from rustfmt after all.

My own feeling would be that rustfmt is new enough that I would start to deprecate Emacs indentation in favour of rustfmt, but not remove it. I use rustfmt for all my new packages, but don't want to introduce lots of whitespace diffs into my old one.

From this perspective, rust-mode would be on a path to becoming very small. Anyway, I cannot offer to main either, and will contribute as I can to rust-mode/rustic as appropriate what ever is decided.

[mookid]

I still believe that there is value in a reasonable elisp implementation of indentation. I don't think that it is reasonable to launch a new executable each time a user want to reindent a line, and I don't think that such a command should have non-local effect either (what indent-for-tab-command is supposed to do but rustfmt does).

there is a risk that Emacs is going to indent in ways different from rustfmt after all.

Agreed. I think that a reasonable goal would be that code formatted with rustfmt with defaults should no be changed by rust-mode, and while ensuring that, having formatting that is close to what rustfmt does.

And in that paragraph, rustfmt means with default config (and, say, no line breaking that emacs formatting does not handle).

[pnkfelix]

From the dialogue so far, It sounds to me like there is desire to maintain a lightweight rust-mode (though my own bias preferring that outcome may be showing), and have it shift focus to providing core functionality without relying on external tools like rustfmt.

So maybe we can:

• provide @mookid with privileges for maintaining the rust-mode repo
• add notes to the README that link to useful alternatives/extensions (like rustic)
• move functionality that does rely on a "non-standard" external tool (e.g. rustfmt, rust-analyzer) out of rust-mode and into rustic
  • There may be some debate as to which functionality should move out of rust-mode, if we go down this path. At least, that's what I infer from a comment above

Would that approach make sense?

[brotzeit]

I wouldn't remove it from rust-mode, since there will certainly be also users that don't want to use rustic but want more features in rust-mode than just syntax highlighting and indentation. But on the other hand this should maybe decided by the person that volunteers for maintaining the package. We all know how hard it is to find active maintainers.

[mookid]

I think it is reasonable to maintain existing features while limiting extra additions.

[nikomatsakis]

I'm happy with most any outcome here, although it's worth noting that my attempts to install rustic all failed (in one case, because I'm using emacs25 on WSL, and in the other...well, I don't know why, I just got some obscure errors and didn't pursue it much further). So I guess that's a vote for "keep something simple for now". I think it'd be great if we could actually share core between rustic and rust-mode but I don't really know enough about emacs to know if that makes sense to pursue as an actual goal.

I have invited @mookid to join the rust-mode team. If there are others who are interested, such as @brotzeit, please let me know. As both @pnkfelix and I have noted, we clearly don't have the time (or, in my case, knowledge) to really do the job.

[brotzeit]

I can support @mookid.

[brotzeit]

@nikomatsakis I just fixed a bug if you want to give it another try. It would be nice if I also had somebody who helped me reviewing PRs...

[nikomatsakis]

@brotzeit I will, thanks! I wish I could help you in reviewing PRs :)

[nikomatsakis]

@brotzeit I've invited you to help out. Maybe you and @mookid can find some useful way to share code between this repo and rustic, maybe not... anyway, I'm going to close this issue for now, but I'd encourage y'all to try and recruit others. e.g. maybe @phillord wants to help? I know they've opened a number of PRs...

[brotzeit]

@nikomatsakis I will add a note to the readme that we are looking for additional maintainers.

[mookid]

@nikomatsakis @brotzeit I started looking into differences of parsing between the two packages and will have more time to do so this weekend.

[monnier]

Regarding the split between rust-mode and rustic: bringing them together into a single package (with some features only enabled conditionally) avoids having to decide things like whether rustfmt support should be in rust-mode or in rustic. It also makes it easier for the end-users who don't have to wonder what's the difference between these two modes. I recommend merging them (incrementally).

[valignatev]

I'm for merging them together and consolidating development in one place as well. Also, Hacktoberfest is coming which can be a good opportunity to get some easy bugs fixed by the community :)