Should editor configs live in seperate repositories?

[mcpherrinm]

Right now, Vim, Emacs, Kate, and gedit configuration lives in /src/etc/. Not only is this tricky to find if you didn’t know where to look, it’s pretty user-unfriendly to somebody who doesn’t want to have to check out the whole rust git repository – even with a shallow clone, it’s pretty big.

I think each editor ought to live in its own repository.

Support on IRC seemed strong: Apparently some people use tools to manage their editor configurations, and while I’m unfamiliar with them, they claim the editor-per-repo setup would be much more convenient.

An alternative is all the editors, and maybe zsh/bash completions, in a rust-lang/extras repository.

[lifthrasiir]

Support on IRC seemed strong: Apparently some people use tools to manage their editor configurations, and while I’m unfamiliar with them, they claim the editor-per-repo setup would be much more convenient.

An example to this is Vundle, which allows for installing plugins via Github. With Vundle and separate repo a single line (Plugin 'rust-lang/rust.vim') can be added to .vimrc to get the highlighting and other goodies.

[tomjakubowski]

A compromise could be to set up individual editor repositories which periodically pull in changes to rust.vim and rust-mode.el and the like from the main repository. There are some probably some conveniences to having editor plugins in tree.

[huon]

A compromise could be to set up individual editor repositories which periodically pull in changes to rust.vim and rust-mode.el and the like from the main repository. There are some probably some conveniences to having editor plugins in tree.

This actually already happens for vim (not an official rust-lang/... thing though), and emacs supports loading packages as arbitrary individual files inside git repos.

[nrc]

+1 we can’t have plugins for every editor in the tree, and certainly not for IDEs too. Already some plugins (e.g., Sublime Text) are out of tree. I would prefer to move Vim, Emacs, etc. out too.

[brson]

I would be fine with moving the existing editor configs and shell completions out of the tree.

It would be super-nice to have a curated list of well-maintained editor configs/plugins somewhere easily discoverable.

[nrc]

I have started making a list of all kinds of Rust tools (including editor plugins), its only a start though. Putting it somewhere easily discoverable is probably the hard part.

[nathantypanski]

Possible community incubation strategy for tools:

1. Share your draft with the world. Maybe put it on the user wiki so it’s easy to hack at.
2. Lobby for some contributions on IRC or here or something, so you don’t miss anything important the first time around and people feel like they’re involved.
3. Make it “good enough to be worth people’s time”, and then get it on the Rust Documentation Index. Presumably it should go under the Tools section, no?
4. Make a Reddit post on /r/rust for initial attention. In the post ask people if they’d like to see your tools list on the sidebar. If they do, great - the community is still small enough that it’s worth having a “great Rust devtools” link in the sidebar there and it won’t be cluttered.

Why do it like this?

• This has the benefit that anyone who has been involved with Rust for a while will both eventually find it, since they’re guaranteed to check the doc index eventually, and will know where to shoot a pull request if they realize something is missing.
• Another benefit of having an “curated great Rust utils list” is getting your code on the list is automatically kinda prestigious. This can encourage people to spend their time developing awesome out-of-band Rust tools, since they know that a sufficiently decent one could end up on the list.
• An official list necessitates a higher standard of quality for the linked tools, since they get linked from the official site. But versus a list that links nearly everything, this strategy is skewed to benefit older/more established tools - even at the expense of some “cool new thing” that deserves attention.

Analogies in other languages

For inspiration on ways of approaching this. IMO we should be trying to emulate Erlang and not just have a wiki page somewhere like Haskell and Python do, but perhaps still linking to a bigger - and less curated - list that is easier to change.

• Erlang’s official Erlang FAQ Tools page.
• cat-v.org’s Go dev utils page (no longer updated, but that’s not the point)
• Haskell’s Development libraries and tools wiki page
• Python’s Development tools wiki page

[system]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.