tags:

views:

467

answers:

3

I know there must be something obvious I'm missing, but I can't stop vim from wrapping my python code. I enter :set nowrap like a champ, but still it wraps. I can hit J to unite the split lines of code, so it seems like a real carriage return is being inserted, I just don't understand why or how to stop it.

A: 

Vim may have to be in vi-compatible mode.

mcandre
+10  A: 
'textwidth' 'tw'        number  (default 0)
                        local to buffer
                        {not in Vi}
        Maximum width of text that is being inserted.  A longer line will be
        broken after white space to get this width.  A zero value disables
        this.  'textwidth' is set to 0 when the 'paste' option is set.  When
        'textwidth' is zero, 'wrapmargin' may be used.  See also
        'formatoptions' and |ins-textwidth|.
        When 'formatexpr' is set it will be used to break the line.
        NOTE: This option is set to 0 when 'compatible' is set.


'wrapmargin' 'wm'       number  (default 0) 
                        local to buffer
        Number of characters from the right window border where wrapping
        starts.  When typing text beyond this limit, an <EOL> will be inserted
        and inserting continues on the next line.
        Options that add a margin, such as 'number' and 'foldcolumn', cause
        the text width to be further reduced.  This is Vi compatible.
        When 'textwidth' is non-zero, this option is not used. 
        See also 'formatoptions' and |ins-textwidth|.  {Vi: works differently
        and less usefully}

If you refer to auto wrapping of long lines sending them to the next one, try

:set textwidth=0 
:set wrapmargin=0
Stefano Borini
works for me. Thanks!
David Berger
+1  A: 

Maybe it's the textwidth that's set, which automatically breaks lines when it reaches a certain length Try

:set tw=0

If that fails play with e.g.

:set wrap linebreak textwidth=0

and

:set virtualedit=insert
nos
wrap and linebreak don't insert actual end-of-lines into the buffer, so that doesn't seem to be his problem.
A. Levy