Herdr supports mobile-friendly layouts seamlessly, just like responsive web pages. On a narrow terminal, the sidebar is automatically hidden, and the tab bar is replaced with a status line (current workspace name, current tab name, and agent statuses). Everything else is tucked into the hamburger menu.
You can use a shell script (stored in the same git repo). You need you run an external tool with dotfile managers anyway, a shell script gives you more flexibility and doesn't need an extra dependency which might break at an inopportune time. The last thing you need is your dotfile manager breaking when you're setting up a new machine (ask me how I know)
You can, but forks or branches need constant merging or rebasing (and sometimes conflict resolution) for each one. Clean/smudge filters are fiddly to set up correctly and almost certainly require shelling out to another program, which could break. The second-to-last thing you need is your hand-rolled solution breaking on a new environment. If and when you need several advanced features that a stable dotfiles manager already covers, why roll your own?
I'm multi-platform and use git. A few scripts include things like this, but for the most part are portable.
# fish
if set -q TERM_PROGRAM # mac os
...
else if test "$COLORTERM" = "kmscon"
...
else # tron leotards
...
end
# bash
if test "$WAYLAND_DISPLAY" == ""; then
echo X11
else
echo Found Wayland
fi
if test -e /etc/fedora-release; then
echo ...
else
# Debian
fi
Don't want to discourage or anything but is this mostly pattern matching? Most of the comments here seem to be about corner cases "added to the model", which doesn't feel that novel. Naturally, context-aware is all about the corner cases.
今日asこんにちはbeing denylisted was the biggest point of concern here.
That’s a fair concern. It’s a hybrid system, so dictionaries and rules handle the high-confidence cases, and the context model handles selected ambiguous words.
今日 is extremely common, but in the vast majority of ordinary text it’s read きょう. The こんにち reading is much less common and tends to appear in more formal contexts, so I handled it conservatively.
I do plan to unblock more cases like this once I find a way to speed up the context model.
Even with that workflow jj can help a lot. Haven't you ever been annoyed by situations like, while working on a few features at once, having unrelated changes from different feature branches piling up in the stash? Or wanting to switch to another branch mid-rebase without losing your place? jj's working-copy-as-commit model and its first-class treatment of conflicts address those pain points.
No? You work on something and finish it. At most I have 2-3 feature branches open. If none are in review, I have commits in them with current work. Maybe I use the stash 2-3 times a year when I am heavily experimenting with different implementations.
That number is unfairly exaggerated. The list includes ~40 internal keywords used only by language developers, plus dozens of tokens that would be called preprocessor directives, attributes, or annotations in other languages (e.g. `canImport` as in `#if canImport(...) #endif`; `available` and `deprecated` as in `@available(*, deprecated) func`).
Git can display diff between binary files using custom diff drivers:
> Put the following line in your .gitattributes file: *.docx diff=word
> This tells Git that any file that matches this pattern (.docx) should use the “word” filter when you try to view a diff that contains changes. What is the “word” filter? You have to set it up [in .gitconfig].
In their 'Git is unsuited for applications' blog post[0] they also say the following:
> We currently have to clone the whole repository just to edit translation files. That is problematic for big repositories. The repository for posthog.com for example is ~680MB in size. Even though we only need translation files which would be at max 1MB in size, we have to clone the whole repository. That is also one of the reasons why git is not used at Facebook, Google & Co which have repository sizes in the gigabytes.
I get that it can be a bit complex, but Git can handle this circumstance pretty easily if you know how (or write a script for it).
For example, cloning the GIMP repo from GitLab takes me about 56 seconds and uses up 632 MB on disk, using just `git clone <repo>`.
(You can also run `git sparse-checkout init --no-cone` and then just `git sparse-checkout add *.po` to grab every .po file in the repo and nothing else)
Takes 14 seconds on my laptop and uses 59 MB of disk space, and checks out only the specified directories and their contents.
So yeah, it's not as automatic as one might like but ship a shell script to your translators and you're good to go. The 'Git can't do X' arguments are mostly untrue; it should really be 'Getting git to do X is more complicated than I would prefer' or 'Explaining how to do X is git is a pain', both of which are legitimate complaints.
I had some interesting luck with the generic approach to unzip the DOCX/XLSX/ODT/etc, then to the contents recursively apply other filters like XML and JSON formatters/prettifiers.
(My work [1] in this space predated git so it wasn't written as a git diff filter, instead it automated source control. But the same principles could be used in the other direction.)
Not the highest level diffs you could possibly get, but at least for a programmer even ugly XML and JSON diffs were still nice to have over binary diffs.
This is great for showing diffs. To actually make git store only deltas, not entire binaries, you would need to configure "clean" and "smudge" filters for the format.
Given that docx (and xlsx) are a bunch of XML files compressed by zip, you can actually have clean diffs, and small commits.
Yeah, this is how I would prefer to solve this problem personally, but it would be really nice to have some collection of tools that cover common binary file formats automatically instead of having to configure this manually every time.
This is really great. I read the Git config article, but I thought the image diff example was kinda lackluster. Im sure some better metrics could be extracted for a more descriptive diff.
I'm not deeply familiar with this, but from reading the `go mod tidy` manual[1], it seems that running `go mod tidy` loads all packages imported from the main module (including transitive dependencies) and records them with their precise versions back to `go.mod`, which should prevent them from being substituted with later versions. Am I understanding this correctly?
go.mod will always match whatever versions are being used directly, as far as I know. But it's not possible to lock them using go.mod. Like if you wanted to bump one version only in go.mod, you're then stumped for actually doing that. Because _probably_ the only reasonable way to get that to build is to do `go mod tidy` after doing that, which will modify go.mod itself. And you can't _really_ go back in and undo it unless you just manually do all of go.mod and go.sum yourself.
Running `go mod tidy` months apart with no other changes to your module will not change your go.mod. It certainly won't update dependencies.
You run that when you've made manual changes (to go.mod or to your Go code), or when you want to slim down your go.sum to the bare minimum needed for the current go.mod.
And that's one common way to update a dependency: you can edit your go.mod manually. But there are also commands to update dependencies one by one.
go always requires a dependency graph that is consistent with all the declared requirements.
Which means if you wanted to update one version, it might bump up the requirements on its dependencies, and that's all the changes you see from running go mod tidy afterwards.
Manually constructing an inconsistent dependency graph will not work.
