Skip to content

vscode: update editor settings and commit constraints #28306

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.

Sign up for GitHub

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

Merged
hnyman merged 1 commit into from
Mar 13, 2026
Merged

vscode: update editor settings and commit constraints #28306

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
11 changes: 9 additions & 2 deletions .vscode/settings.json
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,3 +1,10 @@
{
"git.alwaysSignOff": true
}
"git.alwaysSignOff": true,
"files.trimTrailingWhitespace": true,
"files.insertFinalNewline": true,
Copy link
Contributor

@bam80 bam80 Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Never understood why it's needed.

Copy link
Member

@GeorgeSapkin GeorgeSapkin Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more. 

echo -n a > a
echo a > b
echo b >> b
diff -u a b
--- a   2026-01-09 23:39:47.701093532 +0200
+++ b   2026-01-09 23:39:47.701093532 +0200
@@ -1 +1,2 @@
-a
\ No newline at end of file
+a
+b
echo a > a
echo a > b
echo b >> b
diff -u a b
--- a   2026-01-09 23:40:21.501894017 +0200
+++ b   2026-01-09 23:40:21.501894017 +0200
@@ -1 +1,2 @@
 a
+b

Copy link
Contributor

@bam80 bam80 Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, I never felt in need of that for myself, but if you think it's worth it - go ahead.

Copy link
Contributor

@bam80 bam80 Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Isn't it the default behavior anyway?

Copy link
Member Author

@BKPepe BKPepe Jan 12, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In practice, though, you’ll encounter this issue more often on Windows, mainly because Windows editors are more likely to allow saving files without a trailing newline (or have mixed line-ending settings).

"files.trimFinalNewlines": true,
"files.eol": "\n",
Copy link
Contributor

@bam80 bam80 Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it really necessary?

Copy link
Contributor

@danielfdickinson danielfdickinson Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The formality checks will fail if these are not true, so having a common editor make it easy to adhere to desired style makes sense to me.

If you disagree with the formality checks, that is another discussion (though personally I think that ship has sailed).

Copy link
Contributor

@bam80 bam80 Jan 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry I don't bother to read the manual.
What I'm asking here is eol specifically - in what conditions it's not \n, on Windows?
And if you know - where is the corresponding formality check?

Copy link
Contributor

@danielfdickinson danielfdickinson Jan 10, 2026 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah. Sorry didn't realize was only the eol. I think MacOS is even weirder (\r only or \n\r - I can never remember exactly). I don't know if there is a formality check for this (though it would be useful to have) but things will fail in funky, non-obvious ways if the line-endings are wrong.

Setting Git correctly is the best defence for this, really. If there is a .gitattributes or other Git way to address this at the repo level it would be better.

I'm thinking particularly for newbies who genuinely want to help, or similarly with well-meaning occasional contributors.

[aside: don't read if you're in a bad mood and can't respond well to honesty]

It is unfortunate that the type of contributors who get upset and abusive over non-acceptance or being asked for changes makes regulars grumpy and less willing to help the good ones. And then there is the fact that sometimes it is really not the contributor who is being unreasonable and unpleasant. We are all human, and some grouchier and less helpful than others, regardless of regular contributor status or not.

I personally, whether on a project where I am lead or an occasional get annoyed with 'unpleasant individual' whether they are regulars, new, or occasional.

The "Be nice to each other" rule of OpenWrt seems to not be particularly well practised by some members of the community, and makes the project more hostile than it should be.

The project isn't supposed to be here to make anyone feel superior or entitled, nor to cater to free riders (especially unpleasant ones), or other undesirable attitudes and traits.

In my view it is about collaborating on making something great for all of us.

[/aside]

Copy link
Contributor

@bam80 bam80 Jan 10, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In my impression IDEs usually follow what majority of the project have for eol, so they always auto set it to the right thing whichever OS you are on.
I might be wrong on this.

Copy link
Contributor

@danielfdickinson danielfdickinson Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair comment, and no I have not. Enforcing EOL editor-side is not something I have needed because I configure git for that. It might be good if @GeorgeSapkin could check for wrong line endings in the formalities, and if contributors are having problems with it, we could revisit.

Copy link
Member Author

@BKPepe BKPepe Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Working on it GeorgeSapkin/hyperstickler#11 💪

Copy link
Contributor

@bam80 bam80 Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"files.eol": "\n",

Copy link
Contributor

@bam80 bam80 Jan 11, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Or if we want some kind of not necessary needed duplication of the formalities here, let's keep them separated and commented out.

Copy link
Contributor

@danielfdickinson danielfdickinson Jan 15, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

files.trimTrailingWhitespace": true is problematic when editing patches. It seemed like a good idea... Now I remember why I didn't have that option still enabled in my editor.

"git.inputValidation": true,
"git.inputValidationSubjectLength": 60,
Copy link
Contributor

@danielfdickinson danielfdickinson Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@GeorgeSapkin I thought the formality check was for 50 characters. Am I mistaken?

Copy link
Member

@GeorgeSapkin GeorgeSapkin Jan 9, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's a soft limit of 50 and a hard limit of 60. Soft limit results in a warning, hard - in a fail.

"git.inputValidationLineLength": 75
}
Loading