The author recreated the "Bad Apple!!" animation within Vim using an incredibly unconventional method: thousands of regular expressions. Instead of manipulating images directly, they constructed 6,500 unique regex searches, each designed to highlight specific character patterns within a specially prepared text file. When run sequentially, these searches effectively "draw" each frame of the animation by selectively highlighting characters that visually approximate the shapes and shading. This process is exceptionally slow and resource-intensive, pushing Vim to its limits, but results in a surprisingly accurate, albeit flickering, rendition of the iconic video entirely within the text editor.
The blog post "Bad Apple but it's 6,500 regexes that I search for in Vim" details a complex and computationally intensive method of recreating the "Bad Apple" animation within the Vim text editor. The author's approach eschews traditional methods of animation or video playback, instead leveraging Vim's regex search functionality as the core mechanism for displaying each frame.
The process begins with a pre-processed version of the Bad Apple video. Each frame of the original animation is converted into a simplified, monochrome representation. These frames are then translated into a series of approximately 6,500 unique regular expressions. Each regex is designed to match a specific pattern of characters within a specially prepared text buffer in Vim. This buffer acts as the canvas, filled with a grid of characters that represent the pixels of the video frame.
The core of the animation engine is a Vim script. This script iterates through the sequence of pre-generated regexes. For each frame, the script executes a search using the corresponding regex. This search highlights the matching characters within the text buffer, effectively "drawing" the frame on the screen by highlighting the appropriate "pixels." The rapid execution of these searches, combined with the carefully crafted regexes, creates the illusion of animation.
To further enhance the visual effect, the author utilizes Vim's highlighting capabilities. Matched characters, representing the black portions of the frame, are highlighted with a dark background, creating contrast against the unhighlighted characters, which represent the white portions. This allows for a clearer visual representation of each frame.
Due to the sheer number of regex searches and the computational overhead involved, the animation playback is significantly slower than real-time. The author acknowledges this performance limitation, attributing it to the inherent complexities of regex processing within Vim. Despite this limitation, the project demonstrates a unique and inventive application of Vim's functionality, showcasing the versatility and, perhaps, the limitations of the text editor. The author also provides insights into their process of converting video frames to regex patterns and optimizing the Vim script for performance.
Summary of Comments ( 51 )
https://news.ycombinator.com/item?id=42674116
Hacker News commenters generally expressed amusement and impressed disbelief at the author's feat of rendering Bad Apple!! in Vim using thousands of regex searches. Several pointed out the inefficiency and absurdity of the method, highlighting the vast difference between text manipulation and video rendering. Some questioned the practical applications, while others praised the creativity and dedication involved. A few commenters delved into the technical aspects, discussing Vim's handling of complex regex operations and the potential performance implications. One commenter jokingly suggested using this technique for machine learning, training a model on regexes to generate animations. Another thread discussed the author's choice of lossy compression for the regex data, debating whether a lossless approach would have been more appropriate for such an unusual project.
The Hacker News post titled "Bad Apple but it's 6,500 regexes that I search for in Vim" (linking to an article describing the process of recreating the Bad Apple!! video using Vim regex searches) sparked a lively discussion with several interesting comments.
Many commenters expressed amazement and amusement at the sheer absurdity and technical ingenuity of the project. One commenter jokingly questioned the sanity of the creator, reflecting the general sentiment of bewildered admiration. Several praised the creativity and dedication required to conceive and execute such a complex and unusual undertaking. The "why?" question was raised multiple times, albeit rhetorically, highlighting the seemingly pointless yet fascinating nature of the project.
Some commenters delved into the technical aspects, discussing the efficiency (or lack thereof) of using regex for this purpose. They pointed out the computational intensity of repeatedly applying thousands of regular expressions and speculated on potential performance optimizations. One commenter suggested alternative approaches that might be less resource-intensive, such as using image manipulation libraries. Another discussed the potential for pre-calculating the matches to improve performance.
A few commenters noted the historical precedent of using unconventional tools for creative endeavors, drawing parallels to other esoteric programming projects and "demoscene" culture. This placed the project within a broader context of exploring the boundaries of technology and artistic expression.
Some users questioned the practical value of the project, while others argued that the value lies in the exploration and learning process itself, regardless of practical applications. The project was described as a fun experiment and a demonstration of technical skill and creativity.
Several commenters expressed interest in the technical details of the implementation, asking about the specific regex patterns used and the mechanics of syncing the searches with the audio. This demonstrated a genuine curiosity about the inner workings of the project.
Overall, the comments reflect a mixture of amusement, admiration, and technical curiosity. They highlight the project's unusual nature, its technical challenges, and its place within the broader context of creative coding and demoscene culture.