'gq' not working as expected in Vim 7.3

[Trey Sizemore]

This was previously working well, but is no longer. I use vim (v7.3)
on my Mac and as my editor on mutt.

Now when I use 'gqG' or 'gq}' when replying to a message in mutt, it
no longer respects the reply '>' characters and wraps everything in
one big glob when I'm just trying to wrap excessively long lines.

Below is my .vimrc file content:


" We use a vim
set nocompatible
set paste
"
" Colo(u)red or not colo(u)red
" If you want color you should set this to true
"
let color = "true"
"
if has ("syntax")
if color == "true"
" This will switch colors ON
so ${VIMRUNTIME}/syntax/syntax.vim
else
" this switches colors OFF
syntax off
set t_Co=0
endif
endif
"set textwidth=75
set autoindent
set tabstop=8
set expandtab
set shiftwidth=4
filetype indent on
"The below is something recently added
"set comments=s1:/*,mb:*,ex:*/,://,b:#,:%,:XCOMM,n:>,fb:-
"set comments=n:>,n:\|
set comments=nb:>

"macro for stripping signatures from mails in mutt
map _qs G?^><CR>?^> -- $<CR>d}
"
" -------------------------------------------
" Commands for quoting URLs in emails
" Copyright (c) 2001-2004 Hugo Haas
" 2004-06-01 version
" I hereby put this code in the public domain.
" Documentation at: http://larve.net/people/hugo/2001/02/email-uri-refs/
" --------------------------------------------

" Insert a reference at the cursor position
function InsertRef() abort
let l:ref = input("Reference: ")
call AskNumber()
set paste
if (col(".") == 1)
execute "normal i[\<C-R>r]\<ESC>"
else
execute "normal a[\<C-R>r]\<ESC>"
endif
normal G
?^-- $
execute "normal O " . @r . ". " . ref . "\<ESC>`rf]"
set nopaste
let l:a = col(".")
normal $
let l:b = col(".")
if ( l:a == l:b )
startinsert!
else
normal `rf]l
startinsert
endif
endfunction

" Convert <http://example.com> into a reference
function ConvertToRef() abort
call AskNumber()
set paste
execute "normal cf>[\<C-R>r]\<ESC>G"
?^-- $
execute "normal O \<ESC>"
execute "normal a\<C-R>r. \<ESC>px0f.2 x`r"
set nopaste
endfunction

" Ask a reference number
function AskNumber() abort
if !exists("b:refNumber")
let b:refNumber = 0
call FindRefHiNumber()
endif
let b:refNumber = b:refNumber + 1
let l:number = input("Reference number (" . b:refNumber . "): ")
if ( l:number != "" )
let b:refNumber = l:number
endif
let @r = b:refNumber
endfunction

" Find the highest number in the text
function FindRefHiNumber() abort
normal 1G
/^$
let l:body = line(".")
let l:cur = l:body + 1
let l:found = 0
let @/="\\[[0-9]\\+\\]"
while ( l:cur <= line("$") )
if (match(getline(l:cur), @/) != -1)
let l:found = 1
break
endif
let l:cur = l:cur + 1
endwhile
if ( l:found == 0 )
let b:refNumber = 0
normal `r
return
endif
" Find the highest number
normal n
let l:l = line(".")
let l:c = col(".")
while (1)
if ( line(".") > l:body )
normal f]mqF[ly`qf]
if ((@0 + 0) > b:refNumber)
let b:refNumber = @0
endif
normal n
endif
if ( (line(".") < l:body) || ((l:l == line(".")) && (l:c == col("."))) )
break
endif
endwhile
normal `r
endfunction

imap <F5> <ESC>mr:call InsertRef()<CR>
nmap <F6> F<mr:call ConvertToRef()<CR>

nnoremap y "+y

" ~/.vimrc ends here


Any help is greatly appreciated!

[Ben Fritz]

On Monday, June 11, 2012 1:32:58 PM UTC-5, Trey Sizemore wrote:
> This was previously working well, but is no longer. I use vim (v7.3)
> on my Mac and as my editor on mutt.
>
> Now when I use 'gqG' or 'gq}' when replying to a message in mutt, it
> no longer respects the reply '>' characters and wraps everything in
> one big glob when I'm just trying to wrap excessively long lines.
>

What is your full Vim version? I.e. can you copy-paste the output of the :version command? There have been over 500 version updates since the initial 7.3 release.

What did you do just before noticing that it had stopped working? Install a new plugin? Upgrade Vim? Unknown?

[Ben Fritz]

And can you explain (with some example text) what you mean by "wraps everything in one big glob"? Please show how you expected Vim to format the text, and how it actually formatted the text.

[Christian Brabandt]

Hi Trey!

On Mo, 11 Jun 2012, Trey Sizemore wrote:

> This was previously working well, but is no longer. I use vim (v7.3)
> on my Mac and as my editor on mutt.
>
> Now when I use 'gqG' or 'gq}' when replying to a message in mutt, it
> no longer respects the reply '>' characters and wraps everything in
> one big glob when I'm just trying to wrap excessively long lines.

please show us the output of :verbose :set fo? ft?

The 'fo' option should include the 'c' and also the 'q' flag. See
:h fo-table for the description of each flag.

The simplest solution should be to make sure your .vimrc contains a line
like:
filetype plugin on

and then create a file like ~/.vim/after/ftplugin/mail.vim (create
directories that don't exist yet) and add the line:
setlocal fo+=tcq

to it. That should work.


regards,
Christian
--
Die Zeit ist schlecht? Wohlan! Du bist da, sie besser zu machen.
-- Thomas Carlyle

[Trey Sizemore]

Here is the output of :version

:version
VIM - Vi IMproved 7.3 (2010 Aug 15, compiled Jun 24 2011 20:00:09)
Compiled by ro...@apple.com
Normal version without GUI. Features included (+) or not (-):
-arabic +autocmd -balloon_eval -browse +builtin_terms +byte_offset
+cindent -clientserver -clipboard +cmdline_compl +cmdline_hist
+cmdline_info +comments -conceal +cryptv +cscope +cursorbind
+cursorshape +dialog_con +diff +digraphs -dnd -ebcdic -emacs_tags
+eval +ex_extra +extra_search -farsi +file_in_path
+find_in_path +float +folding -footer +fork() -gettext -hangul_input
+iconv +insert_expand +jumplist -keymap -langmap +libcall +linebreak
+lispindent +listcmds +localmap -lua +menu +mksession +modify_fname
+mouse -mouseshape -mouse_dec -mouse_gpm -mouse_jsbterm -mouse_netterm
-mouse_sysmouse +mouse_xterm +multi_byte
+multi_lang -mzscheme +netbeans_intg -osfiletype +path_extra -perl
+persistent_undo +postscript +printer -profile -python -python3
+quickfix +reltime -rightleft -ruby +scrollbind +signs +smartindent
-sniff +startuptime +statusline -sun_workshop +syntax +tag_binary
+tag_old_static -tag_any_white -tcl +terminfo
+termresponse +textobjects +title -toolbar +user_commands +vertsplit
+virtualedit +visual +visualextra +viminfo +vreplace +wildignore
+wildmenu +windows +writebackup -X11 -xfontset -xim -xsmp
-xterm_clipboard -xterm_save
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
user exrc file: "$HOME/.exrc"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -D_FORTIFY_SOURCE=0 -Iproto -DHAVE_CONFIG_H
-arch i386 -arch x86_64 -g -Os -pipe
Linking: gcc -arch i386 -arch x86_64 -o vim -lncurses


And :verbose :set fo? ft? results in:

formatoptions=tcq
Last set from ~/.vimrc
filetype=

As an example, if i take the following snippet from a mail with a long
line in it:

> I have googled and see that with Vim as the editor, 'gq' is likely what
> I want, but reading the help on this I'm still not sure how to
> invoke/use it.

Take a try with this line. First reply to this email, move the cursor
to this line an press consecutively Vgq. V select the whole line while
gq wraps it.

> Ideally, it would be nice to have the lines in the original e-mail that
> are too long to automatically be wrapped in the reply when I hit 'r'.


If I then use 'Vgq' I get this:

> > I have googled and see that with Vim as the editor, 'gq' is likely what
> > I want, but reading the help on this I'm still not sure how to
> > invoke/use it.
>
> Take a try with this line. First reply to this email, move the cursor
to this line an press consecutively Vgq. V select the whole line while
gq wraps it.
>
> > Ideally, it would be nice to have the lines in the original e-mail that
> > are too long to automatically be wrapped in the reply when I hit 'r'.


Notice how it doesn't preface the wrapped lines with > so that the
e-mail response looks as it should. It *did* used to do this, but not
sure what might have changed recently to cause it to stop working.

Thanks for any guidance!

[Christian Brabandt]

On Mon, June 11, 2012 22:33, Trey Sizemore wrote:
> Notice how it doesn't preface the wrapped lines with > so that the
> e-mail response looks as it should. It *did* used to do this, but not
> sure what might have changed recently to cause it to stop working.
>
> Thanks for any guidance!

Please read again my mail, to which you replied.

regards,
Christian

[Trey Sizemore]

Thanks Christian. Following the steps you mentioned above results in
the same behavior (or mis behavior) of vim when using the 'gq'
variations on mails with long lines.

Not sure what is going on!

[Trey Sizemore]

OK. Getting closer to the issue maybe. I noticed that the lines I
have in my .vimrc for citing references using the F5 key are not being
sourced. In other words, I was previously able to type a message in
mutt (with vim as editor) and hit F5 to bring up a line to enter the
website and then it would increment a reference number (starting with
1, then 2…).

Now hitting the F5 key in an e-mail only inserts '<F5>' in the message.

Any ideas why the .vimrc is not being read?

Thanks!

[Trey Sizemore]

OK, I had recently added a line in my .vimrc (set paste) for pasting
external contents into vim while maintaining formatting. It worked
great, but was hosing up the aforementioned pieces as editor for mutt.
Commenting out that line returned expected behavior.

So for pasting things into vim from now on, should I just invoke 'set
paste' before pasting and leave the entry out of my .vimrc?

Thanks.

[Bee]

> OK, I had recently added a line in my .vimrc (set paste) for pasting
> external contents into vim while maintaining formatting.  It worked
> great, but was hosing up the aforementioned pieces as editor for mutt.
>  Commenting out that line returned expected behavior.
>
> So for pasting things into vim from now on, should I just invoke 'set
> paste' before pasting and leave the entry out of my .vimrc?

set pastetoggle=<F11>

:help pastetoggle

Bill

[Ben Fritz]

On Tuesday, June 12, 2012 9:56:24 AM UTC-5, Trey Sizemore wrote:
>
> OK, I had recently added a line in my .vimrc (set paste) for pasting
> external contents into vim while maintaining formatting. It worked
> great, but was hosing up the aforementioned pieces as editor for mutt.
> Commenting out that line returned expected behavior.
>
> So for pasting things into vim from now on, should I just invoke 'set
> paste' before pasting and leave the entry out of my .vimrc?
>
> Thanks.

From :help 'paste':

When the 'paste' option is switched on (also when it was already on):
- mapping in Insert mode and Command-line mode is disabled
- abbreviations are disabled
- 'textwidth' is set to 0
- 'wrapmargin' is set to 0
- 'autoindent' is reset
- 'smartindent' is reset
- 'softtabstop' is set to 0
- 'revins' is reset
- 'ruler' is reset
- 'showmatch' is reset
- 'formatoptions' is used like it is empty

Moral of the story: always read the :help on an option before you mess with its default setting.

'paste' in general, as you now suspect, is meant to be set only temporarily.

[Trey Sizemore]

Lesson learned ;-)

[Trey Sizemore]

That works perfectly! Thanks!