Forem: KabosuTravel

EqPad: A Calculator-Style Equation Editor for LaTeX, Markdown, and PNG

KabosuTravel — Sat, 07 Feb 2026 14:29:05 +0000

What I Built

I built EqPad, a minimal equation editor for people who don’t want to “learn LaTeX first, write math later.”

The idea is simple: most of the time, I’m not trying to typeset a paper—I’m trying to quickly assemble a correct expression and paste it into wherever I’m working (Markdown, a doc, a worksheet, a chat, etc.). So EqPad focuses on a calculator-like workflow:

Button-first input for common structures (fractions, powers, roots, brackets, matrices)
Fast navigation with Tab to jump between placeholders (so you can fill the “holes” in order)
Practical exports only: LaTeX, expanded LaTeX, block/inline Markdown, and PNG
A lightweight “template” area for common high school / university patterns (derivatives, sequences, probability, trig identities, etc.)

No accounts. No documents. No “math notes app.” Just an equation builder that stays out of your way.

Demo

Live app: https://eqpad.kttin.net
Repo: https://github.com/kotatsu-dog/EqPad

https://eqpad.kttin.net

Quick walkthrough:

Click a structure button like fraction / power / root.
Use Tab to jump to the next input slot and type.
In Output, click what you need: LaTeX / LaTeX (expanded) / Markdown / Inline / PNG.

Screenshots:

My Experience with GitHub Copilot CLI

This challenge is explicitly about building with Copilot CLI and showing how it helped along the way. I leaned into that by keeping Copilot open in my terminal as my “build buddy” while I iterated on the UI and export pipeline.

How I used it day-to-day

1) Planning and scoping before I coded
Instead of starting with a blank editor and guessing the shape of the app, I used Copilot CLI’s planning flow to outline the MVP screens, state model, and edge cases. The CLI supports structured planning commands (for example, /plan) which are great when you want a concrete checklist before touching code.

2) Fast iteration without context switching
I stayed inside the terminal: run, inspect, tweak, repeat. Copilot CLI’s interactive mode (copilot) plus the built-in help (/help) made it easy to discover commands and shortcuts as I went.
My typical loop looked like this:

copilot
# /help
# /cwd
# /clear

That “/clear + /cwd” habit sounds small, but it prevents the agent from drifting when you’re jumping between tasks.

3) Safer “agentic” changes with explicit permissions
When Copilot CLI wants to read/modify files or run tools, it asks you to confirm trust boundaries and approve commands. That made me more comfortable letting it do bigger refactors—because it wasn’t a silent black box touching my repo.

4) Repo-specific instructions
I also like the fact that Copilot CLI can initialize repo instructions (copilot init) so the agent consistently follows project rules (naming, folder structure, etc.).

Where it helped most on EqPad

Turning “I want a calculator-like equation editor” into concrete UI primitives (buttons, placeholders, tab order).
Speeding up repetitive implementation work (button packs, template lists, export wiring).
Catching edge cases I would have missed (export sizing, placeholder navigation, keyboard shortcuts).
Keeping momentum: I didn’t have to constantly jump between browser docs, editor, and terminal—Copilot CLI stayed in the same loop as my build/test cycle.

I Built "GitJin" - A Web App to Escape GitHub's Unusable Home Screen

KabosuTravel — Wed, 17 Dec 2025 08:38:20 +0000

Winter days continue to be cold in Japan. With poor circulation, my fingertips get so cold that typing on a keyboard becomes painful.

By the way, everyone, don't you find GitHub's home screen difficult to use?

I use GitHub every day, but honestly, I'm dissatisfied with the UX of the home screen.

The Copilot promotional area is intrusive and makes scrolling annoying
Too many clicks required to reach my own profile
Checking PRs and Issues isn't intuitive

Isn't it strange that a platform for developers isn't user-friendly for developers?

Born from this frustration is GitJin, which I'm introducing today.

✨ What is GitJin? The "Fastest" GitHub Dashboard for Accessing Information

GitJin is a web app that displays repositories, PRs, and Issues in an easy-to-read single screen just by logging in with your GitHub account.
https://gitjin.com/

🎯 Three Problems GitJin Solves

Scattered Information
On GitHub, repositories, PRs, and Issues are on separate pages.
GitJin consolidates them into one screen for speedy access without page transitions!
Slow Display Speed
Initial display is faster than GitHub, with parallel API requests for a comfortable experience!

Privacy Data is fetched from GitHub API on-demand. Only minimal necessary information is stored.

🔧 Tech Stack Overview

For personal projects, being able to "build quickly" is crucial. This time I built around Next.js, which I've been obsessed with recently.

Why I Chose It

Intuitive file-based routing for fast implementation
Robust development with TypeScript
Complete frontend and backend in one framework

For personal development and quickly shaping products, I think Next.js is the only choice.

🔐 Authentication

I used better-auth for user authentication.
Previously I used Auth.JS (formerly NextAuth), but better-auth is more intuitive with simpler implementation. Switching was the right decision.

📚 Other Key Libraries

octokit: Communication with GitHub API
drizzle: Lightweight and comfortable as database ORM
@primer/octicons-react: Using official GitHub icons

💡 Key Features I'm Proud Of

⚡ Improved Perceived Speed with Skeleton Display

GitJin's biggest feature is its fast initial display.
The screen appears faster than GitHub, and skeleton states visualize loading while data is being fetched.

Implementation Points:

Start API requests after initial rendering
Parallel execution of repository, Issue, and PR requests
Sequential display as data arrives, dramatically improving perceived speed

I focused on UI design that doesn't make users feel "loading."

🎨 Calculated Menu Close Tolerance

The floating menu in the bottom right intentionally has a wide tolerance area.

In typical implementations, the menu closes immediately when the mouse leaves the menu area, but GitJin allows a margin so it won't close from slight mouse movements.

It's a small detail, but it contributes to a stress-free user experience.

🔤 Web Font Flickering Prevention

const geistMono = Noto_Sans_JP({
  weight: ["400"],
  subsets: ["latin"],
  variable: "--font-geist-mono",
  display: "swap", // 👈 Display text even while loading
});

I'm using Noto Sans JP, but by specifying display: "swap", text displays with a fallback font even while the font is loading.

This prevents flickering on initial display without compromising UX.

(Side note: I didn't notice the class name is geistMono... I'll fix that later 😅)

https://gitjin.com/

🚀 Future Development

GitJin still has plenty of room for improvement:

Enhanced notification features
Customizable dashboard layout
PR/Issue filtering functionality

If you have feedback or suggestions, please let me know!

🎉 Conclusion

"Build what you want" - that's the appeal of personal development.

GitJin is my ideal GitHub home screen.
If you feel the same frustrations, please give it a try!

https://gitjin.com/