Open floating terminal on command start not on exit

[gwenwindflower]

I think it would be an improvement to a) use a more featureful terminal window vs the popup b) have it open immediately on command issue, rather than displaying the customized popup with the final data on exit. Happy to hack on this but maybe we can jam a bit so I know my way around the repo better? lmk what you think.

[gwenwindflower]

yes i am vimming on friday night leave me alone.

[PedramNavid]

ah yea i've thought about this! because this uses an async job with a callback, nvim doesnt bubble up the command results until the job is complete.

there are some other options here, similar to what https://github.com/tpope/vim-dispatch/blob/master/doc/dispatch.txt does. i like the idea of giving users options on where dbt runs, e.g. in a separate shell or tmux environment.

the other idea i had was that if everything succeeds, by default just send a vim-notify message, rather than show the entire terminal output (since there's no real benefit there).

taking it one step further, could even parse the dbt errors and send them to vim quickfix so if more than one file has problems you can quickly jump to the next failure with [q and ]q

see #9 and #12

[gwenwindflower]

what would you think about trying to implement this for the UI elements? this seems like it would cover everything really well https://github.com/folke/noice.nvim [i may be completely misinterpreting what this plugin does i slept really poorly and i'm not well versed in nvim plugin land yet]

[PedramNavid]

i already added nvim notify for the debugging messages a few days ago, so if you have that installed you’ll get these for the logs and errors that dbtpal generates.

it doesn’t solve the delayed terminal output and i don’t think it’ll work for dbts output because it contains color ascii codes which needs a terminal buffer to display properly.

did you have other any other output you were hoping to see? we could probably use json parsing of structured logs in newer dbt versions if you had some other view you were thinking of?

[gwenwindflower]

amazing! i need to update.

so to describe from a very high level what i was envisioning as an ideal workflow:

1. i command to run the current file
2. this is dispatched to a detached terminal and i stay in the buffer
3. a notification comes back with success or failure messages based on the outcome, not necessarily the stdout from dbt
4. if it failed errors are identified in the quickfix

[optional] 5. i can easily pull up the terminal it ran if i need to look at the output

[PedramNavid]

that does sound like a very nice workflow. i think handling success with a simple message is very straightforward. we can start there and then deal with the failure case next? the code is a bit of a mess but let me find some time this weekend and i can share something for us to jam on

…

On Wed, Jul 26 2023 at 8:21 AM, winnie ***@***.***> wrote: amazing! i need to update. so to describe from a very high level what i was envisioning as an ideal workflow: 1. i command to run the current file 2. this is dispatched to a detached terminal and i stay in the buffer 3. a notification comes back with success or failure messages based on the outcome, not necessarily the stdout from dbt 4. if it failed errors are identified in the quickfix — Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAH7LZSTKQBLVV2BWEQUXFLXSEYXXANCNFSM6AAAAAA2TPODUQ> . You are receiving this because you commented.Message ID: ***@***.***>