Verb Noun or Noun Verb?
When doing one change, other changes quickly follow! I’m not exactly how it started, but for a couple of days now I’ve been using Helix(https://helix-editor.com) as my go-to editor. Helix is a terminal based modal editor written in Rust, and one of the strong points is the out of the box experience: It has support for LSP and tree-sitter enabled, and as long as a language server is installed, ending with LSP support is a breeze.
At first, the term “modal editor” gives the impression that Helix is merely a variation of vi/vim/neovim, but what sets it apart is the way to change text. Modifications and other actions work on the current selections (yes, multiple selections are supported), and there are a number of ways to select text: Select a word, a line, a tree-sitter object, visually by cursor motions, and much more. Once selected, different text modifications are possible, but likewise, it is also possible to modify the selection itself, for example to search within a selection to generate a new, smaller selection.
There is an interesting parallel to Forth, where you push the operands on the stack, and the perform operations on them. What’s not to like :)!
The only downside is that there is at the moment no plugin system, but I found working with the Rust-based Helix code actually quite nice, and it seems not too hard to extend it if needed.
That’s not enough with the changes though. The alternative git
frontend (and possibly evolution)
jj(https://martinvonz.github.io/jj/latest/) popped up, and wanted to
be tried. In my case, being able to work on multiple changes at the
same time in a simpler way than git branches was one of the main
drivers. I’ve been using StGit(https://stacked-git.github.io) for a
while, which is a great a tool to work with sequential changes, but
jj goes one step further and supports more complex commit structures.
It really seems like a graph editor, and I’m curious what kind of
graphical user interfaces will be built on top of it, even though I’m
very likely to stick with the terminal.
Title Cleanup
I just cleaned up a long standing annoyance and removed the redundant titles from the Mottek blog posts. I think the RSS feed should not mark any of the posts as new, but you never know. If all posts pop up as unread, no worries, it’s just a format change :)
SourceHut Mirroring and CI
I’ve been testing the mirroring setup from SourceHut to GitHub, and it seems easy enough to set up. On the GitHub side, fine grained access tokens allow modifications to the mirrored repositories, and on the SourceHut side, the tokens are made available to the build pipelines for each repo to be mirrored.
One interesting feature of SourceHut is the integration of mailing lists, git repos, and the CI system. The SourceHut build system will automatically build patches sent to a mailing list which refer to a git repo in the same SourceHut project. To avoid misuse, the build system is only available to paying users, and patches are built with the author’s permissions, not the permission of the owner of the target repo. If a patch submitter does not have a paid plan, SourceHut will not build the patch. And even more important: Patches are built without access to the receiver’s tokens.
Testing SourceHut
The next chapter of source code management has started. After SourceForge, GitHub and GitLab, I am now trying out SourceHut. The first chapters were pretty self evident, SourceForge was at the time back then the only viable option, but once GitHub came around, it offered improvements specifically in the handling of Git repos, and the networking effects.
Two downsides with GitHub led me to try GitLab (which I also started to use in my day jobs): GitHub Actions are a bit too complex for my taste, and the flat structure makes it difficult to logically group together related repos. GitLab provides a very powerful CI, and the ability to use groups and projects brings a nice structure to one’s work.
After using GitLab for a while though it does seem to be a better fit for corporate usage than for personal projects. It offers a complete and integrated solution for many development related tasks (issue tracking, CI, security scanning, deployments, …), which makes sense in a corporate setting, but my preference is the one tool for one job approach.
SourceHut is in that respect an interesting take on source code management. It does look less integrated than the other offerings, but that is not neccessarily a weakness, since it is explicitly designed that way, it is also easier to integrate with other systems. Two areas stand out for me: The ability to link resource into projects freely, and the elegant build system which makes it very easy to interatively improve the CI setup.
The downside of having less visibility than e.g. GitHub is easily handled by mirroring repositories to GitHub.
Giving it another Go
Continuing the exploration of programming languages for implementing the Newton Docking Protocol, I’ve decided to give Go another go :) The main reasons are the ability to easily target multiple platforms, and the possibility of implementing a desktop application.
Being able to support multiple platforms is important since there are not that many Newton users out there, and the more users can benefit from a new connectivity tool, the better. Similarly, having a desktop application should make it easier for end users to keep their Newtons going.
Another aspect is that Go is maybe a bit more accessible than e.g. OCaml, and more stable than Zig, in case there are people who want to contribute or work with the project.
All of this is of course still a bit theoretical, getting started with Go again has been easy, but completing the job is another issue :)