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

Extend tutor file #2133

Merged
merged 40 commits into from
Apr 29, 2022
Merged

Extend tutor file #2133

merged 40 commits into from
Apr 29, 2022

Conversation

n0s4
Copy link
Contributor

@n0s4 n0s4 commented Apr 16, 2022

Here are the sections I've added:

  • yanking/pasting
  • switching case (~)
  • setting case (` A-`)
  • Jumplist (C-s C-i C-o)
  • Searching in file (/ ? n N)
  • Joining lines (J)
  • indenting lines (> <)
  • opening lines (o O)

Also now adds section numbers (1.1, 1.2 etc. ).

I'm not 100% on the order of the sections, e.g maybe yanking and pasting should come earlier, but I've left the previous part of the file mostly untouched.

@Omnikar
Copy link
Contributor

Omnikar commented Apr 16, 2022

The gaps separating the sections were intentional; they were such that there is an even amount of space between each section header (regardless of how much content is in the section) so that in an 80x24 terminal, page-up and page-down will smoothly switch between sections, keeping headers right at the top of the screen.

runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
@n0s4
Copy link
Contributor Author

n0s4 commented Apr 16, 2022

Thanks for all the feedback. I'll work on this soon as I can.

Copy link
Contributor

@Omnikar Omnikar left a comment

Choose a reason for hiding this comment

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

Missing capitalization:

  • "Selecting to a Character" steps 2–4 and "Helix" and "Vim" in the note
  • "Selecting 'til a Character" steps 2–3 and "Helix" and "Vim" in the note
  • First "Recap" of the PR bullet 5
  • "Copying and Pasting Text" steps 2–3 and "Helix" in the first note
  • "Setting Case" steps 2–3
  • Second "Recap" of the PR bullet 4
  • "Joining Lines" steps 2–3
  • "Indenting Lines" step 2

Missing periods:

  • "Selecting to a Character" step 3
  • "Selecting 'til a Character" introductory text and step 4
  • First "Recap" of the PR bullet 3
  • "Copying and Pasting Text" step 4 and second note
  • "Switching Case" step 2
  • "Setting Case" step 3
  • "Macros" step 4
  • Second "Recap" of the PR all bullets
  • "Indenting Lines" introductory text
  • Third "Recap" of the PR bullet 3

runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
This is so that - on a 24 line terminal -
only one section is visible at a time and
page up/page down goes straight to the next
section keeping the header at the top.
@n0s4
Copy link
Contributor Author

n0s4 commented Apr 16, 2022

The gaps separating the sections were intentional; they were such that there is an even amount of space between each section header (regardless of how much content is in the section) so that in an 80x24 terminal, page-up and page-down will smoothly switch between sections, keeping headers right at the top of the screen.

Alright I have largely resolved this but the section "copying and pasting text" is too big to fit on the screen. I'm thinking removing the "Note:" part of the footnotes or splitting this into two sections: 1 for yanking and 1 for pasting, what would you suggest?

Edit: By the "Note:" part, I just mean the word "Note:", note the whole thing. Just trimming off extra words to squeeze it to fit.

n0s4 and others added 6 commits April 16, 2022 19:04
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
Co-authored-by: Omnikar <omkar.subramaniam@icloud.com>
@n0s4
Copy link
Contributor Author

n0s4 commented Apr 16, 2022

I am having a not very good time with git. I can't git push the branch because it's "behind it's remote counterpart". I have git pulled from my fork but it's apparently up to date. I'm really sorry, I'm still new to using git/github so if you have any help that'd be very appreciated.

@Omnikar
Copy link
Contributor

Omnikar commented Apr 17, 2022

The solution to that should be git stashing your changes, pulling from Github, then git poping your changes.

@Omnikar
Copy link
Contributor

Omnikar commented Apr 17, 2022

The gaps separating the sections were intentional; they were such that there is an even amount of space between each section header (regardless of how much content is in the section) so that in an 80x24 terminal, page-up and page-down will smoothly switch between sections, keeping headers right at the top of the screen.

Alright I have largely resolved this but the section "copying and pasting text" is too big to fit on the screen. I'm thinking removing the "Note:" part of the footnotes or splitting this into two sections: 1 for yanking and 1 for pasting, what would you suggest?

Edit: By the "Note:" part, I just mean the word "Note:", note the whole thing. Just trimming off extra words to squeeze it to fit.

Hm, separating yanking and pasting into different sections doesn't make sense; I'll have to think about what to do.

@n0s4
Copy link
Contributor Author

n0s4 commented Apr 17, 2022

The solution to that should be git stashing your changes, pulling from Github, then git poping your changes.

git stash says No local changes to save. Looking in my github repo, the tutor on this branch is definitely more up to date than my local repo. But git pulling has no effect because it's "already up to date". 😮‍💨

@Omnikar
Copy link
Contributor

Omnikar commented Apr 17, 2022

Are you looking at the correct branch on your local computer?

@n0s4 n0s4 requested a review from pickfire April 20, 2022 20:11
runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
Copy link
Contributor

@pickfire pickfire left a comment

Choose a reason for hiding this comment

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

Nice, looks a lot better to me but still left some comments for minor changes.

@n0s4
Copy link
Contributor Author

n0s4 commented Apr 21, 2022

I think there has to be a clear convention on when to say "press" and when to say "type". Seems a bit petty but there can be clear inconsistencies without one and saying just one for everything doesn't make sense.
This is a rule set that I've come up with along with reasoning, let me know what you think.

  1. Single lowercase letters are "press".
  2. Single uppercase letters are "type" because of the shift key needed.
  3. Single symbols and punctuation are "press" to adhere to different keyboard layouts. Different layouts have different symbols available at one keypress.
  4. Any key combined with ctrl or alt is "type" as it is one than more keypress.
  5. When referring to multiple keys at once like "hjkl" or "f/F" say "use".

I've mentioned that saying "use" in all cases would be an easy solution and more consistent but it's a little strained and "press"/"type" usually seems more natural.

@n0s4 n0s4 requested a review from pickfire April 21, 2022 22:12
@pickfire
Copy link
Contributor

I've mentioned that saying "use" in all cases would be an easy solution and more consistent but it's a little strained and "press"/"type" usually seems more natural.

cc @Omnikar what do you think? Should we just use the same "press" for everything so to not assume which layout the user is on? For example for dvorak for programmer (dvp) pressing 3 is {.

@Omnikar
Copy link
Contributor

Omnikar commented Apr 23, 2022

I think the best solution is to always use "type" honestly.

@n0s4
Copy link
Contributor Author

n0s4 commented Apr 23, 2022

Ok, let's just go with that.

runtime/tutor.txt Outdated Show resolved Hide resolved
runtime/tutor.txt Outdated Show resolved Hide resolved
@n0s4 n0s4 requested a review from pickfire April 26, 2022 21:53
Copy link
Contributor

@pickfire pickfire left a comment

Choose a reason for hiding this comment

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

Thanks. I think this should be good now, since this is tutor file and no other maintainers is reviewing this so I guess I will merge this for now.

@pickfire pickfire merged commit e10cf08 into helix-editor:master Apr 29, 2022
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.

4 participants