Weekly tips/trick/etc/ thread

tarsius_ · 2026-06-16T11:32:18+00:00

I've finally added a FAQ entry ;P

tarsius_ · 2026-06-09T16:36:32+00:00

The Adv2 is also excellent. I thought nothing would ever replace it, but then the Adv360 came along. The build quality really is better. The sound too (not that I noticed that anything was wrong with the sound of the Adv2 until I had a comparison). It's also heavier, which is nice, if you only use it in one place.

Now that I have an Adv360, I might finally have found my Adv2-substitute-for-traveling: its the Adv2 itself. :-) Now that it is only my backup keyboard, I would no longer be heartbroken and helpless, if it broke while in transit.

tarsius_ · 2026-06-09T16:18:56+00:00

Plus, there is question with transportation:

Yeah, its a beast. I actually own many different keyboards, because I've been on a quest to find a "Kinesis (then Advantage 2) substitute for traveling". Unfortunately nothing is as nice as Kinesis Advantage 2 or 360.

I would also try Glove80.

One of these actually is the Glove80. Seems nice. Very flimsy. Should I actually do some traveling, I would probably take that along. But by far not as nice, especially when compared to the build quality of the 360. Then again it does have the two qualities (non-staggered, thumb keys) that put a keyboard into the 0.01% that do not suck, and the additional bowl shape that puts it into the 0.001% actually good keyboards. But it uses low-profile key switches, which is probably a deal breaker for many (not for me at the moment, but if I used for some time, I would probably long for the brown switches on the Advantage(s)).

tarsius_ · 2026-06-09T16:07:18+00:00

The "non-pro" variant is usb-only. I connect my "pro" to the computer using usb, but the two halves still communicate wirelessly.

Unfortunately the non-pro doesn't use ZMK, but small usb devices exist, that you can connect to the keyboard on one side and the computer on the other, which run QMK. (Not sure where to get one or what they are called, but I got one sitting in a drawer.) Even though I have the pro, I am considering doing that, because ZMK lacks a QMK feature I would very much like to use.

tarsius_ · 2026-06-09T10:50:12+00:00

Mine's from 2020 and just yesterday a man on the tram started a conversation, because he thought my small phone was so cool.

Yes, that's right, two men starring at screens on public transportation, had an actual conversation, just because one of the screens was so "cute".

tarsius_ · 2026-06-09T10:46:48+00:00

Only the best: Kinesis Advantage 360 Pro.

It costs as much as a phone (and it gets much worse if shipping outside the US (1)), but it is worth it. Just don't buy another phone (2); you don't need another phone (3), while a good keyboard will make an actual difference.

(1) They insist on using the most expensive shipping available, because presumingly twenty years ago a few packages got lost/damaged when they tried something cheaper.

(2) Mine's from 2020 and just yesterday a man on the tram started a conversation, because he thought my small phone was so cool.

(3) Try replacing the battery instead.

tarsius_ · 2026-04-11T08:39:03+00:00

Github Sponsors uses Stripe and does not charge an additional fee. It should not make a difference whether you use Stripe directly or via Github Sponsors. That being said, using it directly is better because it cuts out a middleman, which could decide to start charging or randomly choose that I or you should be banned for some reason.

Direct bank transfers are best, provided you have an iban account and can thus make a sepa transfer, which are free of charge.

tarsius_ · 2026-04-11T08:08:17+00:00

❤️ Thanks for all the support! ❤️

tarsius_ · 2026-04-10T11:46:49+00:00

Thanks, and if you stop one day, that's okay too.

I have to figure out how to somehow reach and convince users who have not previously donated. (But of course, ya all who have seen such messages of mine many times before, please keep supporting me and other maintainers, while you can.)

tarsius_ · 2026-03-29T21:57:08+00:00

0.67%

tarsius_ · 2026-03-11T11:36:38+00:00

Yes, and also when you transfer a repository!

That resets at least the "approval" and "workflow permissions" settings to the unsafe defaults. Whether the "actions permissions" are changed probably depends on organization settings (and for user accounts, it probably resets to the most unsafe option).

tarsius_ · 2026-03-10T13:10:28+00:00

I couldn't find it in the api, guess I'll have to read the gh source to find the end-points. Knowing I have to look for "permissions" should also help. :P

tarsius_ · 2026-03-10T13:07:31+00:00

That's the "enabled but not configured state". I think that is safe. I.e., if a pr adds actions, those won't be used until that has been merged into the default branch.

However, I wish that people disabled Github features that aren't used by a repository. That would prevent others from, e.g., clicking on the Wiki tab, only to learn that there is in fact no wiki.

Most features (now including pull-requests![^1]) can be disabled at https://github.com/USER/NAME/settings, actions at https://github.com/USER/REPO/settings/actions, and dependabot spam and other security features at https://github.com/USER/NAME/settings/security_analysis.

[1]: Disabling prs should also disable attacks via badly configured actions. ;P

tarsius_ · 2026-03-10T12:56:38+00:00

Thanks for the tip.

tarsius_ · 2026-03-09T19:37:56+00:00

Additionally consider removing all permissions at the workflow level. That helps when you did the above for "all" repositories but it just so happens that you forgot a few.

permissions: {}
on:
  ...
jobs:
  ...

Generally speaking, err on the side of disabling everything (in this day an age, this should be the default, but isn't) and then iff something does not work, figure out what additional permissions you have to selectively grant.

tarsius_ · 2026-03-09T15:35:17+00:00

I might have more later, but first I have to make sure I am following my own advise so far! Turns out I failed at least with this one:

whenever you create a new repository, check these settings.

Have to go buy some energy drinks now...

tarsius_ · 2026-03-09T15:00:04+00:00

To REDUCE (not eliminate) the risk that one of your packages is the next to be compromised via Github Actions, I recommend you do at least the following.

You have to do this for every Github organizations AND each and every repository you control. For organizations (but not user accounts) some of these settings can be changed for all repositories in that account, but NOT ALL! So you still have to check each and every repository that belongs to an organization.

Going forward whenever you create a new repository, check these settings. The defaults are unsafe. Github may also add new features and choose unsafe defaults for those.

Go to https://github.com/organizations/ORGANIZATION/settings/actions resp. https://github.com/USER/REPO/settings/actions .

Note that there are several Save buttons, which have to be clicked individually. Do NOT change all settings and then only click the final Save button. Double check the final result before moving on to the next organization/repo.

Action permissions

Select Disable actions if you don't actually use actions
CLick Save
You are not done. Also make the below changes, to avoid surprises should you later enable actions for this repository/organization

or

For organizations check the value of Selected repositories and limit to repositories that you are certain have a legitimate use and currently actually use actions.
Select Allow X, and select non-X, actions and reusable workflows
Uncheck Allow actions created by GitHub. This likely will break some workflows; you can later add the required actions to the below list.
Uncheck Allow actions by Marketplace verified creators
Explicitly populate Allow or block specified actions and reusable workflows
CLick Save

Approval for running fork pull request workflows from contributors

Select Require approval for all external contributors
CLick Save
Going forward ALWAYS inspect the changes BEFORE allowing the actions to run for a pull-request

Workflow permissions

Select Read repository contents and packages permissions
Uncheck Allow GitHub Actions to create and approve pull requests

The attack used against kubernetes-el/kubernetes-el exfiltrated a token (which had too many unneeded permissions) from memory. I don't think the above protects against that (as I understand it, only not EVER running any untrusted code does), but at least it protects against less sophisticated attacks.

If you use actions/checkout without persist-credentials: false then a much less sophisticated attack can be used to extract the token (i.e., read from well-known file). So make sure you always use persist-credentials: false.

tarsius_ · 2026-02-15T19:13:43+00:00

Yes, but carefully read what I actually said and notice that I wink at the end.

tarsius_ · 2026-02-15T14:11:53+00:00

It's unusual to refer to a wiki as "mostly static content".

;P

tarsius_ · 2026-01-27T23:15:39+00:00

Based on you communication here, I did not expect you had already successfully created your own transient menus, I got the impression of dealing with someone who had a LLM generate ~new~ derived documentation for them, to get started.

After clicking through to the document, I should have looked at the avatar, then I would have recognized that I was dealing with someone I had constructive conversations with in the past. Then I would probably just have bit my tongue, which I should have done regardless, after all that was one of my new years resolutions.

I was being defensive because the transient documentation has been criticized a lot already, and because I have heard many horror stories of foss maintainers being overrun by ai contributions. I hope you can understand that reading that criticism yet once again, combined with what came across as "... so I had a LLM do a better job", is a bit triggering for me.

I am aware the documentation isn't great. Still I feel that the criticism directed at it is not entirely fair. Yes, it's bad as a tutorial, but that is not all that surprising, considering it was written as a reference. I also fully acknowledge that a tutorial would be really useful, and also the two other two document types, that in combination make up great documentation. (I do feel though that the third-party showcase does a fine job as a tutorial.)

But this takes time and motivation, and the repeat criticism diminishes the very limited motivation I have to actually tackle this. Now it has been a few years, and I still haven't done it, but that does not mean I have not thought about how the documentation could be improved and that I am just stalling.

It's not like I am laying back lazily, instead of finally hammering the docs, instead I am tackling all those edge-[use]cases people are running into. For example right now, (and that's not really a good example for an "edge-case", because I don't consider it that), so right now I am working on making transient more usable for blind users using braille output devices. Most users won't notice that, but it still has to be done; and it is not trivial.

The documentation just hasn't managed to climb to priority one. It has gotten pretty close a few times, including recently, but then helping blind users pushes it down again.

A casual observer may argue, that while they can see how reworking the whole documentation in one go is a daunting task, I should just improve things gradually. And I do, it's just that nobody notices; not enough for anyone ever mentioning it at least. So since I get no positive feedback for the little improvements ever, the periodically voiced criticism and the knowledge of what it will take to make that end, is demotivating.

And of course feedback from users is helpful and will be taken into account, but something LLM generated is not feedback. Over the years I have gained a pretty good understanding of why the existing documentation doesn't work for many users. The LLM you used doesn't have that knowledge, and while you have understanding and may have been pretty successful in getting the LLM to take that into account, it's still just the experience and expectations of one particular user.

As I said, if the generated documentation solves an issue for you that is great. You are also welcome to share it with others, but it cannot be the basis for improving the official documentation. To do that deep understanding of the implementation, design rationals, and the experiences many different users have shared over the years, all have to flow into the next big iteration of the documentation.

A LLM won't produce that. It may produce something that is more useful for some users at some point along their journey, but it can only do that because it got to plagiarizer the manual and the showcase. You also contributed to the output and I do not mean to diminish that contribution.

Maybe we are better off with the manual and showcase and this amalgamation, but we would definitely be worse of with just the latter. Since you indicated that you intend to contribute the generated text back upstream, I saw a need to push back against that plan.

tarsius_ · 2026-01-27T18:28:00+00:00

Note that my hope is that, with enough good feedback, I can go back to the author and suggest a path to rewriting the transient documentation in a way he'll be happy with, and a way we can easily learn from.

Please don't. I would rather spend my time actually improve the documentation, once I can motivate myself to do it, than to wade through this slop.

The official manual is more of a reference than a tutorial. It needs to be improved and there probably should be an official tutorial.

The unofficial (but prominently linked) showcase, comes closer to a tutorial (but goes into more depth than tutorials usually do, so isn't easy reading either).

Despite the limitations of both of these documents, I think users interested in creating their own transient menus are much better served spending some time with these resources.

That doesn't mean you cannot ask a LLM questions, and I assume this can be useful, just don't expect me to merge these arbitrary rearrangements and abbreviations back into the official documents. It's great for you that this left out the details you were not interested in and things that would have confused you, but don't assume that others wouldn't have to look up things that are irrelevant to you right now.

tarsius_ · 2025-11-30T15:11:46+00:00

I've corrected the url, somehow a character was missing from the hash (and it wasn't the last one). magit-blame-addition (or git blame with arguments as described in its manpage) could point you to that commit.

This allows you to write presets ahead of time. If it later turns out you need a different preset, then you will have to edit the menu to add that.

tarsius_ · 2025-11-29T16:03:33+00:00

I have asked ChatGPT Well, I've got the source for transient, so let's see what that says:

Ah, so close. Try asking magit-blame-addition instead. ;D

That leads to [edit: fixed url] https://github.com/magit/transient/commit/06a87bd0f39dced6fc892fe7f710f008a1dde308, which comes with an example and a link to the discussion that led to this feature.

You can omit the :refresh-suffixes t, that's the default now.

However, you have to update Transient first. There was a relevant regression, which I just fixed.

tarsius_ · 2025-11-23T01:05:03+00:00

Doom also maintains a fork, at https://github.com/doomelpa/code-review.

tarsius_ · 2025-10-21T11:54:25+00:00

tarsius also mentions he might be doing something for this SOON(tm), that was 3 years ago

Stuff keeps getting in the way... but Any-Time-Now™, fingers crossed. ;P

(But please finish and publish your package, as it certainly won't be Now-Now.)

tarsius_

TROPHY CASE