Over the last month, I have documented my experience participating in Hacktoberfest 2019. By jumping head-first into this open source GitHub hubbub, I have learned and gained so much more than I initially bargained for. Before I touch back on my first three Hacktoberfest pull requests (in a separate post), please allow me to proudly showcase my fourth and final achievement: my work on a very “close-to-home” project, xterm.
I have enjoyed using xterm since before I even knew that I was using xterm (through Visual Studio Code)! I use xterm practically every day, and I could not pass up on an opportunity to meet both of my Hacktoberfest goals by progressive challenging myself by working on a real bug (not a feature request) on this sizable, “close-to-home” project! The issue I ultimately chose to tackle is one that appears to have been haunting the repo for over a year:
Issues upon issues
Unlike the other three issues that I tackled this Hacktoberfest, there was no mistaking this issue for an easy one off the bat. It became quickly clear that this was a bug that resulted from the complex interactions of a multitude of xterm’s search and selection-related components. In the issue thread, I posted that I would attempt to (at least) improve the selection of strings that include diacritical marks (e.g. “ééé”), and I can happily say that I managed to do just that (plus a little bit more)!
What I was not able to do, however, was resolve the entire issue. I have come to terms with the fact that some issues are simply best solved collaboratively; shared among multiple contributors. This is one such issue, and I made an effort to ensure that my work on this issue could be easily taken over another contributors.
A grander environment
Fortunately, from my work on RestfulHttpProxy, I learned how to run projects from Docker containers (in my case, from within a Linux virtual machine). Contributing to xterm requires running its demo—which I was able to do using Docker!
This was my first time working with such a large code base. Although large, xterm’s code base is quite well-organized, and I had surprisingly little difficulty navigating its structure. However, I was quickly overwhelmed by the sheer amount of interfaces, base classes, and helper functions spread across the project and written for the purposes of searching, selecting, buffering, etc. (and each of which could be contributing to the issue at hand).
I made heavy use of browser-based debugging tools, and I learned quite a few things about them. (For example, I learned that browser breakpoints do not fire from within TypeScript accessors—and I learned to work around this by placing
debugger statements within them, instead. I also learned that I really would like data breakpoints for debugging web applications.)
When I realized that a helper function my work could use was inaccessible from the search addon’s working directory, I was wary about going against the established structural conventions by duplicating code within the addon. After conferring with the issue’s author, I have accepted the task of posting an issue on this matter (to discuss how to include helper functions within addons).
Naturally, after I submitted my pull request, I was present with a number of failed unit testing. I hope to pass these tests and give my PR a fair shot of being accepted!
My open source journey continues, with some longer-term work beginning on two very close-to-home open source projects! Stay tuned! 🔭