I wanted to share a tool I’ve been working on that solves a specific friction point I kept running into.
If you’re like me and spend a lot of time in the terminal, you know the flow disruption of having to reach for the mouse, switch windows, and navigate to Logseq just to make a quick journal entry. Logseq is fantastic for knowledge management and is my main hub for all my notes. But this context switching was slowing down my daily workflow.
So, I created lsq.
A simple command-line tool that lets you create journal entries directly from your terminal. At its most basic, it’s simply:
lsq
This single command opens today’s journal in your preferred editor ($EDITOR). This lets you capture thoughts without leaving your terminal workflow. When using only lsq the program defaults to the standard Logseq directory structure (~/Logseq) and leverages the config.edn file for some configuration requirements.
Once I solved the basic problem, I decided to add a Terminal User Interface (TUI). The goal with the TUI is to add common Logseq capabilities that are not possible when only using $EDITOR. It’s my first time creating a TUI application and it’s quite basic at the moment.
Current TUI Abilities:
Open today’s journal page
Write and save text
TODO and priority cycling through keyboard shortcuts
This is very much a work in progress. It’s functional for daily use (I use it every day), but there’s plenty of room for improvement.
If you’re interested in streamlining your terminal-to-Logseq workflow, you can install it with:
go install github.com/jrswab/lsq@latest
The project is open source and available at github.com/jrswab/lsq. I’d love to hear your thoughts, feedback, and ideas for improvement.
What other terminal-to-Logseq friction points should I tackle next?
This sounds great, but I am not sure why you are not using keyboard shortcuts to open LogSeq.
I use Windows and Mac, and on both, I can be in the journal in 3 keys.
Launchpad, l, enter on mac
Window key, l, enter on Windows.
Alt tab to go back to Terminal.
Thanks for sharing your workflow! Those are definitely efficient shortcuts.
The main advantage of lsq is that it lets you make journal entries directly in the terminal without switching contexts at all.
When you’re deep in a terminal session (maybe SSHed into a server, running tests, or monitoring logs), staying in the terminal can help maintain focus and keep your workflow uninterrupted.
Plus, the TUI mode adds Logseq-specific features like TODO/priority cycling right in your terminal environment. (With more features in the works.)
Different workflows suit different people though - that’s the beauty of having options!
Oh right! I see what you mean.
Sorry, my bad.
I will definitely check out your work when I get a chance.
Staying that long in the terminal sounds like you will be on to Emacs before long!
Right now it’s journal-focused, but that’s just the beginning! LSQ actually defaults to using your $EDITOR (including nvim) for journal entries.
I’m working on expanding it to handle any Logseq page, add search functionality, and let you jump directly into specific pages with nvim. The current journal focus is mainly to get the core editing experience solid before expanding.
Since you’re using nvim, you’ll be able to use all your familiar keybindings and configs with LSQ - it just handles the Logseq-specific bits like file management and naming for you.
Nice work, @jrswab . Seeing you are a Vim/Nvim user, I imagine you probably long for what I long: vim capabibilities inside logseq. Even a simple vim emulation that allowed for jumping around inside a block, and deleteing, copying and pasting things would already be life-changing. (The vim mode extension unfortunately works only in the blocks level, not inside them.)
Lack of vim mode in Logseq is a big drawback of it compared to Obsidian. I often imagine if it is possible to have a vim mode and WYSIWYG just like obsidian, which means you don’t have two page with source and preview but one integration. Obsidian’s vim and WYSIWYG is almost there. I assume Logseq has more difficulty to implement vim mode because of the outline structure.
I think the important piont is it is impossible that you work in the vim mode of Logseq just like use vim in source code editor. The first inconsistence you encounter is that in logseq many don’t use monospace font, which is a problem in vim mode. There is many other function that is not possbile behave the same like ctrl-V multi line select.
So the right way is to simulate vim and implement the vim spirite not the complete vim mode. Obsdian’s vim is on the right way in that for example, it move up and down by the visual position not the columan number.
