[vim/vim] Termdebug: function + command to close program pty (PR #10389)
Simon Sobisch
providing both a possible workaround for #9319 by allowing you to call ClosePtyBuff after opening and an "attach" attribute in the dictionary (currently not set) to allow not opening the pty in the first place.
Reason for the attribute not being set: there is currently no defined code path to know about "Do we attach or debug a core dump?", partially because there are multiple ways to reach that including specifying "prog core.file", "prog 1234", "1234" when starting TermDebug, but that also can come in later positions because one may also want to pass more commands like -ix some_init.gdb before.
You can view, comment on, or merge this pull request online at:
https://github.com/vim/vim/pull/10389
Commit Summary
- 8142324 Termdebug: function + command to close program pty
File Changes
(1 file)
Patch Links:
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Simon Sobisch
@GitMensch pushed 1 commit.
- 42d5ef7 Termdebug: function + command to close program pty
—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
> providing both a possible workaround for #9319 by allowing you to call
> `ClosePtyBuff` after opening and an "attach" attribute in the
> dictionary (currently not set) to allow not opening the pty in the
> first place.
>
> Reason for the attribute not being set: there is currently no defined
> code path to know about "Do we attach or debug a core dump?",
> partially because there are multiple ways to reach that including
> specifying "prog core.file", "prog 1234", "1234" when starting
> TermDebug, but that also can come in later positions because one may
> also want to pass more commands like `-ix some_init.gdb` before.
Can we see from the arguments whether a process ID or core dump file is
passed? Assuming the command has no spaces it would be a simple "more
than one word" rule. Then we could automatically skip opening a window
to run the program in.
--
hundred-and-one symptoms of being an internet addict:
152. You find yourself falling for someone you've never seen or hardly
know, but, boy can he/she TYPE!!!!!!
/// 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 ///
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Simon Sobisch
Using an "attach" flag seems strange. Something like "notty" perhaps?
no_tty sounds better to me, too
Can we see from the arguments whether a process ID or core dump file is passed?
We can only try. The reason for that is:
g:termdebugger may be an array that includes command line arguments passed to the debugger (with tools like rr also command line arguments that are passed to that) and arguments (if --args is used), that are passed to the program.
Also TermDebug can include command line arguments for all of these.
I think it is only reasonable to check the later one.
- If the only argument of
TermDebugis a number, then -> no_tty (= attach to pid) - if there's an argument
--argsin the list of arguments we only need to inspect everything before - if there is argument
--coreor--pid, then -> no_tty - if the last argument is a number or an existing file and the argument before is given and not an argument itself we have the "prog 123" / "prog some.core" scenario --> no_tty
- if we have one of the options --eval-command=COMMAND, -ex COMMAND, --init-eval-command=COMMAND, -iex COMMAND and COMMAND is
target ...we possibly are remote debugging... (in this case there's too much guessing, similar with -x / -ix options)
So yes: there can be an educated guess in the first scenarios, but there's no knowledge in other cases.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Damien R.
@GitMensch Sorry for reviving this long-opened pull request, but I'm interested about that feature. My use case is working with an embedded target and having a lingering tty window is annoying. In my case, I can open another terminal to get SWO output with StartPost and StopPre hooks like so:
function! SetupSWO()
let s:swo_terminal = term_start("telnet 127.0.0.1 2332", { "term_kill" : "term", "term_name": "SWO" })
" call TermDebugSendCommand("send whatever commands to GDB to enable SWO on target")
endfunction
function! TearDownSWO()
if exists("s:swo_terminal")
exe $"bwipe! {s:swo_terminal}"
unlet s:swo_terminal
endif
endfunction
au User TermdebugStartPost call SetupSWO()
au User TermdebugStopPre call TearDownSWO()
With these hooks I can also close the PTY window but it's hackish and triggers an error when ending the debug session.
I don't know if you plan to update your PR with Bram's comments, but if you don't I could pick it up and send an updated version.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Simon Sobisch
Checked: termdebug.vim is now Vim9, so the changes visible here would be best applied to the current version.
@d-k-c could you try to do so while implementing Bram's single request "name that no_tty"?
Once this is merge one of us could work on the outlined idea of auto-.setting the no_tty attribute if the command to start shows us that we do attach / do a coredump debugging.
I'm happy to review your PR, please drop a note!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
closed in favor or #14997
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
Closed #10389.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.