Untitled 2026-08-09
Plaindown new post of type shot is failing
Plaindown new post of type shot is failing
Helix has got to have one of the easiest configurations. It is this easy to get the markata-go lsp in helix.
markata-go lsp setup --editor helix
# Helix languages.toml (usually ~/.config/helix/languages.toml)
[language-server.markata-go]
command = "markata-go"
args = ["lsp"]
[[language]]
name = "markdown"
language-servers = ["markata-go"]
I don’t run into windows file endings very often, so when I see little ^M’s
all over your file, I think “shit I know what these are and cant remember”
They represent the windows carriage return.
The difference here is that Unix uses \n and Linux uses \r\n, going all the
way back to the typewriter it represents the two keys that a typist would have
to press to get a new line and return the carriage back to the beginning.
When I open up a file and see this garbage all over, its not cozy, I want them gone, I dont want them all over my editor. I’m not sure what this would look like on windows, I haven’t been able to afford a windows machine in years, but its gross on my machine.
Remove them with a substitution command from normal mode.
:%s/\r//g
removing carriage returns with a substitution command
I ran into an issue where my pinentry was unable to connect, blocking me from
doing commits. You can use this to continue signing commits.
export GPG_TTY=$(tty)
gpg-connect-agent updatestartuptty /bye
printf test | gpg \
--local-user 9A47900E81415D65C32C630066E2BF2B4190EFE4 \
--pinentry-mode loopback \
--sign >/dev/nul
I’ve been running fedora coreos on my home servers for awhile. I really liked
the stability I got from bazzite, and have since enjoyed the stability of
fedora coreos. Since it’s an immutable system I’ve never quite known if I need
to reboot or not, and was unsure how to check for updates. Today I learned you
can use rpm-ostree status to see if your
fedora coreos system is up to date.
rpm-ostree status
For me it listed security advisories with a count of each severity unknown, low, moderate, and important.
This morning I had a machine crash on me and came back to an error.
Error
zsh: corrupt history file /home/u_walkews/.zsh_history
Dammit I don’t want to redo my shell history, I checked with a clanker and they
came up with this solution using strings that only prints printable
characters.
cp ~/.zsh_history ~/.zsh_history.bak
mv ~/.zsh_history ~/.zsh_history.corrupt
touch ~/.zsh_history
chmod 600 ~/.zsh_history
strings ~/.zsh_history.corrupt > ~/.zsh_history
chmod 600 ~/.zsh_history
Just give em the ol one eyed fighting Kirby
This is a vim substitution technique to capture the rest of the line as a capture group.
:'<,'>s/longhorn\(.*\)/longhorn\1-rwx
This one captures pesky optional " and places it back at the end if it found
one.
:'<,'>s/longhorn\("\?\)\(.*\)/longhorn\2-rwx\1
!!! see-also
<a href="/thought-200/" class="wikilink" data-title="The One Eyed Fighting Kirby" data-description="!https://www.youtube.com/watch?v=9_Ekt1PZBzQ&t=351s" data-date="2024-01-26">The One Eyed Fighting Kirby</a>
I’ve been deploying my site old school for most of this year, rsync to a volume mounted to nginx. I ran into an issue today where I updated my site and all of the pages updated first, followed by upload. The issue this created was that the new cache busted css files were not up yet and the site had no styles for a brief period during upload.
I found that delaying updates and delaying deletes until the new content exists first solves this problem pretty well. Theres still possiblility of jank while uploading to a live directory and not doing some sort of hot swap, but I’m good with this low budget option for now.
sync:
rsync -rlt --delete --omit-dir-times \
--info=progress2 \
--delay-updates \
--delete-delay \
./output/ \
server:/mnt/mysite