plugins/dap-rr: init

[GaetanLepage]

Add support for nvim-dap-rr, nvim-dap extension for the record and replay debugger.

Fixes #894

[GaetanLepage]

Should we set up the configurationType so that a string would be automatically converted to lua?

[MattSturgeon]

Initial reaction: I'd assume not, since we want to gradually move away from such implicit conversion?

Saying that, this is a non-freeform option (right?), so we can design it to be more helpful if we wanted.

If we aren't trying to exactly represent an upstream setting and it's unlikely that non-raw string values will ever be valid, then treating strings as lua is fine IMO.

[GaetanLepage]

Saying that, this is a non-freeform option (right?), so we can design it to be more helpful if we wanted.

If we aren't trying to exactly represent an upstream setting and it's unlikely that non-raw string values will ever be valid, then treating strings as lua is fine IMO.

This was exactly my reasoning.

[GaetanLepage]

Well, I gave it a try and it adds more complexity than I thought.
As dap-go and dap-python both use this type, we would need to port the conversion logic there too.
Maybe it is better to stick to using the rawType straight.

[MattSturgeon]

Yeah, if we did this we'd want to construct two types; one for use in freeform settings and another one that can be used in nixvim's own options.

Both types could use the same modules in their submodule-type though.

[GaetanLepage]

I opened jonboh/nvim-dap-rr#9 to deal with the non-initialization of opts.mappings in setup().

[MattSturgeon]

I opened jonboh/nvim-dap-rr#9 to deal with the non-initialization of opts.mappings in setup().

Does that block this PR?

[GaetanLepage]

I opened jonboh/nvim-dap-rr#9 to deal with the non-initialization of opts.mappings in setup().

Does that block this PR?

Nope, I declared settings.integrations with { __empty = null; } as default, so it doesn't crash.

[MattSturgeon]

Have you double checked that __empty doesn't get merged with normal attr definitions?

Normally option-default prio definitions aren't merged with normal prio definitions, but I can't recall whether attrsOf handles that differently.

If the __empty is merged into the final value then toLuaObject will always print "{}" regardless of what other attrs are in the value.

[jonboh]

I've set this branch as the input of my config flake, but I get an error building the nixvim config:

error: attribute 'attrsOf' missing
       at /nix/store/clsmijxr35nxw1j5xir5kb6mrpkcmrsz-source/plugins/by-name/dap-rr/default.nix:15:7

I get the same error running checks on your latest commit (in the nixvim repo)

[GaetanLepage]

I've set this branch as the input of my config flake, but I get an error building the nixvim config:

error: attribute 'attrsOf' missing
       at /nix/store/clsmijxr35nxw1j5xir5kb6mrpkcmrsz-source/plugins/by-name/dap-rr/default.nix:15:7

I get the same error running checks on your latest commit (in the nixvim repo)

It should be good now.

[MattSturgeon]

Empty test case is failing:

empty> ERROR: Error detected while processing /nix/store/1mw23g71qhja1y2vhhagbr9njaxql94p-init.lua:
empty> E5113: Error while calling lua chunk: ...k/myNeovimPackages/start/nvim-dap-rr/lua/nvim-dap-rr.lua:274: bad argument #1 to 'pairs' (table expected, got nil)
empty> stack traceback:
empty>  [C]: in function 'pairs'
empty>  ...k/myNeovimPackages/start/nvim-dap-rr/lua/nvim-dap-rr.lua:274: in function 'setup'
empty>  /nix/store/1mw23g71qhja1y2vhhagbr9njaxql94p-init.lua:12: in main chunk

[GaetanLepage]

Empty test case is failing:

empty> ERROR: Error detected while processing /nix/store/1mw23g71qhja1y2vhhagbr9njaxql94p-init.lua:
empty> E5113: Error while calling lua chunk: ...k/myNeovimPackages/start/nvim-dap-rr/lua/nvim-dap-rr.lua:274: bad argument #1 to 'pairs' (table expected, got nil)
empty> stack traceback:
empty>  [C]: in function 'pairs'
empty>  ...k/myNeovimPackages/start/nvim-dap-rr/lua/nvim-dap-rr.lua:274: in function 'setup'
empty>  /nix/store/1mw23g71qhja1y2vhhagbr9njaxql94p-init.lua:12: in main chunk

This should go away once #3094 is merged.

[jonboh]

I've tested it in one of my projects with this config and everything seems to work fine.

  plugins.dap-rr = {
    enable = true;
    settings.mappings = {
      continue = "<F10>"; # FRight
      step_over = "<F1>"; # FDown
      step_out = "<F2>"; # FUp
      step_into = "<F3>"; # FRight
      reverse_continue = "<F22>"; # <S-FLeft>
      reverse_step_over = "<F13>"; # <S-FDown>
      reverse_step_out = "<F14>"; # <S-FUp>
      reverse_step_into = "<F15>"; # <S-FRight>
      step_over_i = "<F25>"; # <C-FDown>
      step_out_i = "<F26>"; # <C-FUp>
      step_into_i = "<F27>"; # <C-FRight>
      reverse_step_over_i = "<F37>"; # <SC-FDown>
      reverse_step_out_i = "<F38>"; # <SC-FUp>
      reverse_step_into_i = "<F39>"; # <SC-FRight>
    };
  };

[GaetanLepage]

The fix has made its way to our version of nixpkgs. This should now work just fine.