10
points
Leftium
Joined 1,721 karma
email: john@leftium.com
leftium.com
Leftium: The Element of Creativity!
- I'm not sure if !cobalt would meet Kagi's guidelines for public bangs.
Eventually, zBang will execute bangs locally before falling back to a Kagi network call. It's open source: https://github.com/Leftium/zbang
I just remembered my other project can support cobalt. Just enter the youtube URL and press ENTER (or click the buttons): https://mm.leftium.com?p=C4S2BsFMAIF5oEQGED2AjAhuY0AikBbFBAK...
- The link above embeds the cobalt "launch plan" (config) in the URL, but it could also be added as one of the built-in plans like https://mm.leftium.com/svelte.
- Also open source (and very simple to deploy): https://github.com/Leftium/multi-launch
---
But what's the difference between these two?:
1. Go to https://nilch.org and search for `!cobalt YOUTUBE URL`
2. Go to https://cobalt.meowing.de and search for the YOUTUBE URL
I think #2 is actually simpler for that person you are trying to help.
- (replying to dead reply downthread)
Kagi (custom) bangs[1] already supports `!cobalt <youtube video>`
I just added !cobalt to my custom bangs as `https://cobalt.meowing.de#%s`, and it works.
Kagi also accepts new public bangs: https://github.com/kagisearch/bangs#contribution-guidelines
Kagi bangs are free for everyone (a subscription is required for custom bangs and regular search).
- Example of how to use Kagi bangs without subscription: https://kagi.com/search?q=!chatgpt+TEST
- https://zbang.leftium.com/ uses Kagi bangs under the hood.
[1]: https://help.kagi.com/kagi/features/bangs.html#custom-bangs
- Deeply nested comments become nearly unreadable. For example: https://hnplusplus.vercel.app/item/46288491
- comments are pushed all the way to the right side, in a very narrow column
- also must scroll down several screens of just colored stripes
Loading of nested comments could be sped up by using an unofficial API like https://github.com/cheeaun/node-hnapi
- This API sends all the child items of an item at once
- (However due to aggressive caching, many recent children could be missing)
I would add a max-width to the top nav, too. At 2560x1440, the top nav stretches all the way to the corners, making them hard to reach. (Also looks weird with the max-width of the content.)
Some items have over-sized favicons
- It seems to be the job posts, which all lead to 404s
Perhaps some settings to adjust the font. I find the font too small/light.
---
Here are some ideas you may consider taking from my HN frontends (they are both MIT open-source)
- Latest version: https://hn.leftium.com
- Still rendering comments from older version: https://hw.leftium.com
- Based on the HN clients I found most readable: https://hackerwebapp.com (with some ideas from https://hckrnews.com)
Mobile page down: tapping the numbers scrolls that item to the top. I find this more ergonomic than scrolling on mobile.
I reduced items down to two lines to fit more items per screen. I noticed I don't use the poster's id to to decide which items to open so I only show the poster's id on the item page itself.
Items always open comments; the posted URL can be opened from the comments page. (Personally, I always read the comments, and sometimes don't even open the original URL.)
I find highlighting the OP's id useful. I plan to also add toggle highlighting of other specific user ids.
Seeking orange: I highlight items that pass a certain points/comments threshold. First just the icon, then the number, too. Helps more interesting items stand out.
When I re-implement comments, I plan to create a view that focuses on top-level comments and reading a single "thread" at a time.
- So you can choose which conversations to read.
- There will also be a way to expand all the comments for certain users that are more interesting (like the OP).
- The layout/pixel density remains exactly the same (you can also get better scaled resolutions, if desired). (Most) things just look less fuzzy.
It's hard to find good before/after shots. The difference is much more dramatic in real life:
- https://www.reddit.com/r/mac/comments/10oy6xo/i_use_switchre...
- My HN reader supports all those /* urls. (Plus chronological order from HckrNews!)
- My 30-inch 2560x1440 external monitor looked fuzzy/blurry on MacOS until I forced HiDPI. (Mac mini)
MacOS only offers HiDPI for certain resolutions. There is a free OSS program that unlocks HiDPI for other resolutions: https://github.com/waydabber/BetterDisplay
I just tried disabling HiDPI at 2560x1440, and it looks quite bad! With HiDPI, I'd say it looks similar (if not better) than Windows.
- There was a very similar story about a month ago: https://hw.leftium.com/#/item/45766253
Good luck~
- Kagi maintains an update-to-date list of bangs[1]:
- Kagi redirects bang searches even if you are not a member/logged in
- ChatGPT: https://kagi.com/search?q=!chatgpt+test
- Grok: https://kagi.com/search?q=!grok+test
- Copilot (sadly copilot no longer accepts queries from the url params): https://kagi.com/search?q=!copilot+test
- there are internal Kagi bangs for Gemini: https://github.com/search?q=repo%3Akagisearch%2Fbangs+gemini...
- no redirect bang yet for Gemini; you can open an issue and/or pull request
---
- Effectively the same. (If your project's resume.md had your details, would it prevent others from using it as a tool?)
Steps for a user to create their own resume (locally):
1. clone repo
2. update the resume.md file
3. run the server locally `npm run dev --open`
4. print from browser (as PDF)
- My version happens to contain a web server that serves the HTML resume (among other pages).
- You can also preview the results in real-time as you edit the MD file.
---
Compare to steps with your tool:
1. clone repo
2. update the resume.md file.
3. run `make`
(I omitted all the setup steps for the sake of comparing the major steps. I suppose if I added a makefile, the steps would be exactly the same.)
- Interesting, I created two similar projects:
1. markdown resume:
- plain-text version is human-friendly: https://leftium.com/resume?text
- also renders OK on Github: https://github.com/Leftium/leftium.com/blob/main/src/routes/...
- PDF version is produced by printing from browser. (Try Cmd-P)
---
2. invoice generator
- Uses shell scripts instead of make
- Uses weasyprint instead of wkhtmltopdf
---
Some samples would be nice. Curious how the default output settings look.
- There is a way to switch the bars to actual numeric dBM: https://www.techbout.com/display-iphone-signal-strength-in-n...
(Probably a way to do it on Android, too)
A CSR showed me this while debugging network connectivity issues with my phone.
- iOS Safari has a special "QR" menu if you long-tap a QR code.
And this is built in to Android OS: "Search your screen" or "Circle to Search."[1]
- This was the motivating idea for Epicenter Assistant[1] (Prompt your AI coding agent while carrying boxes of pizza home)
- Connect to your opencode sessions via a web interface, connecting via a secure tunnel.
- (Optionally) use a transcription app to prompt the coding agent. (Since typing code is more difficult on a phone.)
I'm not sure if Epicenter Assistant will be developed any further...
Vanilla opencode has a feature for sharing web links to sessions, but these are read-only.[2]
[1]: https://github.com/epicenter-md/epicenter/tree/main/apps/sh
- 2 points
- And now there is a third variation, sanitize.css, which is the one I decided to use: https://github.com/csstools/sanitize.css
Used here: https://github.com/Leftium/news/blob/0d507aecd05dfe94853d278...
- I chose to share the one that seemed more recent/maintained.
Brief history/explanation from: https://github.com/csstools/normalize.css/#differences-from-...
> Nicolas Gallagher and I started writing normalize.css together. I named and created the normalize.css repository with the help of Paul Irish and Ben Alman. I transferred the repository to Nicolas, who turned it into a “household” CSS library.
> Later, I resumed authorship of normalize.css with Luciano Battagliero. Together, we tagged, deprecated, and removed “opinionated” styles — styles developers often prefer but which do not fix bugs or “normalize” browser differences.
> Later, Nicolas resumed authorship and the issue of whether to include or omit the opinionated styles forced us to split.
- 69 points
- Raycast configures the Hyper key as ⌃⌥⇧⌘; if shift key is optionally excluded: ⌥⇧⌘
I like excluding the shift key:
- ctrl-option-cmd is simple to press even without special key mappings
- simple to add shift (esp. with a CapsLock mapped to ctrl-option-cmd)
I also mapped tab to an "Ultra" key: shift-hyper (shift-ctrl-option-cmd)
---
several other references map "meh" to shift-ctrl-option, and "hyper" to shift-ctrl-option-cmd. I find those less logical/ergonomic and prefer matching Raycast's convention.
- 6 points
- 4 points
- I'm curious why you need navigation like this. Is it like selecting text while you read? (I didn't know that was a thing until I read comments about that.)
I find it easier to just read the comments.
I doubt the official HN will ever add this feature, but it seems feasible as a TamperMonkey script or even browser extension.
I will consider including a feature like this when I rewrite https://hw.leftium.com
- I just discovered RayCast's window manager[1].
- The "cycle 1/2, 2/3, and 1/3" feature is amazing.
- As well as optional (CapsLock as) HYPER key[2].
(Still using Magnet for the activation areas)
The one thing Rift offers that I needed was: "Focus follows the mouse with auto raise"
I managed to find it here: https://github.com/sbmpost/AutoRaise
[1]: https://www.raycast.com/core-features/window-management
- I'm developing a web app that makes it easier to view Google sheets (and forms) on mobile. My solution is:
- Expandable rows
- Optional custom row summary
- By default, the row summary is just as much of the row that fits.
- Some data in the row summary is shortened (like a timestamp is reduced to just a date or relative date)
- Sticky header row (with the column titles)
Live demos:
- Custom summary rows: https://veneer.leftium.com/base/g.chwbD7sLmAoLe65Z8/list
- Sticky header rows: https://veneer-nd4fdlulz-leftium.vercel.app/v/s.1mJ_jtZuqL40...
Source code: https://github.com/Leftium/veneer
- It's a matter of trade-offs.
In theory, Handy could be developed by hand-rolling assembly. Maybe even binary machine code.
- It would probably be much faster, smaller and use less memory. But...
- It would probably not be cross-platform (Handy works on Linux, MacOS, and Windows)
- It would probably take years or decades to develop (Handy was developed by a single dev in single digit months for the initial version)
- It would probably be more difficult to maintain. Instead of re-using general purpose libraries and frameworks, it would all be custom code with the single purpose of supporting Handy.
- Also, Handy uses an LLM for transcription. LLM's are known to require a lot of RAM to perform well. So most of the RAM is probably being used by the transcription model. An LLM is basically a large auto-complete, so you need a lot of RAM to store all the mappings to inputs and outputs. So the hand-rolled assembly version could still use a lot of RAM...
- The first half was all manually coded, no AI.
- Claude Opus 4.5 helped add several features I had been planning.
Some features were added on a whim because AI makes experimenting so cheap. Like the UI color gradients reflecting the color of the sky based on time of day.
Just needed to point Claude at https://hw.leftium.com/#/item/44846281. Then we worked together to tweak the palette colors and UX (like smoothly transitioning between colors, tweaking more vibrant sky colors)
Open source: https://github.com/Leftium/weather-sense