I've added the following myself:
* mattermost
* purple-signald (waiting for https://github.com/NixOS/nixpkgs/issues/188384)
* purple-events
* purple-libnotify
and added slack from nixpkgs.
I'm also trying to make signal integration work.
Not sure whether I'll keep pidgin, as I expect video calls from within
slack not to work.
But would be cool to have a single open source messenger instead of x
instances of chromium as wrapper around closed source web applications.
The loading order (runtimepath) was changed with
cda1f8ae46.
The php syntax loaded as package is now loaded after the neovim native
php syntax file and does not have any effect.
I now remove the package and add the file as XDG config so it is always
loaded first.
This file is not maintained anymore since some years and I still prefer
it over the maintained versions.
Use logFileInfix instead of logFile.
As path changes between TYPO3 versions and logs are no longer stored
within typo3temp.
Instead we distinguish the custom log by file infix.
The composer configuration should also be maintained via home-manager.
The files are added to this repo and added via xdg.
The auth.json is crypted of course as it contains my personal tokens.
The module doesn't work or exist anymore.
I use a lightwight battery icon instead which I add as a service to
start during login.
And I don't need the wifi thingy.
This was missing after migrating to i3 via nix.
i3blocks was installed via apt before.
home-manager doesn't provide options, I keep my old file. It is updated
for the used version.
Install and configure i3 via nix home-manager.
This commit just migrates existing configuration.
It doesn't clean things up, e.g. move stuff to expected locations.
I configure x* tools from within i3 right now …
Also didn't clean things up, e.g. sort and group related things.
Remove flakes for now.
I will use shells for now to not have a mixed setup.
Add composer v1 for a single customer project as overlay due to usage in
shell instead of flakes.
Adjust folder to not have unnecessary deep structure.
Add shell for reuter monorepo using composer v1.
Those were the last piece in my old .dotfiles repository.
The whole configuration is now defined here.
Only customer specifics are in a separate location / repo to not expose
any sensible data.
Change i3 config to match current hardware setup.
Add custom dmenu script to start and stop recording.
Move internal dmenu scripts into local variables.
There is an existing module.
Existing manually written and linked files are replaced with usage of
the module.
This has the advantage that I don't need to know where to place the
files and which format to use.
Furthermore, the module will check whether I've typos in options and
whether values match expected types.
Place ctags configuration in expected location.
It wasn't loaded due to wrong location.
Do not add typescript as I'm not using typescript anymore on a
professional level.
Create dedicated xdg desktopEntries to start web apps.
Use chromium where necessary, e.g. due to audio / video experiences.
Start web apps with dedicated Firefox profiles.
Configure those profiles to hide any UI to have an actual app feeling.
I created a private repository within `registries/customer-projects`.
This holds flakes.
The folder is registered as registry.
That allows to run the following from within a customer project:
nix run cp\#reuter-phpstan
In order to execute the customer specific application from flake.
The phps used via flake for local development of legacy projects
distributed pre build packages via cachix.
Install cachix and add configuration to allow fetching of pre compiled
packages.
My host does no longer provide any node or npm or yarn.
Project are partially migrated to shell.nix already.
I still need to migrate all projects. But I'm not working to much on
frontend and don't need to re compile assets to often, so no worries.
Some stuff will not work anymore, e.g. coc within neovim needs nodejs.
That's broken for now, but I don't care to much, not sure whether I used
it at all.
That will be part of neovim migration to home-manager / nix.
As we add more and more files, move to set with curly braces.
Maybe home-files is a better approach, but not documented and I don't
understand it to well yet. I guess I've to create a derivation which
"builds" all the files. Maybe to complicated right now.
Might also make sense to build modules for such tools in future where I
can configure within nix, just like git.nix, and it will generate the
config. Might be cool for some things where configs might change, but
the actual things to configure might not. The generation of the file can
change within nix, while configuration within nix stays the same?! ;)
Daniel Siepmann