[keymap] Add tiny text, full width characters to Ergodone->Vega

[VegaDeftwing]

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

• Added the ability to abuse superscript and full width unicode characters to my keymap

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.

Yes, it's in my master. I know how to use git, but this change is small enough I just don't care.

• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[tzarc]

Yes, it's in my master. I know how to use git, but this change is small enough I just don't care.

That's a shame.

[VegaDeftwing]

Yes, it's in my master. I know how to use git, but this change is small enough I just don't care.

That's a shame.

I did it from Master because after the PR is complete, I'll delete my fork. I do this because my Github account has one, really, really big repo on it that eats space and the smaller I keep my account the less I get nastygrams from Github and because I like to keep my profile only having repos that are either mine or that I'm actively contributing to - as this is my first commit here in years, this doesn't meet that for me. All of this means if I ever make a change again, I'll just re-fork. As this has no effect on the PR or on the repo I'll delete anyway, I see no reason to make a new branch and waste my time. Of course, now that you've decided a rule should be enforced blindly and I have to explain myself, it's using more time anyway.

So, ultimately, if you think ᵗʰᵉ ᶜᵒᵐᵐᵘⁿⁱᵗʸ ᵃᵗ ˡᵃʳᵍᵉ ʷᵒᵘˡᵈ ᵇᵉⁿᵉᶠⁱᵗ ᶠʳᵒᵐ ʰᵃᵛⁱⁿᵍ ᵗʰⁱˢ ᵘⁿⁱᶜᵒᵈᵉ ᵐᵃᵖᵖⁱⁿᵍ ᵃˡʳᵉᵃᵈʸ ˢᵉᵗᵘᵖ ᶠᵒʳ ᵗʰᵉᵐ, I think ｔｈｉｓ ｓｈｏｕｌｄ ｂｅ ｍｅｒｇｅｄ. If you don't, don't. But I'm not going to update the PR to put it in a different branch that I'm just going to delete anyway.

[tzarc]

Glad we're on the same page.

[tzarc]

QMK is an open-source project run by volunteers.

To gain some perspective, please have a read of these links:

• Don't be that open-source user, don't be me
• Open Source Maintainers Owe You Nothing
• GitHub Etiquette

[VegaDeftwing]

QMK is an open-source project run by volunteers.

To gain some perspective, please have a read of these links:

• Don't be that open-source user, don't be me
• Open Source Maintainers Owe You Nothing
• GitHub Etiquette

I have read all of these before (I, too, read Hacker News!). And I agree, you owe me nothing. I also have a large (not this large, but point still stands) open source project I maintain. But, as I explained, the difference in me using a different branch is quite literally irreverent after this is merged - there won't even be history of it, as I'll be deleting it. I went though the tedious process of enumerating code points in a logical way so that others could steal it and add it to their keymaps too, I thought this was valuable, so I didn't keep it to myself.

I put,

Yes, it's in my master. I know how to use git, but this change is small enough I just don't care.

not because I don't care about QMK, but because I tried to save you the effort of pasting the how to git page. Instead, we've now wasted multiple minutes of both of our lives and probably annoyed eachother instead of turning this into positive interaction. I was actually considering paying it forward and reviewing a stack of PRs too. I would still like to do that, but I want to know this project is one that assumes the best of people first.

As the last link says, "Don't patronize" - I don't assume I know more than you, hell, I know I don't. But you also shouldn't assume you know more than me either.

[drashna]

Just a heads up, this sort of thing has been iterated a few times:
https://github.com/qmk/qmk_firmware/blob/master/users/drashna/keyrecords/unicode.c
https://github.com/qmk/qmk_firmware/blob/master/users/drashna/keyrecords/unicode.md

which allows for a natural typing experience, even on multiple different firmware defined keyboard layouts. It also doesn't require the full unicode feature, but just the core code for sending unicode.

[VegaDeftwing]

Just a heads up, this sort of thing has been iterated a few times: https://github.com/qmk/qmk_firmware/blob/master/users/drashna/keyrecords/unicode.c https://github.com/qmk/qmk_firmware/blob/master/users/drashna/keyrecords/unicode.md

which allows for a natural typing experience, even on multiple different firmware defined keyboard layouts. It also doesn't require the full unicode feature, but just the core code for sending unicode.

Ooh! Thank you for the heads up. I just did a basic copy of the greek and math layers I had already done, but this is a much cleaner way to do it for the two I've just added. Though, I think I prefer it be consistent in my keymap anyway.

Any chance we can re-open this PR?

[tzarc]

Yes, it's in my master. I know how to use git, but this change is small enough I just don't care.

I think you're hung up on the fact that you're using master. If you're keen on reading the PR Checklist document, you'll note that it's using a "should" and that we have a note for ourselves after merge to let you know how it should occur. This implies that we do indeed allow PRs to be raised from a user's master branch, but try to educate them after the fact because we understand that there are complications in trying to get people to swap branches if they're unfamiliar with git.

However, there are a multitude of other things in the PR checklist, some of which aren't being followed in your PR.

It seems your argument is based on "not wasting time", and whilst I agree that there's been far more discussion here than what normally would have been warranted, I should point out that the entire point of the PR Checklist is so that you, as a PR submitter, have something to work towards without requiring to-and-fro during subsequent reviews. It also helps us, in the sense that we can ask PR submitters to refer to that document in order to eliminate a significant number of fairly regularly-submitted problems.

As it stands, at least one of your files is missing compatible license headers. I feel no real motivation to go through the checklist on your behalf, so I'd implore you to go through the checklist in its entirety and apply anything that affects your PR. Looking at the first item in the checklist, disputing it, and disregarding the rest of the document does not bode well for future interactions.

[VegaDeftwing]

Apologies, I was under the impression the licence was implied to be the same as the project given it is already existing in the code base, fixed in b99f0ea. I also ran Clang Format, fixing up some of the indention mess I'd left behind.

[drashna]

Apologies, I was under the impression the licence was implied to be the same as the project given it is already existing in the code base

in a repo that has only one license type used, that's a fine assumption to make. But we have gpl2+, Apache, and a number of others that are used in different files/areas. So, we want it to be explicitly stated on any source files, so there is no doubt.