On 10/04/11 04:21, Rostyslaw Lewyckyj wrote:
Tony Mechelynck wrote:
On 09/04/11 05:22, Rostyslaw Lewyckyj wrote:
Would any of you be so kind as to send me pointers
on where, online, I can find any tutorials on vim
debug which contain full examples to illustrate
what is sketched in :h?
For example where do I write any of the commands
to define breakpoints, and then at a breakpoint
to dump values both from the file being processed
and the script being debugged. How do I change
any of the values of the file and script,
without terminating the debug run?
There are two ways to debug Vim:
- Vim debug mode, see :help debug-mode
You don't write the commands into a file, you type them at the keyboard.
- with an external debugger (e.g. gdb) see the debugger's documentation.
This is outside the scope of the present mailing list.
Best regards,
Tony.
Thank you Mr. Mechelynck. However:
I am on a Windows system and so no gdb. or other such debugger.
I am using GVIM and haven't figured out how to run straight vim
as suggested in :h.
You mean you can run *neither* vim nor gvim? I'm baffled.
Or if you can, read attentively the whole section 5 of repeat.txt,
starting at ":help debug-scripts" and continuing until just before "6.
Profiling". This section 5 is not about writing scripts to debug Vim,
but about typing special "debugging" commands to debug your scripts (or
any scripts sourced by vim or gvim).
If you start Vim from the cmd.exe prompt as
gvim.exe --cmd "gui" -D
it will stop at the first line of the first script (probably your vimrc)
saying
>
(i.e. a greater-than sign, in case your mailer replaced this with a
vertical quote bar). What you can answer is listed starting at ":help
>cont" (again, this is a greater-than sign followed by c o n t). For
instance, type s[tep], i.e.
>s
followed by Enter, to see the next line that Vim executes, including
inside a sourced script or called function. Or
>n
to see the next line, but skipping sourced scripts and called functions.
And if at any moment you want to see the value of some variable or
option, just ask, and Vim will tell you:
:echo foobar
1
:set compatible?
nocompatible
Therefore if you can't offer any pointers to tutorials as requested
perhaps you can offer specific instructions for the following:
- I have a small script xxx.vim which I am developing and debugging
and on which I am learning the intricacies of vim scripting.
- I have a file testf.txt on which I am testing xxx.vim
- I load up testf.txt and now I'd like to do a debug run of
xxx.vim against testf.xxx
Ok. How do I do it?
vim.exe -c "breakadd file */xxx.vim" testf.txt
or
gvim.exe -c "breakadd file */xxx.vim" testf.txt
or even
gvim testf.txt
:breakadd file */xxx.vim
source xxx.vim
Any of these will start Vim for editing the file testf.txt and with a
breakpoint set at the first line of any script named xxx.vim in any
directory.
I can start debug with :debug source xxx.vim . But how do I
now add breakpoints to the process?
see :help :breakadd
A breakpoint is only useful when you're *not* doing step-by-step
debugging (but letting Vim "do its stuff" at its usual pace until it
reaches a breakpoint). ":debug source foobar.vim" is IIUC the equivalent
of both setting a breakpoint at the first line of foobar.vim and
sourcing that script.
Using the s command is not
a viable option. I might just as well keep modifying xxx.vim
with various :echo commands to see what is happenning
Also the remarks about breakpoints in :h are quite cryptic
Regards,
Tony.
--
The difference between this school and a cactus plant is that the
cactus has the pricks on the outside.
--
You received this message from the "vim_use" 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
