Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Restrict comments to 100 characters #4668

Merged
merged 1 commit into from Aug 12, 2023
Merged

Conversation

Tyriar
Copy link
Member

@Tyriar Tyriar commented Aug 12, 2023

This is a rule I try enforce in PR but it's a bit of a hassle, this will give a lint warning when it happens resulting in:

  • Yellow underline in supported editors when eslint is installed
  • Compilation will succeed since it's a warning not an error
  • CI will fail as it does not allow lint warnings

Special case comments are ignored which includes @vt comments, table comments and commented out code.

This is a rule I try enforce in PR but it's a bit of a hassle, this will
give a lint warning when it happens resulting in:

- Yellow underline in supported editors when eslint is installed
- Compilation will succeed since it's a warning not an error
- CI will fail as it does not allow lint warnings

Special case comments are ignored which includes @vt comments, table
comments and commented out code.
@Tyriar Tyriar added this to the 5.3.0 milestone Aug 12, 2023
@Tyriar Tyriar self-assigned this Aug 12, 2023
@Tyriar Tyriar enabled auto-merge August 12, 2023 16:06
@Tyriar Tyriar merged commit 519f6a3 into xtermjs:master Aug 12, 2023
8 checks passed
Tyriar added a commit to Tyriar/xterm.js that referenced this pull request Aug 12, 2023
Similar to xtermjs#4668, this brings linting to the API files with a cut down
set of rules. One of the bigger ones is comment length is restricted to 80,
this was done as opposed to 100 for regular code to reduce the chance of
wrapping or API going off screen regardless of resolution or window/browser
size
@Tyriar Tyriar mentioned this pull request Aug 12, 2023
@jerch
Copy link
Member

jerch commented Aug 12, 2023

Hmm yeah the @vt docs clutter the source files to some degree, this is quite obvious when scrolling through inputhandler. Still I find the idea to have that close to source very important, otherwise docs tend to fall behind all the time (also happens to doc strings, but imho to a lesser degree than for completely separate docs).
At least for me the issue is not a biggy, as the display is big enough to still give the right amount of overview on the source, even with those nasty huge markup tables. I also dont know of any good way to shorten those.
Well, at least the @vt lines could be reshaped to store their info vertically instead of horizontally, but I am unsure, if that make anything better?

@Tyriar
Copy link
Member Author

Tyriar commented Aug 12, 2023

I like the @vt comments, no problems having them and the other exceptions be longer. I just want to automate some consistency so I don't have to call it out in PRs as much

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants