Support vim unstack

[IngoMeyer441]

The LLDB frontend in now capable of copying the current stacktrace to clipboard in a format that is supported by vim-unstack. The feature can be activated by setting

g:vebugger_copy_stacktrace_to_clipboard_lldb = 1

On Linux, either xclip or xsel is needed for the copy operation.

[IngoMeyer441]

Ah the timer commit is also part of the pull request... Didn't think about that :(

[idanarye]

I can merge the timer commit as soon as you solve the eval problem - and then you can rebase this PR. This is not a problem.

What is a problem is that the behavior(copying to the clipboard) is done in the debugger. This means:

• This will be a LLDB-only behavior - other debuggers will have to implement it from scratch - even though all debuggers should be able to emit the stack frame.
• You need additional dependencies to use the stack frame(xclip/xsel) even though Vim already has this capability built-in(the @* register)
• You need to go through the clipboard, even though both Vebuger and Unstack run in the same Vim process.

The way it should be is:

1. Make LLDB print the stack trace on command. Most debuggers do this when you send the where command.
2. Make a read handler that reads these stack and populates the readResult objects.
3. Make a think handler that recognizes the readResult and saves them in the debugger object.
4. Make a command - VBGunstack or something - that formats the stack trace and sens it to unstack#UnstackFromText

Step 1 is already done in most debuggers, and step 2 will need to be repeated for each debugger, but steps 3 and 4 could be shared - as long as step 2 emits the stack frames in a common format. I suggest Vim's quickfix dictionary entries(see :help setqflist()), since Vim can use it to populate the quickfix list even for users who did not install Unstack.

[IngoMeyer441]

You are right, my solution is rather quick and dirty. Your suggestions how it could be done right are much better. I like the idea of avoiding the clipboard at all; currently the clipboard is flooded by stacktraces permanently. I will work on that when I have some more time; It seems as it could become some longer task.

Is it possible to implement a new read handler (that is for the new think handler) in one debugger frontend first or do all debugger frontends need an empty read handler at least?

[idanarye]

Vebugger is designed to allow adding features to some debuggers without having to implement them(right away) in all the debuggers:

• If you don't implement a read handler, the readResult field for that feature will never be set and nothing will happen.
• If you don't implement a write handler, the writeAction will not be sent to the debugger, which means that again - nothing will happen.
• If you don't implement a think handler nothing will handler the readResult and nothing will send writeActions - so nothing will happen. I don't see this one happening though, since think handlers are supposed to be debugger-agnostic so there is no reason for them to be missing...

So, worst case - the new feature will not work for other debuggers until we implement the read handlers for them.

[idanarye]

Wait what why? Are you completely bypassing Vebugger to send the stack trace to tmux?

[IngoMeyer441]

I just needed a quick solution to get stacktraces into the tmux paste buffer and pushed the code to synchronize it with multiple machines. This commit was actually not planed for this pull request... but GitHub of course updated the pull request automatically. Just ignore the last commit....