Re: [patch] some fixes for termdebug
On Mo, 16 Apr 2018, Bram Moolenaar wrote: > Thanks. I had to fix a few problems, but I like the idea of using ! to > execute. Thanks for including. I have usually been using the old way to debug using gdb --args ./vim --clean -c to start and debug right away. Now I can move on to using the termdebug plugin actually. Best, Christian -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] some fixes for termdebug
Christian wrote:
> > > Still when the current session is finished and a new session is run
> > > using `:Termdebug vim` it errors out with E174, because the commands are
> > > already defined.
> >
> > I don't see that. There was an error for one command, it was missing in
> > the list of the cleanup function.
>
> Strange I had it yesterday all day long but now cannot reproduce it.
>
> > > How about to delete the commands when the first window
> > > (the one in which you enter the gdb commands) is closed?
> > > Alternatively, please use the `!` argument to the `:command` definition.
> >
> > I avoid using !, because it would cover up overwriting an existing
> > command (that might do something completely different). It's a bit of
> > a risk already, using simple names such as "Finish" and "Step".
> >
> > > My use case is usually I want to run with a clean state. How about using
> > > the special separator '--' to separate gdb arguments from process
> > > specific arguments. This way I can actually run
> > > `:Termdebug vim -- --clean -c ":call setline('..')"` and start debugging
> > > from a good initial state.
> > >
> > > The attached patch does those two things.
> >
> > Hmm, it's different from how gdb is normally used. And it's also not
> > how you would start Vim. Thus introducing a whole new syntax.
> >
> > When using a core file or running process the command arguments would
> > not be used. Thus we would need some way to specify "this is the
> > command I want to run".
> >
> > Perhaps we can use two commands, one to start with gdb arguments, one
> > with the command to run.
> > :Termdebug vim core
> > :TermdebugCommand vim --clean
> >
> > Something like that? We could also use a command to make gdb execute
> > "run" right away. Sometimes it's a hassle that one needs to navigate to
> > the gdb window to type "run" and then navigate to the program window to
> > type something:
> > :TermdebugRun vim --clean test.txt
> > This would start the debugger on Vim and do "run --clean test.txt" in
> > the gdb window and put the cursor in the command window.
>
> Here is a patch. I did not add the TermdebugRun command, but rather use
> the optional '!' to indicate to run the command.
Thanks. I had to fix a few problems, but I like the idea of using ! to
execute.
--
hundred-and-one symptoms of being an internet addict:
196. Your computer costs more than your car.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] some fixes for termdebug
On So, 15 Apr 2018, Bram Moolenaar wrote:
>
> Christian wrote:
>
> > Still when the current session is finished and a new session is run
> > using `:Termdebug vim` it errors out with E174, because the commands are
> > already defined.
>
> I don't see that. There was an error for one command, it was missing in
> the list of the cleanup function.
Strange I had it yesterday all day long but now cannot reproduce it.
> > How about to delete the commands when the first window
> > (the one in which you enter the gdb commands) is closed?
> > Alternatively, please use the `!` argument to the `:command` definition.
>
> I avoid using !, because it would cover up overwriting an existing
> command (that might do something completely different). It's a bit of
> a risk already, using simple names such as "Finish" and "Step".
>
> > My use case is usually I want to run with a clean state. How about using
> > the special separator '--' to separate gdb arguments from process
> > specific arguments. This way I can actually run
> > `:Termdebug vim -- --clean -c ":call setline('..')"` and start debugging
> > from a good initial state.
> >
> > The attached patch does those two things.
>
> Hmm, it's different from how gdb is normally used. And it's also not
> how you would start Vim. Thus introducing a whole new syntax.
>
> When using a core file or running process the command arguments would
> not be used. Thus we would need some way to specify "this is the
> command I want to run".
>
> Perhaps we can use two commands, one to start with gdb arguments, one
> with the command to run.
> :Termdebug vim core
> :TermdebugCommand vim --clean
>
> Something like that? We could also use a command to make gdb execute
> "run" right away. Sometimes it's a hassle that one needs to navigate to
> the gdb window to type "run" and then navigate to the program window to
> type something:
> :TermdebugRun vim --clean test.txt
> This would start the debugger on Vim and do "run --clean test.txt" in
> the gdb window and put the cursor in the command window.
Here is a patch. I did not add the TermdebugRun command, but rather use
the optional '!' to indicate to run the command.
Best,
Christian
--
Vermutlich hat Gott die Frau erschaffen, um den Mann kleinzukriegen.
-- François Marie Voltaire
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/terminal.txt b/runtime/doc/terminal.txt
index 8deba3922..0cb4a43e6 100644
--- a/runtime/doc/terminal.txt
+++ b/runtime/doc/terminal.txt
@@ -626,6 +626,12 @@ Load the plugin with this command: >
To start debugging use `:Termdebug` followed by the command name, for example: >
:Termdebug vim
+< *:TermdebugCommand*
+If you want to give specific commands to the command being debugged, you can
+use the `:TermdebugCommand` command followed by the command name and
+additional parameters. >
+ :TermdebugCommand vim --clean -c ':set nu'
+
This opens two windows:
gdb window A terminal window in which "gdb vim" is executed. Here you
@@ -636,6 +642,10 @@ program window A terminal window for the executed program. When "run" is
that it does not interfere with controlling gdb. The buffer
name is "gdb program".
+Both the `:Termdebug` and `:TermdebugCommand` support an optional "!" bang
+argument to start the command right away, without pausing at the gdb window
+(and cursor will be in the debugged window).
+
The current window is used to show the source code. When gdb pauses the
source file location will be displayed, if possible. A sign is used to
highlight the current position, using highlight group debugPC.
@@ -656,6 +666,9 @@ arguments. E.g.: >
:Termdebug vim core
:Termdebug vim 98343
+If no argument is given, you'll end up in a gdb window, in which you need to
+specify which command to run using e.g. the gdb `file` command.
+
Example session ~
*termdebug-example*
diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index ded114a2d..87cfe3748 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -25,7 +25,8 @@ endif
" The command that starts debugging, e.g. ":Termdebug vim".
" To end type "quit" in the gdb window.
-command -nargs=* -complete=file Termdebug call s:StartDebug()
+command -nargs=* -complete=file -bang Termdebug call s:StartDebug(0, )
+command -nargs=+ -complete=file -bang TermdebugCommand call s:StartDebugCommand(0, )
"
Re: [patch] some fixes for termdebug
Christian wrote:
> Still when the current session is finished and a new session is run
> using `:Termdebug vim` it errors out with E174, because the commands are
> already defined.
I don't see that. There was an error for one command, it was missing in
the list of the cleanup function.
> How about to delete the commands when the first window
> (the one in which you enter the gdb commands) is closed?
> Alternatively, please use the `!` argument to the `:command` definition.
I avoid using !, because it would cover up overwriting an existing
command (that might do something completely different). It's a bit of
a risk already, using simple names such as "Finish" and "Step".
> My use case is usually I want to run with a clean state. How about using
> the special separator '--' to separate gdb arguments from process
> specific arguments. This way I can actually run
> `:Termdebug vim -- --clean -c ":call setline('..')"` and start debugging
> from a good initial state.
>
> The attached patch does those two things.
Hmm, it's different from how gdb is normally used. And it's also not
how you would start Vim. Thus introducing a whole new syntax.
When using a core file or running process the command arguments would
not be used. Thus we would need some way to specify "this is the
command I want to run".
Perhaps we can use two commands, one to start with gdb arguments, one
with the command to run.
:Termdebug vim core
:TermdebugCommand vim --clean
Something like that? We could also use a command to make gdb execute
"run" right away. Sometimes it's a hassle that one needs to navigate to
the gdb window to type "run" and then navigate to the program window to
type something:
:TermdebugRun vim --clean test.txt
This would start the debugger on Vim and do "run --clean test.txt" in
the gdb window and put the cursor in the command window.
--
hundred-and-one symptoms of being an internet addict:
186. You overstay in the office so you can have more time surfing the net.
/// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org///
\\\help me help AIDS victims -- http://ICCF-Holland.org///
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [patch] some fixes for termdebug
On Sa, 14 Apr 2018, Bram Moolenaar wrote:
>
> Christian wrote:
>
> > here is a patch that fixes and enhances the termdebug plugin.
> >
> > Changes:
> > - Make :Termdebug (without argument) an error
> >After all, if no argument is given, what should you debug?
>
> You can start gdb without a program name and then use ":file cmd" to
> debug an executable. I don't think we should disallow that.
Ah, that actually makes sense. I did not think of that.
>
> > - If you run :Termdebug several times, the plugin throws "E174:
> >command already exists", so add the bang argument to it".
> >In addition, make the commands buffer-local.
>
> I don't like making them buffer-local, because it's not unusual to split
> the window to look at other parts of the source code.
>
> I do think we should disallow running two debuggers, the plugin isn't
> prepared for that.
> > - Arguments supplied to the command line were not used
> > correctly.
> >So in case additional runtime arguments are given, use the
> >"set args" command of gdb to set those arguments. This allows to
> >run e.g. :Termdebug vim --clean -c ":set nu". Currently I believe
> >gdb will try to literally run "vim --clean -c ":set nu"" which
> >fails obviously.
>
> The arguments for running the command are to be added to the "run" gdb
> command. The arguments for gdb can be a core file name or a process id.
> But that doesn't work now, I'll use part of your change to make that
> work.
I am not convinced :)
Still when the current session is finished and a new session is run
using `:Termdebug vim` it errors out with E174, because the commands are
already defined. How about to delete the commands when the first window
(the one in which you enter the gdb commands) is closed?
Alternatively, please use the `!` argument to the `:command` definition.
My use case is usually I want to run with a clean state. How about using
the special separator '--' to separate gdb arguments from process
specific arguments. This way I can actually run
`:Termdebug vim -- --clean -c ":call setline('..')"` and start debugging
from a good initial state.
The attached patch does those two things.
Best,
Christian
--
Drinnen ist es genauso wie draußen, nur anders.
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
diff --git a/runtime/doc/terminal.txt b/runtime/doc/terminal.txt
index 8deba3922..f689a9782 100644
--- a/runtime/doc/terminal.txt
+++ b/runtime/doc/terminal.txt
@@ -656,6 +656,14 @@ arguments. E.g.: >
:Termdebug vim core
:Termdebug vim 98343
+To separate gdb arguments from process specific arguments use the `--`
+separator, e.g.: >
+:Termdebug vim -- --clean -c ':set nu'
+
+Will attach gdb to Vim and use the `--clean -c ':set nu'` arguments for Vim.
+
+If no argument is given, you'll end up in a gdb window, in which you need to
+specify which command to run using e.g. the gdb `file` command.
Example session ~
*termdebug-example*
diff --git a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
index ded114a2d..f35ce1266 100644
--- a/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
+++ b/runtime/pack/dist/opt/termdebug/plugin/termdebug.vim
@@ -95,7 +95,8 @@ func s:StartDebug(...)
" Open a terminal window to run the debugger.
" Add -quiet to avoid the intro message causing a hit-enter prompt.
- let cmd = [g:termdebugger, '-quiet', '-tty', pty] + a:000
+ let [gdb_args, proc_args] = s:Split(a:000)
+ let cmd = [g:termdebugger, '-quiet', '-tty', pty] + gdb_args
echomsg 'executing "' . join(cmd) . '"'
let s:gdbbuf = term_start(cmd, {
\ 'exit_cb': function('s:EndDebug'),
@@ -109,6 +110,11 @@ func s:StartDebug(...)
endif
let s:gdbwin = win_getid(winnr())
+ " Set arguments to be run
+ if len(proc_args)
+call term_sendkeys(s:gdbbuf, 'set args ' . join(proc_args) . "\r")
+ endif
+
" Connect gdb to the communication pty, using the GDB/MI interface
call term_sendkeys(s:gdbbuf, 'new-ui mi ' . commpty . "\r")
@@ -181,6 +187,7 @@ func s:StartDebug(...)
augroup TermDebug
au BufRead * call s:BufRead()
au BufUnload * call s:BufUnloaded()
+au BufUnload call s:DeleteCommands()
augroup END
endfunc
@@ -574,3 +581,26 @@ func s:BufUnloaded()
endfor
endfunc
+func s:Split(list)
+ let gdb_args=[]
+ let prc_args=[]
+ " Check for '--' argument as separator for gdb options and process options
+ " Returns a list with 2 entries:
+ " [ [gd
Re: [patch] some fixes for termdebug
Christian wrote: > here is a patch that fixes and enhances the termdebug plugin. > > Changes: > - Make :Termdebug (without argument) an error >After all, if no argument is given, what should you debug? You can start gdb without a program name and then use ":file cmd" to debug an executable. I don't think we should disallow that. > - If you run :Termdebug several times, the plugin throws "E174: >command already exists", so add the bang argument to it". >In addition, make the commands buffer-local. I don't like making them buffer-local, because it's not unusual to split the window to look at other parts of the source code. I do think we should disallow running two debuggers, the plugin isn't prepared for that. > - Arguments supplied to the command line were not used correctly. >So in case additional runtime arguments are given, use the >"set args" command of gdb to set those arguments. This allows to >run e.g. :Termdebug vim --clean -c ":set nu". Currently I believe >gdb will try to literally run "vim --clean -c ":set nu"" which >fails obviously. The arguments for running the command are to be added to the "run" gdb command. The arguments for gdb can be a core file name or a process id. But that doesn't work now, I'll use part of your change to make that work. Anyway, thanks for looking into making the terminal debugger better. -- If Microsoft would build a car... ... The airbag system would ask "are you SURE?" before deploying. /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ an exciting new programming language -- http://www.Zimbu.org/// \\\help me help AIDS victims -- http://ICCF-Holland.org/// -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [patch] some fixes for termdebug
Le Sat, Apr 14, 2018 at 05:46:35PM +0200, Christian Brabandt a écrit : > Changes: > - Make :Termdebug (without argument) an error >After all, if no argument is given, what should you debug? You can use 'file' or 'attach' in gdb buffer -- -- You received this message from the "vim_dev" maillist. Do not top-post! Type your reply below the text you are replying to. For more information, visit http://www.vim.org/maillist.php --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
