06-my-first-pull-request.md (2884B)
1 # My First Pull Request 2 3 ## 06/16/2020 4 5 I was finally ready to make my first pull request. After double checking, and checking again, I knew my changes were ready to merge. I typed up a short summary of what I did, and how it was implemented. I refreshed the pull request page on Github every ten minutes for a few hours until I finally got the response I was waiting for: 6 7 >"Please fix the indentation problems. Github diff page should show you." 8 9 Oops. 10 11 ### Finding My First Project, or The First Victim of my Bad Convention-Following 12 13 The project I contributed to was [nnn](https://github.com/jarun/nnn), a nifty little file manager written with C and Curses for Vim-like browsing and keyboard-oriented navigation. I'd never actually used nnn prior to contributing, but the especially easy to read code let me discover and contribute pretty much within the same day. 14 15 ### Tackling The Issue 16 17 The issue at hand had to do with how Curses handled the hardware cursor. Text is drawn by Curses based on where the cursor is, but upon the refresh of the screen, the cursor always gets placed at the bottom of the screen, with the status bar. Normally, the cursor is invisible, since we don't use it in the program, but we can see it if we recompile the program with curs_set(TRUE) instead of curs_set(FALSE). 18 19   20 21 See the difference between the selected item and where the cursor "actually is"? 22 23 This happens since the status bar is drawn last, and since it isn't important where the cursor is, then we can leave it where it got sent last. The problem is that some accessibility tools like screen readers rely on the cursor's position to detect what someone is looking at. The simple solution is to add a launch option, and then simply move the cursor to the selected item automatically when it's enabled, specifically after Curses is done drawing all the text onscreen. Since the currently selected item's line was already defined, this was easy. 24 25  26 27 Much better. 28 29 ### Code Quality 30 31 My changes were eventually merged, but my indentation and ignorance of conventions within the project got slammed. Pretty much every line I added had to be sanitized of silly mistakes. Oops. The kind maintainer was willing to fix my changes and push to master. 32 33 ### My Tips for New Open Source Contributors, Like Myself 34 35 You probably want to contribute to a project you're already fond of. This project was particularly well documented and minimalistic, with only one C file to keep track of. Knowing a program well in usage will let you be more pragmatic when deciphering code. Also, follow code conventions. You might be able to implement a requested feature or fix, but you want to know you're doing it the best way possible. At the end of the day, you're deciding to contribute to software that helps out everyone. Keep at it.