How to set vimrc for automatic retab and gggqG
Girish Venkatasubramanian
I decided to make me a nice vimrc file. But I am stuck at two spots
and will appreciate any advice/tips on how to get these working.
1) Automatic retab (What I would like to do is to automatically retab
every file that I open). Initially, I had
if has("autocmd")
au BufReadPost * retab
endif
but this complained when I was opening unmodifiable buffers like
"help:retab". Then I changed this to
if &modifiable
if has("autocmd")
au BufReadPost * retab
endif
endif
but still executing "help:retab" complains about
Error detected while processing BufRead Auto commands for "*":
E21: Cannot make changes, 'modifiable' is off: retab
I am currently working around this by asking vimrc to retab only
specific types of files like *c, *cpp etc
2) I can reformat the entire document according to my formatoptions by
gggq<Shift+g>. Is there any way I can do this from vimrc instead of
manually typing n the command every time I open a file?
Thanks.
John Little
wrote:
> 1) Automatic retab ...
> if &modifiable
> if has("autocmd")
> au BufReadPost * retab
> endif
> endif
>
> but still executing "help:retab" complains...
You're testing modifiable at start up, you want to test it when the
auto command fires. Perhaps something like
if has("autocmd")
au BufReadPost * if &modifiable | retab | endif
endif
BTW, it's a good idea to put auto commands in a group. See :help
autocmd-groups
> 2) I can reformat the entire document according to my formatoptions by
> gggq<Shift+g>.
Try the normal command, it lets you do what you would type:
normal gggqG
in vim script is exactly like typing that in normal mode, hence its
name.
Regards, John
Girish Venkatasubramanian
I have another question, though.
I decided against setting a textwidth and formatoptions and au normal
gqG because of a couple of issues (see below). I am letting wordwrap
render the file according to the width of the terminal in which it is
opened. This works fine, except that one paragraph is considered to be
one line and "j" scrolls down by an entire paragraph and not a virtual
(or rendered) line.
To help this, I am considering mapping j and k (or the arrow keys) to
gj and gk so that the scrolling happens from one line to the next
virtual line and not from to the next actual line.
1) My first choice is remapping the arrow keys? Is this a bad idea?
Should I rempa only for specific modes?
2) If not, how do i remap the arrow keys? I mean in the "map key
mapped_key" command, how do I represent the right arrow in the place
of key?
Issues with tw 80 and fo=crqa
-------------------------------------------
1) When textwdith iss set to 80 and I have two lines of code like
//This is a comment; This is a comment This is a comment
printf("Hello, World\n");
commenting out the printf with a // gives me
//This is a comment; This is a comment This is a comment printf("Hello, World\n"
//);
which seems quite ugly
2) When the file being opened is not a C file, but some document, and
I have a paragraph like
Introduction
This is a comment.
This is another comment
gq on this paragraph gives me
Introduction This is a comment. This is another comment
Is there a better setting for fo?
Thanks
> --
> You received this message from the "vim_use" maillist.
> For more information, visit http://www.vim.org/maillist.php
Matt Wozniski
> Thanks John - that took care of the retab issue.
>
> I have another question, though.
>
> I decided against setting a textwidth and formatoptions and au normal
> gqG because of a couple of issues (see below). I am letting wordwrap
> render the file according to the width of the terminal in which it is
> opened. This works fine, except that one paragraph is considered to be
> one line and "j" scrolls down by an entire paragraph and not a virtual
> (or rendered) line.
>
> To help this, I am considering mapping j and k (or the arrow keys) to
> gj and gk so that the scrolling happens from one line to the next
> virtual line and not from to the next actual line.
> 1) My first choice is remapping the arrow keys? Is this a bad idea?
> Should I rempa only for specific modes?
I think it's perfectly reasonable to map the arrow keys to do
something slightly different than j/k. Obviously, you'd only want
that remap in normal, visual, and operator-pending modes, though. You
don't want pressing <Down> in insert mode to insert "gj" into the
buffer at the cursor. So, the command would be
:noremap <Down> gj
:noremap <Up> gk
> 2) If not, how do i remap the arrow keys? I mean in the "map key
> mapped_key" command, how do I represent the right arrow in the place
> of key?
See above.
> Issues with tw 80 and fo=crqa
> -------------------------------------------
> 1) When textwdith iss set to 80 and I have two lines of code like
> //This is a comment; This is a comment This is a comment
> printf("Hello, World\n");
>
> commenting out the printf with a // gives me
> //This is a comment; This is a comment This is a comment printf("Hello, World\n"
> //);
> which seems quite ugly
There's not really any way for this to differentiate between commented
out code and "real" comments, though. It makes sense that it blends
them together.
> 2) When the file being opened is not a C file, but some document, and
> I have a paragraph like
>
> Introduction
> This is a comment.
> This is another comment
>
> gq on this paragraph gives me
>
> Introduction This is a comment. This is another comment
>
> Is there a better setting for fo?
I'm not sure what the problem with this is? That sounds like exactly
what gq is supposed to do.
> Thanks
>
> On Sat, Feb 6, 2010 at 4:28 AM, John Little <john.b...@gmail.com> wrote:
>> On Feb 6, 2:25 pm, Girish Venkatasubramanian <giris...@gmail.com>
*snip*
In the future, please bottom post on this mailing list; it's list policy.
~Matt
Girish
On Feb 6, 3:55 pm, Matt Wozniski <m...@drexel.edu> wrote:
> On Sat, Feb 6, 2010 at 1:50 PM, Girish Venkatasubramanian wrote:
*snip*
> > To help this, I am considering mapping j and k (or the arrow keys) to
> > gj and gk so that the scrolling happens from one line to the next
> > virtual line and not from to the next actual line.
> > 1) My first choice is remapping the arrow keys? Is this a bad idea?
> > Should I rempa only for specific modes?
>
> I think it's perfectly reasonable to map the arrow keys to do
> something slightly different than j/k. Obviously, you'd only want
> that remap in normal, visual, and operator-pending modes, though. You
> don't want pressing <Down> in insert mode to insert "gj" into the
> buffer at the cursor. So, the command would be
>
> :noremap <Down> gj
> :noremap <Up> gk
Thanks. Those did the trick
>
*snip*
> I'm not sure what the problem with this is? That sounds like exactly
> what gq is supposed to do.
I should have explained this a little better. I do realize that this
is fo and gq's behavior. What I would like to happen on gq is
Introduction
This is a comment. This is another comment
But I realize that is asking a bit too much. I cant expect Vim to
distinguish between carriage returns depending on what *I feel* should
happen. Same way, I cant expect vim to distinguish between comments
and commented out code, as you rightly point out. So let me rephrase
these *problems* as features that I tried out but did not like very
much. It may even be an issue of my not being used to this feature and
it may take some time to understand and appreciate it.
*snip*
> In the future, please bottom post on this mailing list; it's list policy.
Will do that. Thanks for letting me know about the policy.
>
> ~Matt
Michael Henry
> On Sat, Feb 6, 2010 at 1:50 PM, Girish Venkatasubramanian wrote:
>> Issues with tw 80 and fo=crqa
>> -------------------------------------------
>> 1) When textwdith iss set to 80 and I have two lines of code like
>> //This is a comment; This is a comment This is a comment
>> printf("Hello, World\n");
>>
>> commenting out the printf with a // gives me
>> //This is a comment; This is a comment This is a comment
printf("Hello, World\n"
>> //);
>> which seems quite ugly
>
> There's not really any way for this to differentiate between commented
> out code and "real" comments, though. It makes sense that it blends
> them together.
This is one reason I prefer to use ``#if 0 / #endif`` instead of
comments to compile out code. Instead of doing this:
// printf("Hello, World\n");
I do this:
#if 0
printf("Hello, World\n");
#endif
It has several other advantages:
- It clearly groups the section of code that's being removed,
and distinguishes that code from "regular" comments.
- It's easy to toggle the code in and out by changing the ``0``.
- Using C-style comments (/* like this */) to compile out code
doesn't nest well with other C-style comments embedded in the
code; using C++-style comments is not portable to all C
compilers and requires modifying every line in the group. By
comparison, ``#if 0 / #endif`` nests well and requires
modification only at both ends of the code group.
- It's useful for trying out new code, like this:
#if 0
oldCode();
wouldBeHere();
#else
newCode();
replacingAboveOldCode();
#endif
You can retain the original code while you work on refactoring
it into new code. At any time, you can easily switch back to
the old code for testing.
- When there are multiple sections of code that must be compiled
out all together or not at all during testing, it's easy to
add a new #define to control the sections together:
#define USING_OLD_CODE 0
#if USING_OLD_CODE
someOldCode();
#endif
/* ... */
#if USING_OLD_CODE
moreOldCode();
#else
withPossibleNewCode();
#endif
Michael Henry
Ben Fritz
On Feb 6, 2:55 pm, Matt Wozniski <m...@drexel.edu> wrote:
> On Sat, Feb 6, 2010 at 1:50 PM, Girish Venkatasubramanian wrote:
>
> I think it's perfectly reasonable to map the arrow keys to do
> something slightly different than j/k. Obviously, you'd only want
> that remap in normal, visual, and operator-pending modes, though. You
> don't want pressing <Down> in insert mode to insert "gj" into the
> buffer at the cursor. So, the command would be
>
> :noremap <Down> gj
> :noremap <Up> gk
>
If you want the same behavior in Insert mode, you could still get it
with:
:inoremap <Down> <C-O>gj
:inoremap <Up> <C-O>gk
The <C-O> is to leave insert mode and perform a single normal mode
command, returning to insert mode when done.
Tony Mechelynck
An answer has been given, but what you're requesting here makes me
shudder: except for 'nomodifiable' files, but for all other files
including 'readonly' ones (either because the medium is readonly, or the
file has readonly attributes, or even because you opened it with :view
rather than :edit for the exact purpose of _not_ changing it) the first
thing that Vim will do, without asking for confirmation, is modify the
files by changing tabs to spaces or vice-versa, and even reformatting
the text, and that all over the place! When I use Vim to examine its own
sources (for example), I don't want it to change any file one single bit
without my positive, explicit and specific say-so (which I don't "say"
very often), and even if I do change a bit of code here or there to test
a proposed bugfix, I wouldn't dream to meddle with Bram's coding style
at the risk of making all future patches fail (because they are based on
whatever there used to be, and are unaware of any "reformatting").
One slightly better solution (than the answer you got) would be to write
the autocommand as (for example)
:au BufReadPost * if &ma && ! &ro | DoSomething | endif
but IMHO it would really be better to have no automatic action at all,
but, let's say,
:map <F6> :retab<CR>
:map <S-F6> gggqG
(or vice-versa if you think you reformat oftener than retab, or any
other {lhs} that strikes your fancy) so Vim would not clobber each and
every file that it opens, but you're still only one keypress away from
your favourite reformatting when you _really_ want it.
Best regards,
Tony.
--
"... the Mayo Clinic, named after its founder, Dr. Ted Clinic ..."
-- Dave Barry