Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WIP: adding plugins as modules #9

Draft
wants to merge 35 commits into
base: main
Choose a base branch
from
Draft

WIP: adding plugins as modules #9

wants to merge 35 commits into from

Conversation

haennes
Copy link
Contributor

@haennes haennes commented Dec 16, 2024

So this is just an idea i had lying around for quite some time.

Motivation

Just add plugins as easy as with nixvim:

  programs.yazi.yaziPlugins = {
    enable = true;
    plugins = {
      bypass.enable = true;
      bypass.package = pkgs.custom-bypass;
      chmod.enable = true;
      chmod.package = null; # do not add chmod to programs.yazi.plugins
      full-border.enable = true;
      hide-preview.enable = true;
      starship.enable = true;
       jump-to-char = {
        enable = true;
        keys.toggle.on = [ "F" ];
      };
      max-preview.enable = true;
      smart-filter.enable = true;
      relative-motions.enable = true;
    };
  };

General Notes:

  • i renamed default.nix -> package.nix
    • it still gets converted to a package using callPackage. (files can just be renamed)
    • $ rename default.nix package.nix */*

exmple config (bypass.nix):

{
  options = { cfg, mkKeyOption, ... }:
    { lib, ... }: {
      keys = { # actually programs.yazi.yaziPlugins.bypass.keys =
        left = mkKeyOption {
          on = [ "l" ];
          run = "plugin bypass --args=smart_enter";
          desc =
            "Open a file, or recursively enter child directory, skipping children with only a single subdirectory";
        };
        right = mkKeyOption {
          on = [ "h" ];
          run = "plugin bypass --args=reverse";
          desc =
            "Recursively enter parent directory, skipping parents with only a single subdirectory";
        };
      };
    };
  config = { cfg, setKeys, ... }:
    { config, lib, ... }: # no need to check if enabled as it is already done for us
    { } // (setKeys cfg.keys);
}

Quality of life improvements:

  • The first argument (attrset) of both the config and option function:
    • cfg = config.programs.yazi.yaziPlugins.PLUGINNAME
    • all other following attrs are the ones defined in ./lib.nix
  • the options enable, and package are automatically declared for each plugin and given sensible defaults
  • a plugin can have runtimeDependencies (fg needs some for example)
  • config is only called if it is enabled
  • all options are automatically mapped to a child of config.programs.yazi.yaziPlugins.PLUGINNAME
  • lib:
    • setKeys: easily add keys (given as second argument) to programs.yazi.keymap.manager.prepend_keymap
    • mkKeyOption: generates simple nested options for keys (see above)

Some Notes regarding the things to fix:

  • the remaining x86_64-linux reference for packages:
    • could be moved into the output builder in expense for having to use homeManagerModules.x86_64-linux to import
    • fix it in any other way (using the pkgs.system from the import yields a infinite recursion error (at least in the way i did it))
  • more cleanly seperate which lib is being used
  • flake.nix is quite crammed and unorganized. (open for suggestions on renaiming and introducing new intermediary variables)

@Mcrtin
Copy link

Mcrtin commented Dec 16, 2024

how about an option for adding/not adding required packages for the plugin

@haennes
Copy link
Contributor Author

haennes commented Dec 16, 2024

how about an option for adding/not adding required packages for the plugin

This is a good idea! I would leave it enabled by default, but giving the option to opt of this is actually quite important
For each one individually, for all at once or for all at one with the individual one overwriting it?

@Mcrtin
Copy link

Mcrtin commented Dec 16, 2024

for each one individually should be fine; disabling that behavior should only be an edge case; most plugins don't work without their packages after all

@haennes
Copy link
Contributor Author

haennes commented Dec 16, 2024

for each one individually should be fine; disabling that behavior should only be an edge case; most plugins don't work without their packages after all

ok, easiser done than said 😂 just setting the package to null removes it

@haennes haennes mentioned this pull request Dec 24, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants