On 16/07/08 00:57, smu johnson wrote:
> Dear Vim Devel Mailing list,
>
> Some suggestions for Vim IMprovement.
>
> 1. When using the % alias as the file you are editing... you are able to
> do things like: :!echo % in vi to show you the path and file of what you
> are currently editing. But, this will not give you the absolute path of
> things. if you're in your home directory and type "vi .vimrc" then do
> the echo thing, it's "full path" will be ./.vimrc instead of
> /usr/home/ronnie/.vimrc or whatever. How about a fullpath alias
> something other than %? Or maybe a .vimrc flag to set that % to mean its
> absolute path, etc.
See ":help filename-modifiers"
Use %:p to get the name with full path.
>
> A quick workaround in Perl until this is maybe fixed for anyone interested:
>
> #!/usr/bin/perl
>
> use strict;
> use Cwd qw(realpath);
>
> my $in_path = $ARGV[0];
>
> if ( ! $in_path) {
> $in_path = '.';
> }
>
> if ( -e $in_path ) {
> print realpath($in_path);
> print "\n";
> }
>
> Interface that with Vim and you should be okay for a while...
>
> 2. Annoyance: When you use the % key in Vim to go to the matching
> bracket on the cursor, it takes into account commented out brackets that
> vim clearly knows are commented out due to the syntax highlighting. If
> it could ignore these brackets then life would be grant! Perhaps it's a
> togglable flag already? I don't know... On the other side of the coin,
> if you are pressing % on a commented comment, maybe it would go to its
> other bracket commented counterpart.
Make sure you have matchit installed. You can do it by adding a file
named (on Unix) ~/.vim/plugin/matchit.txt or (on Windows)
$HOME/vimfiles/plugin/matchit.txt (create the directories if they don't
exist) with the single-line contents
runtime macros/matchit.vim
You should also install the matchit help as follows:
1. Copy $VIMRUNTIME/macros/matchit.txt to (Unix) ~/.vim/doc/ or
(Windows) $HOME/vimfiles/doc/ (or create the corresponding softlink on Unix)
2. In Vim, execute
on Windows:
:helptags ~/vimfiles/doc
or on Unix:
:helptags ~/.vim/doc
to create the corresponding help index. Once matchit is installed as
above, ":help matchit.txt" will tell you what it can do. It extends %
matching in several ways, and by default it will not jump from outside
to inside a comment or vice-versa.
>
> 3. Perl's =cut pod comments work half the time in Vim's syntax
> highlighting. You have to hit pgup and pgdown quickly to "jerk" the
> syntax highligting color into shape. Usually when the problem occurs, it
> comments the rest of the entire text till EOF after the start of the
> first =cut comment.
try synchronizing the syntax for a longer distance
:help :syn-sync
>
> 4. Somehow a toggle option so that when you exit out of insert mode, it
> doesn't automatically move the cursor to the left. Press i, esc, i, esc,
> etc etc to see what I mean. Obviously, it was meant for a reason and
> it's not a bug, but I believe I could get used to Vim much better
> without that behaviour. If you could toggle it...
Train yourself to get _into_ insert mode by using a rather than i. Then
you will insert _after_ where you were when in Normal mode, and go back
to on the latest inserted character when hitting <Esc>. Hitting a then
<Esc> will return the cursor to where it was, even if at the start or
end of a line.
>
> 5. Ever used Vim in a putty window, and pasted a giant section of code
> after hitting insert when you accidently left "auto-indent" on? The
> pasted text is all screwed up cause of the tabs and such. Of course, you
> have to hit undo, toggle the auto-indent, then repaste it. But I make
> this mistake so often... that maybe it could have an intelligent input
> buffering system that can tell how fast you're typing and it knows right
> away that you're pasting text, and to turn off the auto-indent (if you
> tell your .vimrc to do so)? This one is a long shot, but I believe this
> would make a lot of programmers happy. My coworkers agree with me on
> this one.
Try ":set paste" just before you paste, then ":set nopaste" afterwards.
>
> Just throwing those out there. Any comments? Thanks
>
Best regards,
Tony.
--
The past always looks better than it was. It's only pleasant because
it isn't here.
-- Finley Peter Dunne (Mr. Dooley)
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---
