Wikia

Vim Tips Wiki

Changes: Bisecting

Edit

Back to page

(correct wikipedia link and add asee also and comments section)
(Insert TipProposed template + minor manual clean)
 
Line 1: Line 1:
<!-- Why aren't images working? Need to find a ☺ case to match our ☠ case. [[File:Narrowing.gif|link=http://www.st.cs.uni-saarland.de/dd/|frame]] -->
+
{{TipProposed
  +
|id=0
  +
|previous=0
  +
|next=0
  +
|created=September 12, 2012
  +
|complexity=basic
  +
|author=Ryanking
  +
|version=7.0
  +
|subpage=/201209
  +
|category1=
  +
|category2=
  +
}}
  +
Debugging Vim problems is a classic example of working with a system that is often too complex to sit back, stroke your beard, and reason your way through. Perhaps it is the "Hello World" of this class of problems?
   
Debugging vim problems is a classic example of working with a system that is often too complex to sit back, stroke your beard, and reason your way through. Perhaps it is the "Hello World" of this class of problems?
+
So learn about bisecting, aka [https://c2.com/cgi/wiki?BinaryChop Binary Chop], aka [http://www.st.cs.uni-saarland.de/dd/ Delta Debugging], aka [[wikipedia:Divide_and_conquer_algorithm|Divide and Conquer]].
   
So learn about bisecting, AKA [https://c2.com/cgi/wiki?BinaryChop Binary Chop], AKA
+
When you do bisect, you have to start with a ☺ version and a ☠ version. Then you pick a point in between the two, and test to see if it's ☺ or ☠. After you've done that, you've moved the two closer together, so your search space is smaller.
[http://www.st.cs.uni-saarland.de/dd/ Delta Debugging], AKA
 
[[wikipedia:Divide_and_conquer_algorithm|Divide and
 
Conquer]].
 
   
When you do bisect, you have to start with a version and a verision. Then
+
When you are debugging, you have your "☠" version automatically, because you've got something that's not working currently.
you pick a point in between the two, and test to see if it's ☺ or ☠. After
 
you've done that, you've moved the two closer together, so your search space
 
is smaller.
 
   
+
An important test in Vim is to use <code>vim -u NONE</code> (which skips almost all of the startup sequence) to see if the problem reproduces there or not.
When you are debugging, you have your "☠" version automatically, because
 
you've got something that's not working currently.
 
 
An important test in vim is to use <code>vim -u NONE</code> (which skips almost all of
 
the startup sequence) to see if the problem reproduces there or not.
 
   
 
Generally it will not.
 
Generally it will not.
   
* If debugging a <code>.gvimrc</code> problem, you might want to try<code>gvim -U NONE</code> after
+
* If debugging a <code>.gvimrc</code> problem, you might want to try<code>gvim -U NONE</code> after you determine the status of the lower-cased version.
you determine the status of the lower-cased version.
 
 
* Try <code>vim -u NORC</code> to see if loading plugins but not rc-files works.
 
* Try <code>vim -u NORC</code> to see if loading plugins but not rc-files works.
 
* Try <code>vim --noplugin</code> to see if loading rc-files but not plugins works.
 
* Try <code>vim --noplugin</code> to see if loading rc-files but not plugins works.
   
 
Then the next step is a bit of a mess.
 
Then the next step is a bit of a mess.
+
#vim's bairui has a plan for a script, [https://rubygems.org/gems/bisectly bisectly], that will help you with it, but at the moment his batsuit is at the batdrycleaners, so we're batwaiting with bated batbreath.
#vim's bairui has a plan for a script, [https://rubygems.org/gems/bisectly bisectly], that will help you with it, but at the moment his batsuit is at the
 
batdrycleaners, so we're batwaiting with bated batbreath.
 
 
   
 
In the mean-time, what you can do is:
 
In the mean-time, what you can do is:
+
<pre>
mv ~/.vimrc ~/.vim /tmp && mkdir ~/.vim
+
mv ~/.vimrc ~/.vim /tmp && mkdir ~/.vim
+
</pre>
   
 
Then do:
 
Then do:
  +
<pre>
  +
mv /tmp/.vimrc ~ && vim
  +
</pre>
   
mv /tmp/.vimrc ~ && vim
+
And test the behavior again. (Note that tools like Pathogen and the Vim-Addon-Manager will complicate this first step a bit). If the problem reappears descend into your ~/.vimrc and comment out half of it (with something like 50%:.,$s/^/" ) and find the section that is causing the problem.
 
And test the behavior again. (Note that tools like Pathogen and the Vim-Addon-Manager will complicate this first step a bit). If the problem reappears descend into your
 
~/.vimrc and comment out half of it (with something like 50%:.,$s/^/" ) and
 
find the section that is causing the problem.
 
   
 
If it doesn't reappear, then move one of the pieces of <code>/tmp/.vim/*</code> back into <code>~/.vim/</code> and try again.
 
If it doesn't reappear, then move one of the pieces of <code>/tmp/.vim/*</code> back into <code>~/.vim/</code> and try again.

Latest revision as of 08:00, January 12, 2013

Proposed tip Please edit this page to improve it, or add your comments below (do not use the discussion page).

Please use new tips to discuss whether this page should be a permanent tip, or whether it should be merged to an existing tip.
created September 12, 2012 · complexity basic · author Ryanking · version 7.0

Debugging Vim problems is a classic example of working with a system that is often too complex to sit back, stroke your beard, and reason your way through. Perhaps it is the "Hello World" of this class of problems?

So learn about bisecting, aka Binary Chop, aka Delta Debugging, aka Divide and Conquer.

When you do bisect, you have to start with a ☺ version and a ☠ version. Then you pick a point in between the two, and test to see if it's ☺ or ☠. After you've done that, you've moved the two closer together, so your search space is smaller.

When you are debugging, you have your "☠" version automatically, because you've got something that's not working currently.

An important test in Vim is to use vim -u NONE (which skips almost all of the startup sequence) to see if the problem reproduces there or not.

Generally it will not.

  • If debugging a .gvimrc problem, you might want to trygvim -U NONE after you determine the status of the lower-cased version.
  • Try vim -u NORC to see if loading plugins but not rc-files works.
  • Try vim --noplugin to see if loading rc-files but not plugins works.

Then the next step is a bit of a mess.

  1. vim's bairui has a plan for a script, bisectly, that will help you with it, but at the moment his batsuit is at the batdrycleaners, so we're batwaiting with bated batbreath.

In the mean-time, what you can do is:

mv ~/.vimrc ~/.vim /tmp && mkdir ~/.vim

Then do:

mv /tmp/.vimrc ~ && vim

And test the behavior again. (Note that tools like Pathogen and the Vim-Addon-Manager will complicate this first step a bit). If the problem reappears descend into your ~/.vimrc and comment out half of it (with something like 50%:.,$s/^/" ) and find the section that is causing the problem.

If it doesn't reappear, then move one of the pieces of /tmp/.vim/* back into ~/.vim/ and try again.

Keep doing this until you find the source of your problem.

See alsoEdit

CommentsEdit

Around Wikia's network

Random Wiki