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

foreign_keys and exit options do not overwrite color as noted in README #37

Open
mintelm opened this issue Apr 22, 2024 · 5 comments
Open
Assignees
Labels
bug Something isn't working documentation Improvements or additions to documentation

Comments

@mintelm
Copy link

mintelm commented Apr 22, 2024

Hello everyone,

there's a sentence in the README that describes that foreign_keys and exit configuration options actually overwrite the behavior specified by a color. At least I could not get it working.

What is my problem?
I want to create a DAP hydra that has the policy of an amaranth hydra. However, since DAP stepping/continuing is asynchronous, I have to use a pink hydra. When using a pink hydra and specifying { foreign_keys = 'warn', exit = true }, the behavior of the hydra does not change, i.e. it still processes inputs that are not mapped to a head.

What would solve my problem?

  • option 1: I can create a pink hydra and specify foreign_keys and exit and the configuration actually changes the behavior of the hydra
  • option 2: I can create a amaranth hydra that works with the asynchronous events of DAP (I tried the trick with { on_key = function() vim.wait(20) end, color = 'amaranth' } that is used in the proposed git hydra, however that does not work as expected with the DAP since when i use dap.continue() it actually pastes some text into the popup created by dap.continue()

Example code:

    function cmd(command, suffix)
        suffix = suffix or ''
        return '<cmd>' .. command .. '<CR>' .. suffix
    end


    hydra({
        name = 'Debugging',
        config = { color = 'pink', foreign_keys = 'warn', exit = true },
        hint = hints.dap,
        mode = 'n',
        body = '<Leader>d',
        heads = {
            { 'b',     cmd('DapToggleBreakpoint') },
            { 'c',     cmd('DapContinue') },
            { 's',     cmd('DapStepOver') },
            { 'i',     cmd('DapStepInto') },
            { 'o',     cmd('DapStepOut') },
            { 'r',     cmd('DapToggleRepl') },
            { 'u',     function() require('dapui').toggle({ reset = true }) end },
            { 'w',     function() require('dapui').elements.watches.add() end },
            { '<Esc>', nil,                                                     { exit = true, nowait = true, desc = false }, },
        },
    })

@benlubas
Copy link
Collaborator

https://github.com/benlubas/hydra.nvim/blob/eb68396f4f3185e000d64711419c71f67b23bb1d/lua/hydra/init.lua#L126

It seems like there's an inconsistency between the docs and the code here.

@benlubas
Copy link
Collaborator

benlubas commented Apr 27, 2024

going back to when that code was written, the docs said the same thing. Guess it just slipped through at the time and hasn't been caught since.

However, I'm not sure fixing this will even fix the problem you're having. color and exit/foreign_keys do have to be reconciled one way or the other, so you currently can't have a Pink hydra that behaves like an Amaranth one, that would just be made into an Amaranth hydra.

edit. I guess in this case, 'warn' + exit = true would give you a Teal Hydra.

@benlubas benlubas self-assigned this Apr 27, 2024
@benlubas benlubas added bug Something isn't working documentation Improvements or additions to documentation labels Apr 27, 2024
@mintelm
Copy link
Author

mintelm commented Apr 29, 2024

ahh okay, makes sense that it does not work how I expect it to if the documentation is inconsistent.

Okay, if I understood you correctly: with the current implementation it is basically not possible to have an -- I'll use a different terminology here -- async hydra (pink) that uses foreign_keys = 'warn'?

@benlubas
Copy link
Collaborator

Yeah currently impossible. I'd be open to changing it though (at the very least I will update the docs). I'm not sure how hard it would be to do though.

@mintelm
Copy link
Author

mintelm commented Apr 30, 2024

I mean sure, I am keen on this feature, so I'd be glad if you tried it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working documentation Improvements or additions to documentation
Projects
None yet
Development

No branches or pull requests

2 participants