<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Hacker News: leleat</title><link>https://news.ycombinator.com/user?id=leleat</link><description>Hacker News RSS</description><docs>https://hnrss.org/</docs><generator>hnrss v2.1.1</generator><lastBuildDate>Sat, 29 Aug 2026 08:56:04 +0000</lastBuildDate><atom:link href="https://hnrss.org/user?id=leleat" rel="self" type="application/rss+xml"></atom:link><item><title><![CDATA[New comment by leleat in "GUIs should be fully keyboard-driven"]]></title><description><![CDATA[
<p>I don't think this really addresses GP's comment as far as I understood it.<p>Your resource mostly describes how to make keyboard-based workflows accessible. But just because the full functionality of an app is keyboard accessible, doesn't mean that it works as well as the pointer-based approach - especially if you have an app with multiple menus, sidebars, headers, footers etc. Maybe you <i>could</i> tab through everything, but a pointer will be faster. This is where a "keyboard-first UX concept" is missing (from GP).<p>I think an interesting idea to solve this would be a "focus navigation mode". Enter this mode with 1 shortcut and then navigate between items with a few keys; like a combination of mnemonics and screen reader navigation e.g. jump between headers with "h" etc.</p>
]]></description><pubDate>Fri, 28 Aug 2026 18:02:10 +0000</pubDate><link>https://news.ycombinator.com/item?id=49482242</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=49482242</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49482242</guid></item><item><title><![CDATA[New comment by leleat in "2x, not 10x: coding with LLMs in 2026"]]></title><description><![CDATA[
<p>Someone posted their AGENTS.md some time ago, that is used in practice to teach their students[1]. That might be useful to you in this context as well.<p>[1]: <a href="https://news.ycombinator.com/item?id=48359858">https://news.ycombinator.com/item?id=48359858</a></p>
]]></description><pubDate>Thu, 30 Jul 2026 20:31:55 +0000</pubDate><link>https://news.ycombinator.com/item?id=49115362</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=49115362</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=49115362</guid></item><item><title><![CDATA[New comment by leleat in "Deno Desktop"]]></title><description><![CDATA[
<p>> Shared CEF runtime across apps. Every app currently bundles its own CEF copy. A managed shared runtime would drop binary sizes to a few MB per app. On the roadmap.<p>This[0] sounds interesting. I am not familiar with CEF, so I wonder how the versioning works. When different apps require different versions of CEF, do we just essentially end up with the electron model where every app bundles their own browser (just slightly less bad). Or is there still an advantage to a "shared runtime" in that case?<p>[0]: <a href="https://docs.deno.com/runtime/desktop/comparison/" rel="nofollow">https://docs.deno.com/runtime/desktop/comparison/</a></p>
]]></description><pubDate>Mon, 22 Jun 2026 07:39:54 +0000</pubDate><link>https://news.ycombinator.com/item?id=48626999</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=48626999</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48626999</guid></item><item><title><![CDATA[New comment by leleat in ".gitignore Isn't the only way to ignore files in Git"]]></title><description><![CDATA[
<p>There is also<p><pre><code>  git update-index --[no]-skip-worktree
</code></pre>
for files that are already tracked. This can be useful for some local experimentation... it's just a bit annoying to use because it's not really surfaced anywhere by git (kinda). You need to remember that you set it; otherwise other operations like checkouts may be blocked.</p>
]]></description><pubDate>Thu, 18 Jun 2026 22:03:48 +0000</pubDate><link>https://news.ycombinator.com/item?id=48592271</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=48592271</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=48592271</guid></item><item><title><![CDATA[New comment by leleat in "GitHub Stacked PRs"]]></title><description><![CDATA[
<p>If I understood you correctly, you want to propagate changes in a branch to other branches that depend on it? Then --update-refs is for you[1]. That way, you only need to update the "latest" branch.<p>[1] <a href="https://andrewlock.net/working-with-stacked-branches-in-git-is-easier-with-update-refs/" rel="nofollow">https://andrewlock.net/working-with-stacked-branches-in-git-...</a></p>
]]></description><pubDate>Mon, 13 Apr 2026 21:58:35 +0000</pubDate><link>https://news.ycombinator.com/item?id=47758401</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=47758401</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=47758401</guid></item><item><title><![CDATA[New comment by leleat in "Ask HN: What are you working on? (February 2026)"]]></title><description><![CDATA[
<p><a href="https://github.com/Leleat/git-forge" rel="nofollow">https://github.com/Leleat/git-forge</a><p>From the README: "[git-forge is a] simple CLI tool for basic interactions with issues and pull requests across GitHub, GitLab, Gitea, and Forgejo".<p>Right now, I am looking into better testing. Currently, I do testing by mocking the forge APIs and then running git-forge against them with TypeScript. But not everything is testable that way. The TUI is pretty much untested. So I now want to port at least the tests to Rust (I am probably gonna leave the mock API in TS) and need to look into how to tests TUIs, which is a bit of a challenge since not only is Rust my first "systems programming language", I am also not knowledgable in Terminal/TUIs...</p>
]]></description><pubDate>Mon, 09 Feb 2026 09:05:04 +0000</pubDate><link>https://news.ycombinator.com/item?id=46943209</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=46943209</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46943209</guid></item><item><title><![CDATA[New comment by leleat in "Show HN: Vibe coding a bookshelf with Claude Code"]]></title><description><![CDATA[
<p>On the other hand, we had this story[^1], where the maintainer of curl mentions a a bunch of actual useful reports by someone using AI tools.<p>[^1]: <a href="https://news.ycombinator.com/item?id=45449348">https://news.ycombinator.com/item?id=45449348</a></p>
]]></description><pubDate>Mon, 29 Dec 2025 15:53:50 +0000</pubDate><link>https://news.ycombinator.com/item?id=46421881</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=46421881</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=46421881</guid></item><item><title><![CDATA[New comment by leleat in "Ruby core team takes ownership of RubyGems and Bundler"]]></title><description><![CDATA[
<p>Technically, deno supports https imports as well<p><a href="https://docs.deno.com/runtime/fundamentals/modules/#https-imports" rel="nofollow">https://docs.deno.com/runtime/fundamentals/modules/#https-im...</a></p>
]]></description><pubDate>Fri, 17 Oct 2025 14:54:23 +0000</pubDate><link>https://news.ycombinator.com/item?id=45617494</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=45617494</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45617494</guid></item><item><title><![CDATA[New comment by leleat in "KDE is now my favorite desktop"]]></title><description><![CDATA[
<p>The problem is that the extension experience <i>can</i> be really bad. There is no extension API; instead Extensions have (almost) full access to GNOME Shell's code.<p>This makes them incredibly powerful and flexible... but also fragile. Extensions can crash GNOME Shell/mutter. On Wayland that means your entire session goes down with GNOME Shell. Extensions can interfere with each other, and if you are an extension developer, you may need to update (or at least check) your extension every 6 months (GNOMEs release cycle).</p>
]]></description><pubDate>Thu, 18 Sep 2025 14:36:22 +0000</pubDate><link>https://news.ycombinator.com/item?id=45290243</link><dc:creator>leleat</dc:creator><comments>https://news.ycombinator.com/item?id=45290243</comments><guid isPermaLink="false">https://news.ycombinator.com/item?id=45290243</guid></item></channel></rss>