[vim/vim] Events when starting/stopping termdebug (#8709)

84 views
Skip to first unread message

Federico Igne

unread,
Aug 5, 2021, 6:46:50 AM8/5/21
to vim/vim, Subscribed

Requested feature
It would be nice to be able to run custom commands when starting/stopping GDB through the termdebug plugin.
An example would be to be able to turn on line numbers when :Termdebug ... is issued and turn them off when typing quit in GDB.

Solution
Events like TermdebugStartPre, TermdebugStartPost, TermdebugStopPre, TermdebugStopPost should allow this quite easily.

Alternatives
To run custom commands upon starting termdebug I'm currently wrapping :Termdebug around a function and, e.g., call set nu from there.
To restore/undo those commands when termdebug terminates I currently don't have a solution. I thought about using the hidden buffer that the plugin uses to communicate with gdb but haven't looked into it yet.

If this is something interesting, with some pointers, I should be able to contribute to the issue myself.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Triage notifications on the go with GitHub Mobile for iOS or Android.

lacygoill

unread,
Aug 5, 2021, 7:00:54 AM8/5/21
to vim/vim, Subscribed

If this is something interesting, with some pointers, I should be able to contribute to the issue myself.

Check out $VIMRUNTIME/pack/dist/opt/termdebug/plugin/termdebug.vim.

For every new event you want the plugin to fire (TermdebugStartPre, TermdebugStartPost, TermdebugStopPre, TermdebugStopPost), add this kind of block:

if exists('#User#TermdebugStartPre')
    doautocmd <nomodeline> User TermdebugStartPre
endif

Then the user can write this in their vimrc:

autocmd User TermdebugStartPre echomsg 'do something'

Example of a patch:

diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index f80d9c396..45d4beaa2 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -108,6 +108,9 @@ func s:StartDebugCommand(bang, ...)
 endfunc
 
 func s:StartDebug_internal(dict)
+  if exists('#User#TermdebugStartPre')
+    doautocmd <nomodeline> User TermdebugStartPre
+  endif
   if exists('s:gdbwin')
     echoerr 'Terminal debugger already running, cannot run two'
     return

When you get something which works, don't forget to add some documentation in $VIMRUNTIME/doc/terminal.txt (:help terminal-debug).

Bram Moolenaar

unread,
Aug 5, 2021, 10:24:31 AM8/5/21
to vim/vim, Subscribed


Federico Igne wrote:

> **Requested feature**

> It would be nice to be able to run custom commands when starting/stopping GDB through the termdebug plugin.
> An example would be to be able to turn on line numbers when `:Termdebug ...` is issued and turn them off when typing `quit` in GDB.
>
> **Solution**
> Events like `TermdebugStartPre`, `TermdebugStartPost`, `TermdebugStopPre`, `TermdebugStopPost` should allow this quite easily.
>
> **Alternatives**

> To run custom commands upon starting termdebug I'm currently wrapping `:Termdebug` around a function and, e.g., call `set nu` from there.
> To restore/undo those commands when termdebug terminates I currently don't have a solution. I thought about using the hidden buffer that the plugin uses to communicate with gdb but haven't looked into it yet.
>
> If this is something interesting, with some pointers, I should be able to contribute to the issue myself.

I think we can add User autocommands:

au User TermdebugStartPre before starting debugging
au User TermdebugStartPost after debugging has initialized
au User TermdebugStopPre before debugging ends
au User TermdebugStopPost after debugging has ended

I'll add these, please try them out after the next update and see if
this does what you want.


--
ARTHUR: Will you ask your master if he wants to join my court at Camelot?!
GUARD #1: But then of course African swallows are not migratory.
GUARD #2: Oh, yeah...
GUARD #1: So they couldn't bring a coconut back anyway...
The Quest for the Holy Grail (Monty Python)

/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

Federico Igne

unread,
Aug 5, 2021, 11:32:10 AM8/5/21
to vim/vim, Subscribed

@brammool if it's the same for you I can give it a try.
I already have somewhat of a working version, I just need to add some documentation and open a PR.

ii14

unread,
Aug 23, 2021, 2:19:59 PM8/23/21
to vim/vim, Subscribed

Related question, could we also add a new filetype for terminal window? I'd like to map some keys for gdb window and this kinda works, but only when g:termdebug_disasm_window is turned off, if I'm reading the code correctly. A new filetype like termdebug would be more robust.

Bram Moolenaar

unread,
Aug 23, 2021, 3:20:18 PM8/23/21
to vim/vim, Subscribed


> Related question, could we also add a new filetype for terminal
> window? I'd like to map some keys for gdb window and this kinda works,
> but only when `g:termdebug_disasm_window` is turned off, if I'm
> reading the code correctly. A new filetype like `termdebug` would be
> more robust.

Currently no filetype is used, thus setting one should be harmless.
How about below job_setoptions():

call job_setoptions(term_getjob(s:gdbbuf), {'exit_cb': function('s:EndTermDebug')})

" Set the filetype, this can be used to add mappings.
set filetype=termdebug

call s:StartDebugCommon(a:dict)


--
FATAL ERROR! SYSTEM HALTED! - Press any key to continue doing nothing.


/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

ii14

unread,
Aug 23, 2021, 4:23:51 PM8/23/21
to vim/vim, Subscribed

Yeah, seems fine to me. 👍

ii14

unread,
Aug 23, 2021, 4:33:27 PM8/23/21
to vim/vim, Subscribed

I was also wondering about the window with the application output, maybe it should also have a custom filetype, like termdebug_program or something along these lines. I personally don't have any use for it right now, but maybe someone else does.

Bram Moolenaar

unread,
Aug 24, 2021, 2:27:31 PM8/24/21
to vim/vim, Subscribed


> I was also wondering about the window with the application output,
> maybe it should also have a custom filetype, like `termdebug_program`
> or something along these lines. I personally don't have any use for it
> right now, but maybe someone else does.

The window where the application is running could do anything. I
normally run Vim there, then the filetype of the window is irrelevant.


--
This message contains 78% recycled characters.


/// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

ii14

unread,
Aug 24, 2021, 2:48:58 PM8/24/21
to vim/vim, Subscribed

I know, but what I'm getting at is that someone might want to set up mappings there or register the job ID from that window to send keys to the program etc. Maybe I'm just overthinking it.

lacygoill

unread,
Oct 24, 2021, 2:17:07 PM10/24/21
to vim/vim, Subscribed

I guess this issue can be closed, since the Termdebug* events have been added when the PR #8711 was merged.

If there are other issues with the termdebug plugin, they should probably be dealt with in a dedicated and separate issue.


You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub.

Bram Moolenaar

unread,
Oct 24, 2021, 3:43:55 PM10/24/21
to vim/vim, Subscribed

Please open a new issue if the newly added events are insufficient.


You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub.

Bram Moolenaar

unread,
Oct 24, 2021, 3:43:56 PM10/24/21
to vim/vim, Subscribed

Closed #8709.


You are receiving this because you are subscribed to this thread.

Reply to this email directly, view it on GitHub.

Reply all
Reply to author
Forward
0 new messages