Since this is a list for vim users, not emacs users, no one here is
likely to know how ALT-Q works at all, much less the difference that
makes it work better that gq in vim.
What behavior are you looking for?
Regards,
Gary
I'm not quite sure what you're going for. Vim allows you to wrap
the current line at whatever 'textwidth' is set to using
"gq<motion>" which can indeed be mapped to meta+Q/alt+Q like
:nnoremap <m-q> gqq
or
:nnoremap <m-q> gqip
However, you mention
> Unfortunately the gq (arrow) in vim doesn't work so well.
without offering a lot of details as to *why* it doesn't work
well. Do you have some plugin interfering with the gq<motion>
behavior? Is it working as described, but not what you want? Do
you want soft-wrapping (just visually, not actually inserting the
line-breaks) or hard-wrapping (inserting line-breaks)?
With further details, it's likely Vim can be made to operate the
way you want, but you'll need to give details on how that works
(the "like Emacs" doesn't help the non-emacs users on the list --
such as myself -- help you).
-tim
map x mx{gq}`x
This marks position (in register x) -> formats current paragraph -> returns
to the marked position.
-ap
The example is great. Thanks. Now for the bad news. I don't think
there's a way for vim to do that, short of a plugin that implements
such a formatting algorithm.
Vim distinguishes between formatting (see the 'formatprg' option and
the gq and related commands) and indenting (see the 'indentexpr' and
'equalprg' options and the = and related commands). This allows the
user to re-indent lines of code without redistributing the code
among the lines, and allows the user to "reformat" comments in the
sense of redistributing the words among lines while keeping the
comment leaders intact. However, vim does not reformat code the way
that the 'indent' program does, for example.
Regards,
Gary
-ap
> On Jun 21, 10:45 pm, Gary Johnson <garyj...@spk.agilent.com> wrote:
> > On 2008-06-21, drososkourou...@gmail.com wrote:
> > > No, it works but if you try it on the following comments it wraps the
> > > if statement as well. Try to create a file named filename.cpp and copy
> > > there the following code. Then go to // we can push here the common
> > > facet e.t.c. and type ESC-x. You will see that the if statement is
> > > wrapped as well.
[...]
> > The example is great. Thanks. Now for the bad news. I don't think
> > there's a way for vim to do that, short of a plugin that implements
> > such a formatting algorithm.
> >
> > Vim distinguishes between formatting (see the 'formatprg' option and
> > the gq and related commands) and indenting (see the 'indentexpr' and
> > 'equalprg' options and the = and related commands). This allows the
> > user to re-indent lines of code without redistributing the code
> > among the lines, and allows the user to "reformat" comments in the
> > sense of redistributing the words among lines while keeping the
> > comment leaders intact. However, vim does not reformat code the way
> > that the 'indent' program does, for example.
> Is it hard to implement such a feature? Or write a vim script which
> does exactly that?
I guess it depends on what you mean by "hard". Some people find
that sort of thing easy while others struggle, and then some find
even the struggle fun.
I don't think it would be too bad, depending how fancy you wanted to
get. The simplest solution would be to find some external program
such as 'indent' or 'fmt' that reformats code as you want. You
could then either assign its name to 'equalprg' or 'formatprg' and
invoke it with the gq or = commands, or create a simple mapping like
the following:
map <f4> vip!yourformatprog<CR>
which visually-selects the current paragraph, then executes
'yourformatprog' on the selected lines.
If there is no such external program, you could write one in the
language of your choice. Or you could write the algorithm in Perl,
Python or Ruby and use vim's interface to those interpreters to
execute it. (See :help on any of those languages.) You could also
write it completely in vim's scripting language, perhaps invoking
vim's built-in formatting and/or indenting commands on selected
portions of the region to be formatted.
Personally, I would write an external program in either C or Perl
simply because I am more familiar with those tools and could
implement the algorithm faster that way. I've done a little of that
in C and it's worked well. But that's just me.
I think the hard part is the algorithm. Once you have that figured
out, it depends on you how you want to implement it. As long as the
command behaves like a filter and doesn't reformat as you type, it
should be easy to integrate into vim.
Regards,
Gary
> I think ident is the best way to go but will it work for .tex
> files as well or only C,C++?
I don't know. You'll have to check the indent documentation.
You can specify different formatting commands for different
languages, so you could use 'indent' for C and C++ and something
else for TeX. There are some plugins already written for TeX that
have been contributed to the scripts at vim.sf.net. You might find
one that does reformatting.
Regards,
Gary
> and what is &fo?
The 'formatoptions' option.
:help 'fo'
:help let-&
Regards,
Gary
I think the problem you're seeing is discussed here:
:help map-alt-keys
To work around that problem, you can map the Alt-q key by typing
Ctrl-v followed by Alt-q instead of the characters <m-q> on the left
side of the mapping.
> The VIM help is not helpful at all although easier to understand than
> that of emacs which is a chaos. So in many cases I understand what to
> do but as it regards mapping a set of keys I am confused with all
> those different commands like: nnoremap, map, imap noremap e.t.c. Why
> do we need so many?
I find the vim help on mapping the most difficult to find and to
understand.
The different mapping commands are needed because there are
different contexts in which you may want to use a mapping and in
which you may want a different behavior for a particular lhs or you
may have to use a different sequence of commands to achieve a
particular behavior. Hence the need for map, nmap, imap, cmap,
vmap, etc.
Then in some cases you may want character sequences on the rhs to
trigger other mappings and in other cases you don't. Hence the need
for the nore prefix to inhibit remapping of the rhs.
> Besides what I really would like to have is the following:
>
> Suppose that I am editing a file filename.tex which is a .tex file. I
> would like to have the F5 key to run the command:
>
> latex filename.tex
>
> when I am editing though a C++ file lets call it filename.cpp I would
> like the F5 key to run the command
>
> make filename.o
>
> or
> cd src
> make filename.o
> cd ..
If you have filetype detection on (see ":help filetype.txt" and
":help usr_43.txt") you can define different mappings and other
settings to be applied only when editing certain file types.
Following your examples above, you can put this command,
map <buffer> <F5> :!latex %<CR>
in the file ~/.vim/after/ftplugin/tex.vim and put this command,
map <buffer> <F5> :make %<.o
in the file ~/.vim/after/ftplugin/cpp.vim. See also
:help map-<buffer>
:help :_%<
There are several ways to handle cd'ing to src before executing
make, in part depending on whether you want to execute ":!make" or
":make". One thing I've done is to define makeprg something like
this:
setlocal makeprg=cd\ src;make\ %:t:r.o
> I am not sure if make filename.o will work outside of src/ since I
> have a Makefile in src/ and I have to be in src/ to be able to write
> something "make filename.o".
>
> Any ideas?
You may also want to look at
:help latex
:help :make
:help quickfix.txt
for some ideas of how to use latex as a compiler within vim's make
system.
HTH,
Gary
As mapping related questions are asked a lot of times in this mailing
list over the years, I wrote the following three-part tutorial to describe
the various aspects of mappings keys in Vim:
http://vim.wikia.com/wiki/Mapping_keys_in_Vim_-_Tutorial_%28Part_1%29
If you have any suggestions on improving this tutorial, let me know.
- Yegappan
http://thread.gmane.org/gmane.editors.vim/66163
The original question was this:
drososk...@gmail.com wrote (2008-06-21 10:45 -0700):
> I am trying to find the vim command for the emacs Meta-Q (usually
> ALT- Q). This command wraps text at around 72 characters per line. It
> is very useful and nice to have in vim. Unfortunately the gq (arrow)
> in vim doesn't work so well. Does anybody of you know how to make that
> work in vim as well as ALT-Q works in emacs?
Later "drososkourounis" gave a bit more information:
drososk...@gmail.com wrote (2008-06-21 12:16 -0700):
> No, it works but if you try it on the following comments it wraps the
> if statement as well. Try to create a file named filename.cpp and copy
> there the following code. Then go to // we can push here the common
> facet e.t.c. and type ESC-x. You will see that the if statement is
> wrapped as well.
>
>
> if (foundnewboundaryelement)
> {
> // we can push here the common facet shared by
> // those elements and later we use that for
> // visualization purposes
> vElementsOnSubDomainBoundary.push_back(e);
> elementmarked[e] = true;
>
> if (dimension == 2)
> {
> boundaryfacet = elementedgeslist[3*e + i];
> vEdgesOnSubDomainBoundary.push_back(boundaryfacet);
>
> for (j = 0; j < 2; j++)
> {
> node = edgelist[2*boundaryfacet + j];
> if (!nodemarked[node])
> {
> vDofsOnSubDomainBoundary.push_back(node);
> nodemarked[node] = true;
> }
> }
> }
>
> Any ideas?
As Gary Johnson already noted, there is not direct equivalent of Emacs's
Meta-Q in Vim. I think the best Vim-way is to add "w" char to
'formatoptions' setting. I'd suggest you to create file
~/.vim/ftplugin/cpp.vim and add the following line to that file:
setlocal textwidth=78 formatoptions+=w
These settings combined with the default settings for *.cpp files cause
comments to be automatically wrapped at column 78 while writing. The "w"
char in 'formatoptions' means that a whitespace at the end of line
indicates that the paragraph continues in the next line. Formatting
commands like gqap only join lines which have whitespace at the end.
In the actual code file add a space char to every comment line except
the last one in the comment block. An example (the dollar sign indicates
the end of line here):
[some code here]
// we can push here the common facet shared by $
// those elements and later we use that for $
// visualization purposes$
[some code here]
(Such whitespaces are automatically added when you write new comments.)
Try formatting the comment with any of the gq or gw commands. Should
work nicely. I use similar setting with LaTeX files; actually I have
also "a" in 'formatoptions' (formatoptions+=aw) so that my text is
automatically formatted while typing (no need for gqap).