Any interest in getting the setup upstreamed[1] so that users only need to `git config --global diff.tool omnidiff` to enable it by default? Disclosure: I created `git difftool` a long time ago, and am always happy when builtin support for useful tools are added to it. Feel free to reach out if you'd like help making that happen.
For example https://crates.io/crates/saphyr-parser/0.3.2/code was recently published (without any client-side errors) but crates.io says: The source code for this version is not available yet. Archives are built shortly after a version is published. This usually only takes a few seconds, so please try again in a couple of minutes. I've never seen this error before. The same can be...
Github might be on the decline, but git != github
Considering all of the effort and hoop-jumping involved in the route that was chosen, perhaps this decision might be worth revisiting.
In hindsight, maintaining a parser might be easier and more maintainable when compared to the current problems that were overcome and the future problems that will arise if/when the systemd libraries decide to change their C API interfaces.
One benefit of a freestanding parser is that it could be made into a reusable library that others can use and help maintain.
> I had to get my project to emit compile_commands.json,
> get clangd, figure out which things about our build
> process clangd was not understanding from
> compile_commands.json and add them in .clangd
I haven't used clangd myself, though, so I can't say either way, I just know ccls works well.
By convention I tend to have the generated build system in build/ at the top-level of the repo so that the file is at build/compile_commands.json. That, or I'll arrange to have a symlink there pointing to one generated elsewhere.
The nvim snippet I use in my init.lua to setup ccls to work in that scenario is:
vim.lsp.config('ccls', {
init_options = {
compilationDatabaseDirectory = 'build',
},
})
vim.lsp.enable('ccls')
ctrl-n and ctrl-p should let you select next and previous from the autocomplete menu while avoiding the arrow keys.
Only a good writer, that truly enjoys their craft, is able to masterfully insert a witty dry pun like that into their work. Bravo!
> Is there anything equally effective for any of you nowadays?
I'm not affiliated in any way. You might be interested in the "Futo Keyboard" and voice input apps - they run completely offline and respect your privacy.
The source code is open and it does a good job at punctuation without you needing to prompt it by saying, "comma," or, "question mark," unlike other voice input apps such as Google's gboard.
git rebase --update-refs
Likewise, a lispier(?) and more compact compromise?:
(define (match:element variable restrictions)
(define (ok? datum)
(every
(lambda (restriction)
(restriction datum))
restrictions))
(define (element-match data dictionary succeed)
(and
(ok? data)
(let ((vcell (match:lookup variable dictionary)))
(if vcell
(and
(equal? (match:value vcell) data)
(succeed dictionary))
(succeed (match:bind variable data dictionary))))))
element-match)The lessons from (Qt3 to Qt4 and) Qt4 to Qt5 have been learned and moving a large project from Qt5 to Qt6 is not that hard comparatively. There are a few minor deprecated APIs to handle and it's relatively easy over all.
I even have a stable project that is compatible with Qt5 and Qt6 [1] all in a single code base (particularly thanks to the effort of the qtpy[2] library). It's not that hard, and my opinion includes C++ in that assessment.
I'm pretty sure there are better ways of handling this edge case, but, hey, it works and was a pretty fun experiment.
It is indeed using fzf in a specialized way so that it only searches for git worktrees and nothing more. The use case I have is that I have dozens or hundreds of repos in various locations on disk and this tool makes it easy to instantly jump into any of them.
That's why it's called "gcd" -- git + cd.