Why I Built A New Tech Workflow for Logseq
Ever notice how the smallest friction points can disrupt your entire workflow? For me, it was the constant context switching between my terminal and Logseq. There I'd be, deep in a terminal session managing servers or debugging code, when I'd need to make a quick note or journal entry.
Like many developers, my terminal is my primary workspace - Tmux, Neovim, and a carefully curated set of tools that keep me in flow. But every time I needed to capture a thought in Logseq, I had to break that flow.
Don't get me wrong - Logseq is an excellent tool. Its outline format, bi-directional linking, and open-source nature make it perfect for managing knowledge.
But having to constantly hop out of the terminal, launch the app, navigate to today's journal, and then context switch back to my terminal work was driving me nuts. It was a classic case of death by a thousand paper cuts.
The solution seemed obvious in hindsight: why not bring Logseq's journal entries directly into my terminal workflow? Surely someone had already built a simple CLI tool to open today's journal in the terminal.
But after some searching, I found nothing that quite fit this use case. So I did what any developer would do - I built it myself.
The initial solution was surprisingly straightforward. All I needed was a small Go program that could read Logseq's configuration, create today's journal file if it didn't exist, and open it in Neovim.
Here's what made Go the perfect choice: it's fast, compiles to a single binary, and I could write it in a language I use daily.
The core logic was simple: find the Logseq directory, read its config file to respect my preferred format settings, construct today's journal path, and hand it off to Neovim.
You can see the first commits at https://github.com/jrswab/lsq
All in too was a few lines of code to eliminate my daily friction point. Now I could type `lsq` and immediately land in today's journal page in Neovim, right from my terminal. No context switching, no extra windows, no disruption to my workflow.
What surprised me most wasn't the solution itself - it was that nobody had built this before. The Logseq community is full of developers who live in the terminal, yet this simple CLI tool didn't exist. Sometimes the best tools start from scratching your own itch.
But once I had the basic functionality working, I started thinking about other features that could make the experience even better.
While opening journal entries in Neovim solved my immediate need, I found myself wanting to experiment with a different approach. What if I could create a lightweight interface right in the terminal for quick notes, while keeping the option to pop into Neovim for longer writing sessions
Enter Bubble Tea, Go's charming terminal UI framework. I'd never built a TUI before, and the learning curve was steeper than expected. Creating an interactive text editor that felt natural while supporting Logseq's markdown formatting meant diving deep into terminal rendering, key event handling, and state management.
But the effort paid off. Now I had two ways to journal:
Quick entries right in the terminal with `lsq -t`
Full Neovim sessions with just `lsq`
The TUI became more than just a text editor. I added keyboard shortcuts for common Logseq patterns - `Ctrl+T` to cycle through TODO states and `Ctrl+P` for priorities.
These small features made it feel less like a generic terminal editor and more like a purpose-built tool for Logseq journaling.
The best part? Everything still syncs perfectly with Logseq's desktop app. Whether I'm writing through the TUI, Neovim, or the main Logseq interface, my notes are always where they should be, formatted correctly, and ready for linking and organizing.
Looking back, what started as a simple script to avoid context switching has evolved into something more useful than I expected. `lsq` hasn't just improved my personal workflow - it's become a bridge between the terminal-centric development environment I love and the powerful knowledge management features of Logseq.
The project is open source and available on GitHub. While it solves my specific workflow needs, I'm curious to see how other developers might adapt it for their own use cases.
Maybe you're a Vim user who wants to stay in the terminal, or perhaps you're looking to script some Logseq journal automation. Either way, the codebase is simple enough to understand and modify.
Want to try it out? Installation is straightforward:
go install github.com/jrswab/lsq@latest
If you're interested in contributing or have ideas for new features, check out jrswab/lsq on GitHub. Whether it's improving documentation, adding new features, or reporting bugs, all contributions are welcome.
Sometimes the best tools come from solving our own small frustrations. What started as a way to avoid switching windows has become a daily part of my workflow, and maybe it can help improve yours too.