DEV Community: Meliq Pilosyan

From FZF file preview to a browser for cht.sh to discovering the ideal solution

Meliq Pilosyan — Thu, 12 Dec 2024 20:22:40 +0000

Very few scientific discoveries, if any, ever begin with "Eureka".
It's "that's funny ...".
— Isaac Asimov (possibly (paraphrased by Neil deGrasse Tyson))

A story about the cycle of learning, following a hunch, further exploration and discovery along the way.

After setting up the FZF to my liking: changing the theme, adding the file preview and some aliases, I was happily using it until the next time I looked up information on cht.sh.

Don't get me wrong, the outcome is more satisfying. It was the feeling of realization that a new project was unfolding right then, sparked by curiosity and excitement.

You see, the way the cht.sh API is designed with its :lists of topics and subtopics makes it a perfect candidate for browsing it with FZF.

It did took me a few iterations to finalize the spec, decide on the trade-offs (I had to say no to supporting some of the cht.sh's features for the sake simplicity), but in the end I made myself a useful tool. Well, two, actually. So naturally I'm in a happy user mode again.

Let's start with the browser. It's a Bash script that takes user input matching the path in the cht.sh URL, downloads the file if not found in the cache, saves it for next time, and displays it with bat leveraging its conditional pager.

The fun begins when you run the script without arguments or with one ending with a slash. Now you'll be greeted by FZF with all the predefined topics listed for search and preview, if they have already been downloaded. And if not, Enter on the selected topic downloads it.

The cheat sheet for Ruby searched and previewed in the browser

Bash shortcuts cheat sheet found as a subtopic

It includes several convenient features:

Sorting topics so the most recently downloaded ones appear first.
Reopening FZF with subtopics when selecting/passing a topic that ends with a slash.
Accepting custom queries directly from the FZF prompt.
Building a proper URL by escaping the input.
Printing the full command needed to display a cheat sheet directly, bypassing the need to search through FZF again.
Lastly, allows to delete cached files or remove the entire cache directory.

A fragment of the help message of the cheat sheets browser

Unsurprisingly, I was using the half-baked browser during its development to look up Bash's variable expansion and substitution syntax, and to refresh my memory on find, awk, and sed parameters. In hindsight, the utility has already begun to serve its purpose. What I didn't expect, however, was to find a candidate for another tool I was looking for in the middle of making this one.

The cheat sheet for bashmarks is presented as follows:

# bashmarks
# Save and jump to commonly used directories using 1 character commands.
# More information: <https://github.com/huyng/bashmarks>.

I've tried common directory bookmarking implementations such as zoxide. But they all seem to override the cd command, which interferes with other, more important tools in my workflow. Whereas bashmarks has no automated functionality. It's not even a separate binary. But a set of a few straightforward Bash functions to manually add, delete, print and list directory bookmarks. Exactly what I needed.

I really liked the simplicity of the idea. With my newly acquired Bash skills, it was a no-brainer to copy the file and refine the implementation. I dropped zsh support and optimized it further for Bash. Added Tab completion and an optional second parameter to specify the directory path when creating new bookmarks. Renamed the g command to j and removed p altogether. Printing the path of a specific bookmark is of no use to me.

The help message of the cheat sheets browser

Again, these are just functions that you can update as needed.

Or refer to the README of my confNest, if you'd like to use my version. The README includes installation instructions for both bashmarks and the cheat sheets browser.

As I wrapped this project up, I couldn't help but reflect on the journey — the progression of curiosity, experimentation, and discovery. It began from the decision to finally integrate the FZF into my workflow. I was curious to unlock its full potential, which led to the idea of combining it with cht.sh. In the process, I found more insights and tools, each enabling the next step.

It's funny how side projects are born — often out of questioning the status quo, wondering "what if ...".

The joy of creating your own toolkit

Meliq Pilosyan — Mon, 12 Feb 2024 15:22:23 +0000

Are you a Ruby developer? You use Neovim? Then this article is for you. Although the Neovim component is not a hard requirement.

A while ago (almost two years), tired of switching between Kitty windows and inspired by Tj's excellent tutorial on how easy it can be to add custom features to Neovim, I wrote a teeny tiny plugin to run RSpec tests from within Neovim.

It was so much fun figuring out the weirdness of the Lua language that I just loved it. If I didn't know Ruby, I'd agree to program in Lua for full time. And the Neovim aspect only added satisfaction. I felt how the buffers, text lines and words come to life, gain character and preferences after every API discovery.

Spending years in programming I worked on different kinds of projects, tackled fresh ideas, wrote automation scripts for bizarre use cases, but this project was different. I spent so much time in IDEs that file tabs were just openings, means of entry, nothing that I could relate to. And the source code... I have long ceased to see it as “plain” text. Parameters, variables, methods, conditions and expressions, loops and statements, it's all conceptual, intangible.

Now my script runs underneath that text and the result reflects on top of it, treating lines and words as individual entities. The same kind of text developed in one window does something to a text in another. It was unusual, strange and exciting.

Unsurprisingly, this plugin was even more fun to use.

You hit a couple of keys, and watch the thing to test your test assumptions. Sometimes your fingers are still on the keyboard, you still think if that's enough of a test to validate your application code, when the result comes back. A nice green success message on top right corner of your screen or a little "Failure" label at the end of the line where something requires your attention.

Soon it was hard to tell what I enjoyed most was writing tests or running them. I've made myself a small toy.

I was happily playing with it for months. Then there was a no-ruby-coding period. And when I came back again, that fast feedback loop didn't seem that fast anymore. Even simplest test examples took 2 to 3 seconds to complete. While RSpec reported tests duration of around 0.3 seconds, the actual command didn't fall below 2.5.

RSpec's runtime without Spring

"Files took 1.76 seconds to load". This refers to the loading of the Rails framework and the application code involved.

The application I'm using here includes the Spring gem. Opening the Rails console, for example, uses the application running in the background, which is what Spring does. It is fast. A lot less than 2 seconds, at least. But the bundle exec rspec command that my plugin used has no idea about Spring.

How I didn't notice this back then is a good question. But from the other hand, 2-3 seconds is not that much. I used to run tests during active development that took minutes. Definitely can wait 2 seconds. Or so I thought, until it started to irritate me.

It turns out Spring has no native support for the rspec command. And yet, as is usually the case, there is this gem: spring-commands-rspec.

So I installed it, generated the bin/rspec binstub. Here is the effect.

RSpec's runtime with Spring

Total runtime of 2.8 seconds vs 0.9, almost 3 times faster. Impressive!

Of course, this doesn't mean that Spring will make the whole test suite 3 times faster. The 1-2 seconds difference in loading files disappears within minutes of running the entire test suite. But in the case of running single test examples or individual files over and over during development, it actually can be 2 to 3 times faster.

I updated my plugin to be a wee bit smarter about selecting which command to run RSpec as, and back to happy mode again.

In the end, here are a couple of facts about the spring-commands-rspec gem.
It's minuscule. So small it's hard to call it a gem.

1 class with 4 methods with a total of 5 lines of executable code and 2 more lines integrating with Spring. That's it. That's the whole gem.

But wait. There is more. This code was last updated ten years ago.

Github page of the spring-commands-rspec gem

Isn't that fascinating? When was the last time you loaded a ten year old library and it still worked?

What a great example of the benefits of robust interfaces. Well done Spring!