blesh: add module

[aiotter]

Description

This PR implements @akinomyoga's ble.sh module. cf. https://github.com/akinomyoga/ble.sh/issues/216

~~In order to load ble.sh earlier than other programs like starship, I have to modify home.file module so that you can edit files from other modules.~~ ~~The main implementation of this change resides in modules/lib/file-overlay.nix.~~ ~~With import modules/lib/file-overlay.nix { inherit pkgs config; } you can get a simple function which takes original home.file config and returns modified one.~~

~~I'm not sure whether this is the best practice. Please let me know if you have better ideas.~~

I'll remove them and use mkBefore and mkAfter instead. While rewriting this PR is kept draft.

Checklist

• [x] Change is backwards compatible.

• [x] Code formatted with ./format.

• [x] Code tested through nix-shell --pure tests -A run.all.

• [x] Test cases updated/added. See example.

• [x] Commit messages are formatted like

  {component}: {description}
  
  {long description}
  

  See CONTRIBUTING for more information and recent commit messages for examples.

• If this PR adds a new module

  • [x] Added myself as module maintainer. See example.

  • [x] Added myself and the module files to .github/CODEOWNERS.

[aiotter]

I found lib.mkBefore and lib.mkAfter functions used at tmux module. I checked the source code, however, without documentation it's not easy to understand.

Can I just use it like below? Please let me know if you have good document or tutorials.

{
  programs.bash.bashrcExtra = mkIf cfg.manageBashrc (mkBefore ''
    [[ $- == *i* ]] && source '${config.programs.blesh.package}/share/ble.sh' --noattach
  '');
  programs.bash.initExtra = mkIf cfg.manageBashrc (mkAfter ''
    [[ ''${BLE_VERSION-} ]] && ble-attach
  '');
}

[berbiche]

That is indeed how you use mkBefore and mkAfter. The module system takes care of ordering correctly based on the type defined by the option. Here bashrcExtra is a string (types.lines or types.str) and allows ordering of the declarations.

[aiotter]

Now I have done all the work here. The module will be ready to merge when https://github.com/NixOS/nixpkgs/pull/185866 is merged to nixpkgs.

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the PR

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[DavSanchez]

Hi! https://github.com/NixOS/nixpkgs/pull/185866 has been merged for a while now. Would this be ready for review?

[stale[bot]]

Thank you for your contribution! I marked this pull request as stale due to inactivity. Please read the relevant sections below before commenting.

If you are the original author of the PR

• GitHub sometimes doesn't notify people who commented / reviewed a PR previously when you (force) push commits. If you have addressed the reviews you can officially ask for a review from those who commented to you or anyone else.
• If it is unfinished but you plan to finish it, please mark it as a draft.
• If you don't expect to work on it any time soon, please consider closing it with a short comment encouraging someone else to pick up your work.
• To get things rolling again, rebase the PR against the target branch and address valid comments.

If you are not the original author of the PR

• If you want to pick up the work on this PR, please create a new PR and indicate that it supercedes and closes this PR.

[tannerlegvold]

Bump... @rycee

[D3vil0p3r]

@aiotter @akinomyoga @rycee what about this PR?

PS: @akinomyoga you should fix the link on your blesh repository about home-manager's documentation at the bottom of the page because the link is old and broken.

[akinomyoga]

@aiotter It's been quite a while since the discussion took place, and I'm not a user of Home Manager and unfamiliar with it. So I forgot most of the details of the discussion. Could you take a look at this again?

PS: @akinomyoga you should fix the link on [your blesh repository about home-manager's documentation at the bottom of the page because the link is old and broken.

Ah, thanks for the information. I've fixed it. You could actually edit it by yourself. I'm not restricting the users who can edit the wiki pages.

[aiotter]

My bad, I missed the mention.

I got an advice from @SuperSandro2000 about configuration options: https://github.com/NixOS/nixpkgs/pull/201345#issuecomment-1322576091. As rcfile is just a bash script, maybe we should add no configuration options other than programs.blesh.extraConfig.

I'm planning to remove programs.blesh.options, programs.blesh.faces, and programs.blesh.imports. Does anyone have some thought about it?

Current way of configuration:

  config = {
    programs.blesh = {
      enable = true;
      options = {
        prompt_ps1_transient = "trim:same-dir";
        prompt_ruler = "empty-line";
      };
      faces = { auto_complete = "fg=240"; };
      imports = [ "contrib/bash-preexec" ];
      blercExtra = ''
        function my/complete-load-hook {
          bleopt complete_auto_history=
          bleopt complete_ambiguous=
          bleopt complete_menu_maxlines=10
        };
        blehook/eval-after-load complete my/complete-load-hook
      '';
    };
  };

will be changed to:

  config = {
    programs.blesh = {
      enable = true;
      extraConfig = ''
        bleopt prompt_ps1_transient='trim:same-dir'
        bleopt prompt_ruler='empty-line'
        ble-face auto_complete='fg=240'
        ble-import 'contrib/bash-preexec'
        function my/complete-load-hook {
          bleopt complete_auto_history=
          bleopt complete_ambiguous=
          bleopt complete_menu_maxlines=10
        };
        blehook/eval-after-load complete my/complete-load-hook
      '';
    };
  };

[akinomyoga]

Thank you for your reply. May I ask where the content of extraConfig is supposed to go?

If it's supposed to go into ~/.bashrc, I'd have to say it should instead be put in ~/.blerc or $XDG_CONFIG_HOME/blesh/init.sh. The settings in ~/.bashrc are not fetched on ble-reload and ble-update, so those settings would vanish after ble-update in the session.

If it's supposed to be in ~/.blerc, maybe "extra" sounds strange because there do not seem to be basic parts of the settings.

[aiotter]

@akinomyoga If programs.blesh.rcfile is null(default), the content of the extraConfig will become a text file and then it will be loaded by adding the following line at the very head of ~/.bashrc:

[[ $- == *i* ]] && source /path/to/ble.sh --attach=none --rcfile=/path/to/generated-text-file

And at the very end of the file as well:

[[ ${BLE_VERSION-} ]] && ble-attach

If programs.blesh.rcfile is specified, it must be a type of path or str, and that value will be supplied to --rcfile argument.

---

I agree with you that extraConfig sounds strange with no other configurable values. However it seems common in home-manager modules. Please take a look at programs.bashmount.extraConfig for example. It has no other options than extraConfig. It even generates no config file when the user set nothing there.

I'm not familiar with home-manager very much. There may be a better naming.

[akinomyoga]

Thank you for the explanation!

I agree with you that extraConfig sounds strange with no other configurable values. However it seems common in home-manager modules. Please take a look at programs.bashmount.extraConfig for example.

OK, it indeed seems a convention. Then, let's follow the convention here.

[akinomyoga]

@aiotter Can we have another option to switch how the blesh-related codes are arranged in ~/.bashrc?

I have been recommending people using the combination source ble.sh --attach=none & ble-attach as a more reliable way, but I recently stumbled upon a case where the simple source ble.sh works while source ble.sh --attach=none & ble-attach doesn't work. So I think it would be good to provide an option to switch that.

I'm naively thinking about a config for the attaching strategy such as programs.blesh.attach = "manual" (default) producing the configuration mentioned in https://github.com/nix-community/home-manager/pull/3238#issuecomment-1946005014, while programs.blesh.attach = "prompt" inserting a single line [[ $- == *i* ]] && source /path/to/ble.sh --attach=prompt at the very end of ~/.bashrc.

[aiotter]

@akinomyoga That's indeed possible. I'll implement in that way.

Btw I couldn't find out what is happened when you specify --attach=prompt. Is there a document for this option?

[akinomyoga]

Btw I couldn't find out what is happened when you specify --attach=prompt. Is there a document for this option?

Ah, I think the explanation is only found in the output of source /path/to/ble.sh --help. To begin with, I actually haven't explained the meaning of --prompt=none used in the recommended setup.

[akinomyoga]

P.S. Actually, --attach=prompt is the default strategy, so it can be in principle omitted. However, there is another case where we want to specify it to work around a problem: Some Bash configuration tries to perform source ~/.bashrc inside a function. When we only specify the filename to the source builtin without arguments, positional parameters $1, $2, ... in the context of source are inherited by the sourced file. Then, if source /path/to/ble.sh without arguments is placed in ~/.bashrc, ble.sh ends up unexpectedly receiving the arguments originally specified to the function that sourced ~/.bashrc.

Maybe it is easier to see an example:

$ cat A.sh
# A.sh (.bashrc)
echo "A.sh: $*"
source B.sh
$ cat B.sh
# B.sh (ble.sh)
echo "B.sh: $*"
$ function my_source { echo "my_source: $*"; source "$1"; }
$ my_source A.sh
my_source: A.sh
A.sh: A.sh
B.sh: A.sh

For this reason, to inhibit the unexpected inheritance of the positional parameters, we want to specify at least one parameter as a workaround. Then, I think --attach=prompt would be a good one because it doesn't change behavior and it also makes the selected attach strategy explicit.

[RojJuan]

how's the state of this now?