[vim/vim] runtime(termdebug): add no_tty option to prevent creation of TTY window (PR #14997)
Damien R.
In some circumstances, like debugging an embedded system, the TTY window is useless and there was no way to prevent its creation.
Add a new "no_tty" option to termdebug_config to let user get rid of TTY window if they don't want it.
This is based on development by @GitMensch in #10389, adapted to newer Vim Script.
Unfortunately I could not get the vim9 version to work with my local installation for unknown reasons, so it's untested.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/14997
Commit Summary
- e36b8ff runtime(termdebug): add no_tty option to prevent creation of TTY window
File Changes
(2 files)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
I have been there :)
In reality, all the work that I started been doing on termdebug originates from a need I had for embedded systems.
Nevertheless, I sort of solved this problem through a script that tweaks the underlying termdebug settings: such a script closes the "debugged program" buffer/window, start a open_ocd server, open a buffer/window running a serial monitor, etc.
That is to say that for embedded we need more than just closing the pty for the debugged program - and in-fact I plan to write a plugin for this purpose in the future, if time allows.
Instead of adding your proposed change here, you may want to create a script that adjust termdebug as I described above?
In this way we would keep a clear separation line between embedded applications and applications that require a window with a running program (at first thought I would say all the applications requires it but embedded). Plus the termdebug code functions would contain less logic to maintain without this option. What do you and the others think?
Nevertheless, if the team decide to include this change, could you please write some tests?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
just curious, what issues did you face with the vim9 implementation?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
just curious, what issues did you face with the vim9 implementation?
For example, the fact that you can only map 3 keys (K, + and -) and the lack of Frame and Watch windows just to cite some and perhaps some more that now I could not even remember. I remember some of them are very tedious to adjust with just a script on top, but it would have been easier/better to work on the termdebug itself. But then, I could not script with the legacy language, plus I had fairly enough large time so I converted it to Vim9 on my own repo. But then I realized that the whole community may appreciate such porting (I am everything but greedy!) and I issued my first PR here. The rest is history.. :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien R.
It's probably due to the way I developed this. I'm symlinking master's termdebug plugin into my current installation:
- I cloned vim repository
- symlink'd master's plugin into my local setup
ln -s $VIM_REPO/vim/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim ~/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim - When I start vim, I get already loaded errors (I added
Echoerr(expand('<sfile>:p'))to try to understand a bit more).
[termdebug] /Users/dkc/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim
[termdebug] /Users/dkc/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim
[termdebug] Termdebug already loaded.
- When using
Termdebug, I getE117: Unknown function: StartDebugerror.
My vim is the latest one available on Homebrew:
$ vim --version
VIM - Vi IMproved 9.1 (2024 Jan 02, compiled May 30 2024 05:52:44)
macOS version - x86_64
Included patches: 1-450
Compiled by Homebrew
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien R.
@ubaldot this looks very very much like what I want.
Instead of merging this PR, you may want to create a script that adjust termdebug as described above?
Sorry but I'm not super familiar with Vim development, would such a script be packaged as part of vim? If so would it be another package or something different?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
@ubaldot this looks very very much like what I want.
Instead of merging this PR, you may want to create a script that adjust termdebug as described above?
Sorry but I'm not super familiar with Vim development, would such a script be packaged as part of vim? If so would it be another package or something different?
No, I don't think that it will be packaged in the Vim distribution. It will be most likely a separate package. Maybe. One day. :) I suggest you to comment on my repo for everything related to the usage of such a script and I will help you from there, so we avoid polluting this discussion with off-topic arguments. :)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
It's probably due to the way I developed this. I'm symlinking master's termdebug plugin into my current installation:
- I cloned vim repository
- symlink'd master's plugin into my local setup
ln -s $VIM_REPO/vim/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim ~/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim- When I start vim, I get already loaded errors (I added
Echoerr(expand('<sfile>:p'))to try to understand a bit more).[termdebug] /Users/dkc/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim [termdebug] /Users/dkc/.vim/pack/develop/opt/termdebug/plugin/termdebug.vim [termdebug] Termdebug already loaded.
- When using
Termdebug, I getE117: Unknown function: StartDebugerror.My vim is the latest one available on Homebrew:
$ vim --version VIM - Vi IMproved 9.1 (2024 Jan 02, compiled May 30 2024 05:52:44) macOS version - x86_64 Included patches: 1-450 Compiled by Homebrew
I am a bit in a rush now, but do you have any packadd termdebug in your .vimrc or in some script that you sourced?
Given that termdebug is only one file, one quick and dirty test could be the following:
- create a
~/foofolder, - copy the whole latest termdebug.vim file into such a folder,
- open vim in that folder (you could try to launch vim with --clean flag),
- run :source %
- run :Termdebug
Let us know!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien R.
@d-k-c pushed 2 commits.
- 376a532 runtime(termdebug): close all buffers in the same way
- 033d2f3 runtime(termdebug): add no_tty option to prevent creation of TTY window
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien R.
Thank you that worked! I've split the initial commit into two: the first one to only tackle closing buffers, the second one with the no_tty feature.
I think the first one can be picked up with any issue, that way if users close the tty window manually, there is no bwipe related error anymore. The second one is up for debate, maybe a dedicated script is the right way to go.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
@yegappan requested changes on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -354,23 +353,32 @@ enddef
# Open a terminal window without a job, to run the debugged program in.
def StartDebug_term(dict: dict<any>)
- ptybufnr = term_start('NONE', {
- term_name: 'debugged program',
- vertical: vvertical})
- if ptybufnr == 0
- Echoerr('Failed to open the program terminal window')
- return
+ var create_pty = 1
Instead of using 0 and 1, can you use the Boolean values true and false?
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -328,14 +328,13 @@ enddef
# Use when debugger didn't start or ended.
def CloseBuffers()
- exe $'bwipe! {ptybufnr}'
- exe $'bwipe! {commbufnr}'
- if asmbufnr > 0 && bufexists(asmbufnr)
- exe $'bwipe! {asmbufnr}'
- endif
- if varbufnr > 0 && bufexists(varbufnr)
- exe $'bwipe! {varbufnr}'
- endif
+ var bufnames = ['debugged\ program', 'gdb\ communication', asmbufname, varbufname]
+ for bufname in bufnames
+ if bufnr(bufname) > 0 && bufexists(bufnr(bufname))
Instead of calling bufnr() twice, can you store the return value in a local variable and then use it?
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> - ptybufnr = 0
- if has('win32')
- # MS-Windows: run in a new console window for maximum compatibility
- SendCommand('set new-console on')
- elseif has('terminal')
- # Unix: Run the debugged program in a terminal window. Open it below the
- # gdb window.
- belowright ptybufnr = term_start('NONE', {
- term_name: 'debugged program',
- vertical: vvertical
- })
- if ptybufnr == 0
- Echoerr('Failed to open the program terminal window')
- job_stop(gdbjob)
- return
+ var create_pty = 1
Can you use var create_pty: bool = true?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien R.
Damien R.
@ubaldot I added an extra commit to make TermDebugSendCommand global again, it seems to have been dropped when the script was converted to vim9 syntax.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
Thank you that worked! I've split the initial commit into two: the first one to only tackle closing buffers, the second one with the no_tty feature.
Awesome! Thanks! Now we only have to decide if we want to merge both the commits or only the one related to CloseBuffers(). In my opinion, if embedded is the only use-case for not having the debugged program pty, I would not include the commit, as I discussed above. @chrisbra @yegappan What do you think?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
It's probably due to the way I developed this. I'm symlinking master's termdebug plugin into my current installation:
maybe it was a bug:
099.099 000.639 000.639: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
191.283 000.027 000.027: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
102.040 000.765 000.765: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
216.570 000.028 000.028: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
121.850 001.149 001.149: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
255.589 000.028 000.028: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
120.244 000.765 000.765: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
235.894 000.028 000.028: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
173.052 000.858 000.858: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
302.396 000.031 000.031: sourcing /usr/local/share/vim/vim82/pack/dist/opt/termdebug/plugin/termdebug.vim
619.493 005.905 005.905: sourcing /usr/local/share/vim/vim90/pack/dist/opt/termdebug/plugin/termdebug.vim
1573.176 000.206 000.206: sourcing /usr/local/share/vim/vim90/pack/dist/opt/termdebug/plugin/termdebug.vim
514.097 006.278 006.278: sourcing /usr/local/share/vim/vim90/pack/dist/opt/termdebug/plugin/termdebug.vim
1819.148 000.203 000.203: sourcing /usr/local/share/vim/vim90/pack/dist/opt/termdebug/plugin/termdebug.vim
172.500 000.912 000.912: sourcing /usr/local/share/vim/vim91/pack/dist/opt/termdebug/plugin/termdebug.vim
407.808 000.237 000.237: sourcing /usr/local/share/vim/vim91/pack/dist/opt/termdebug/plugin/termdebug.vim
i can reproduce it, but i cannot reproduce it with '--clean' and manually 'packadd termdebug'
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
@Shane-XB-Qian commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -717,7 +717,7 @@ def ContinueCommand() enddef # This is global so that a user can create their mappings with this. -def TermDebugSendCommand(cmd: string) +def g:TermDebugSendCommand(cmd: string)
if it worked, then you may need to update the doc/help as well, there is some description about this func.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien R.
@d-k-c commented on this pull request.
In runtime/pack/dist/opt/termdebug/plugin/termdebug.vim:
> @@ -717,7 +717,7 @@ def ContinueCommand() enddef # This is global so that a user can create their mappings with this. -def TermDebugSendCommand(cmd: string) +def g:TermDebugSendCommand(cmd: string)
From my script, I can call TermDebugSendCommand("...") without the leading g:, but if the function is not declared with the g: then the call fails with E117: Unknown function: TermDebugSendCommand. I'm not sure the doc needs to be updated.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Thanks. I'll merge commit 1 and 3. For number 2, I leave it to @ubaldot . Please take this to his repository. I am sure you will figure out a solution to this, that will then eventually be merged back here. Thanks all!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
> but if the function is not declared with the `g:` then the call fails with `E117: Unknown function: TermDebugSendCommand`. I'm not sure the doc needs to be updated.
yes, that is another magic of vim9 script.
--
shane.xb.qian
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Simon Sobisch
First thanks @d-k-taking the work to implement this to the current version!
[....]I've split the initial commit into two: the first one to only tackle closing buffers, the second one with the no_tty feature.
Awesome! Thanks! Now we only have to decide if we want to merge both the commits or to merge only the commit related to
CloseBuffers(). In my opinion, if embedded systems is the only use-case for not having the debugged program pty, I would not include the commit, for all the reasons I discussed above. @chrisbra @yegappan What do you think?
Embedded is far from the only use-case for that!
This relates to everything where you don't have a program pty:
- foremost attaching to running processes i.e.
:Termdebug 1234 - inspecting a coredump
:Termdebug ./prog ./core
Braam considered that so relevant that he wanted to:
- have the setting
no_pty - try to deduce the setting that should be used when termdebug is started with parameters (clear in the case above, not clear in other cases)
I suggest to create a new PR to:
- move
CreatePtyto a separate function (mostly for clarity and maybe to be able to execute it if the pty was closed), otherwise we can leave it there, if that would be preferred - add the
no_ttysettting with 0/1/2 (are there better values?) for "no", "deduce", "yes" - "deduce" would use the logic discussed with Bram
@chrisbra Do you agree?
@d-k-c Would you work on at least part of this PR?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
This relates to everything where you don't have a program pty:
* foremost attaching to running processes i.e. `:Termdebug 1234` * inspecting a coredump `:Termdebug ./prog ./core`
Braam considered that so relevant that he wanted to:
* have the setting ` no_pty` * try to deduce the setting that should be used when termdebug is started with parameters (clear in the case above, not clear in other cases)
as my understanding, it was to hide the program window, right?
if yes, seems not a very matter, event those cases not req pty, but seems ok it was default there, or you can just close it manually, all in all termdebug by default was gdb/source/program, seems reasonable.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
if you (or any of you) have time, perhaps can try to reproduce and find out why #14997 (comment) this wrong/dup sourcing happened, that maybe odd somehow i donot know why so far.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Shane-XB-Qian
if you (or any of you) have time, perhaps can try to reproduce and find out why #14997 (comment) this wrong/dup sourcing happened, that maybe odd somehow i donot know why so far.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
ubaldot
Embedded is far from the only use-case for that!
Ok! Thanks for the info! 😅
It seems there are solid arguments to have this feature, perhaps we shall open a new PR for that. Shall we do it now or later on once we have finished with the refactoring/bugfix process that is currently undergoing?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Damien R.
@GitMensch For sure I can help. My Vim script skills are pretty limited but I can give it a try. We could try to detect what type of debugging is going on by reading GDB messages as suggested in #9319 and default to opening the program window if no "known types of debug" are found.
@ubaldot With the snippet you posted, the program pty was closed on start-up but that triggered an error when the debug session was ended as termdebug tried to close the already-closed pty. At least that should be fixed now, no wore bwipe errors. Side question but what is the refactoring/bugfix that is currently undergoing?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.