Skip to content

Conversation

@yarikoptic
Copy link
Collaborator

More about codespell: https://github.com/codespell-project/codespell .

I personally introduced it to dozens if not hundreds of projects already and so far only positive feedback.

CI workflow has 'permissions' set only to 'read' so also should be safe.

…(but ignoring overall fail due to ambigous ones)

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w || :",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^
…nteractively

=== Do not change lines below ===
{
 "chain": [],
 "cmd": "codespell -w -i 3 -C 4",
 "exit": 0,
 "extra_inputs": [],
 "inputs": [],
 "outputs": [],
 "pwd": "."
}
^^^ Do not change lines above ^^^
Copy link
Member

@smichel17 smichel17 left a comment

Choose a reason for hiding this comment

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

The rest looks good


const threshold = 300;
dy = Math.min(threshold, Math.abs(clone.y - this.initialY));
dy = Math.min(threshold, Math.abs(clone.y - this.initially));
Copy link
Member

Choose a reason for hiding this comment

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

This one is wrong. Can it be smarter about camelCase and/or only linting comments?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

oh, missed that. We can add regex to exclude all camelCases, e.g. `\b[a-z][A-Za-z]+\b' (Python regex), do you want me to do that? or we could exclude some specific ones like this to minimize possible false negatives.

Copy link

@okias okias Oct 17, 2025

Choose a reason for hiding this comment

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

I think initalY is not very well readable, and if there is no strong reason to keep it that way, I would suggest renaming the variable.

@yarikoptic
Copy link
Collaborator Author

should I rebase into develop?

PS FWIW, in some projects we eventually switched everywhere default branches to be the ones to seek PRs into to avoid hassle of needing to ask to rebase etc. Should may be develop to become the default branch to be cloned / sent PRs to?

@smichel17
Copy link
Member

Yes, all PRs should go to develop.

I wasn't involved with the decision to set up the branches how they are now (See CONTRIBUTING.md for history (it's short)). But release is the default to facilitate people who are obtaining paperwm from github instead of getting it through extensions.gnome.org (at one point during the transition to a community project, paperwm was not on extensions.gnome.org).

We could probably do a better job of handling the install process (I'd guide people to use the gnome-* branches instead of release. Personally I use a git worktree to install my running version, rather than the symlink that the install script creates. (Related: #1061)

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.

3 participants