Add vim modeline for indentation

[slowbro]

I'd like to add the following vim modeline to all .rb files in tty-* gems:

# vim: expandtab ts=2 sw=2

It would be the first line in each file. This would help contributors who use vim greatly, especially if they are on the tab side of the space-tab wars - no more fighting with indentation.

I'd be willing to do pull requests for tty-* repos with these changes; I just wanted to bring it up here first and test the waters.

---

Semi-related:

I'd also like to argue the following: for a public code project, I believe tabs are a more 'friendly' option. I used to use spaces, myself (just look at my old code - wait... don't do that) - but my friend @mahlonsmith set me straight.

I believe this because most, if not all code editors allow customization of how tabs are displayed. Do you want a tab to be 2 spaces? 4? 150? Easy - in vim, set ts and sw. But if a project uses spaces, it's not easy to expand the 'tabs' if I need a bit more definition. Tabs enable readability when needed can be suited to any one programmer's sensibilities.

My :2cents: - I'd be happy with just the modeline :)

[piotrmurach]

Hi Katelyn,

That's a bit unusual suggestion.

I'm reluctant to introduce editor specific configuration things into source files. I'm already not a big fan of frozen_string_literal but can see its utility in making my code ready for Ruby 3. I added emacs configuration magic comments in the past - a mistake(i'm a Vim user for more than a decade). More importantly, I like to keep source code pristine and devoid of unrelated things. I'd be more open to introducing a more robust solution like https://editorconfig.org/.

Having said that, I'm also keen on consistency and keeping things formatted in the 'standard' way across all my Ruby projects(nearly 60). Hopefully, in the near future, I can automate more things that I currently do manually - e.i. add tty-bot to help review things.

As for making it 'friendlier' for others to contribute. I haven't heard a mention about indentation before either being hard to deal with or preventing contribution. So on a practical level, I don't think that one or the other approach makes things more approachable. By convention Ruby files are 2 spaces indented, other language choose differently. I've seen occasionally Ruby projects with tabs and browsing their source code in GitHub was hard, to say the least. The code looked like it was blown away by the wind and required a lot of horizontal scrolling 😄

[slowbro]

Ah, I didn't know about editorconfig - I think that's a good idea. It would allow the format specification to be more platform-agnostic instead of just a vim modeline :)

My main problem is I have smarttab enabled and use tabs; so when I'm coding for tty*, I end up spending a lot of time messing with fixing smarttab and removing the tabs, or fixing whitespace changes in diffs. I know I can just change my vimrc... but the box I use for development is also used for work and personal stuff, which is all tabs.

Speaking of consistency; I see the HoundCI complaints a lot but some of them seem arbitrary or not matching to how most of the codebase is. For example, I got a warning on a recent pull request about "TrivialAccessors" - i.e. using attr_writer instead of def whatever(stuff) @whatever=stuff end - are those the code standards of Hound, or should those be heeded? If they should, does that mandate a rewrite of all the other matching parts of the codebase?

Again, I'd love to help with consistency and any changes! I enjoy this project very much, and use it regularly.

[slowbro]

I put in a PR for a .editorconfig that I believe matches the style you'd want. If that looks good, I can put in similar PRs for all other tty-* repos.

[piotrmurach]

Thanks for adding the editorconfig config - I've reviewed the options and they seem like sensible defaults. Updating 20 something tty projects seems like a lot of effort. 😅 I'm happy for you to add this to other projects. Whatever project I'm working on, from now on, I will include the editor config as well. I kind of wish for some centralized solution that we could have for tty projects that would automate pushing out such changes to all the projects in one go. There are other templates like .rubocop styles that could do with being in all the projects to keep styling consistent. In the future, we could even use tty itself to help us build such a tool.

As for the HoundCI, I added it a long time ago as a quick and easy way to help me review PRs. Not necessarily to make the PRs comply with hound but to flag things up for me while reviewing. What we could do is match codebase rules by linking .rubocop config with .hound.yml config. However, in the long term, I would like to build up a tty-bot that would review PRs based on GitHub actions/workflows. For example, one of the things it could check for is that a PR modifies the changelog file.

Just to share a little of what I'm thinking. I have "big" plans for tty gem itself this year. I think the future API and how commands work could be even more intuitive and nice. It's probably cliched but I'd like to strive to provide Rails like familiarity and effectiveness in a more "functional" and "no-monkey patching" way. I'm currently "incubating" ideas and hoping to get some funding. It needs some concentrated effort. Let's see what the future holds.

[slowbro]

That's great! Excited for the future of tty :)

I'll add PRs for the other repos as time permits. Thanks, Piotr!