Five (5) new features request

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Five (5) new features request

smu johnson
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.

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.

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.

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...

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.

Just throwing those out there.  Any comments?  Thanks

--
smu johnson <[hidden email]>

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Ian Kelling

For 5. There is an option called 'paste'. I suggest you read about it,
and if you want, you could bind a key to something similar to :set
paste/<esc>"+p:set nopaste. I forget the exact syntax.

For 4, you can do something similar, like :inoremap <ESC> <ESC>l

I didn't test these things, but vim has great documentation to help
figure this stuff out. I suggest the first place you look is the user
manual, :he toc.

So, I looked at number 1, and figured out the answer also. Heres how
useful the help system is. :he %<ctrl-d>, hmm, modify it to :he :
%<enter> /full. Theres your answer.
--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Tony Mechelynck
In reply to this post by smu johnson

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
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

RE: Five (5) new features request

JohnBeckett
In reply to this post by smu johnson

smu johnson wrote:
> 3. Perl's =cut pod comments work half the time in Vim's
> syntax highlighting.

It's a compromise between performance and quality. Read:
  :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.

The standard answer is to forget about 'i' and to use 'a' instead.

> 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?

See for the recommended procedure:
http://vim.wikia.com/wiki/VimTip906

John


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Jens-Wolfhard Schicke-5
In reply to this post by Ian Kelling

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Ian Kelling wrote:
> For 5. There is an option called 'paste'. I suggest you read about it, and
> if you want, you could bind a key to something similar to
> :set paste/<esc>"+p:set nopaste. I forget the exact syntax.
Yes, but the point is still valid. I paste, then I find that I forgot to set
'paste', afterwards I forget to reset 'paste'.

I'd like to have an option 'autopaste' or whatever that assumes an insert at
above say 20 chars / second has been pasted.

The obvious problem here are slow terminals. I have typed ahead more than 20
characters on many occasions. Also the question is, how to determine the end
of the pasted text. In my opinion, the user must be sure that either the one
or the other behaviour has occured, it must not be the case that VIm decided
to treat only 90% of the pasted text as pasted, just because of the unevenly
slow terminal. I think the best option is to consider an insert action paste
or not-paste as a whole. This gives a clear boundary for the measurements. A
user might still find this a bit irritating, but I usually don't switch from
VIm terminals while in insert mode. Hence I usually do a separate insert for
each paste.

But I don't know how much timing is available in the VIm input system. And I
don't know how to handle the redrawing after the decision has been made. The
screen would usually show something during the insert operation itself, only
once the insert has been decided to be 'paste', this could be switched of. I
think the cost of just redrawing everything afterwards is probably ok, in an
insert which was pasted.

Jens
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIfUIrzhchXT4RR5ARArwuAKC+Kugv8EWKVhpYkkFywGu5UG6fWACdFnhQ
RMBUQSJlOiFc0sx32+StDSg=
=jdCr
-----END PGP SIGNATURE-----

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

François Ingelrest
In reply to this post by Ian Kelling

On Wed, Jul 16, 2008 at 01:10, Ian Kelling <[hidden email]> wrote:
> For 4, you can do something similar, like :inoremap <ESC> <ESC>l

I've been using something like that for some time:

inoremap <Esc> <Right><Esc>

This works in GVim but breaks extended keys in Vim (they send <Esc> as
the first keycode).

It seems that Vim doesn't wait a bit to see if another keycode
follows, but rather immediately applies the mapping. This does not
happen without the mapping, because in this case Vim correctly waits a
bit to see whether it's <Esc> or an extended keycode. Not sure whether
this a bug or something desirable though...

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Milan Vancura
In reply to this post by smu johnson

> 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

:h pastetoggle

Milan
--
Milan Vancura, Prague, Czech Republic, Europe

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Marc Haisenko-3

On Wednesday 16 July 2008, Milan Vancura wrote:
> > 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
> >
> :h pastetoggle
>
> Milan

"vim tip of the day" for me, thank you :-)
        Marc

--
Marc Haisenko

Comdasys AG
Rüdesheimer Str. 7
80686 München
Germany

Tel.: +49 (0)89 548 433 321

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Tony Mechelynck
In reply to this post by François Ingelrest

On 16/07/08 08:43, François Ingelrest wrote:

> On Wed, Jul 16, 2008 at 01:10, Ian Kelling<[hidden email]>  wrote:
>> For 4, you can do something similar, like :inoremap<ESC>  <ESC>l
>
> I've been using something like that for some time:
>
> inoremap<Esc>  <Right><Esc>
>
> This works in GVim but breaks extended keys in Vim (they send<Esc>  as
> the first keycode).
>
> It seems that Vim doesn't wait a bit to see if another keycode
> follows, but rather immediately applies the mapping. This does not
> happen without the mapping, because in this case Vim correctly waits a
> bit to see whether it's<Esc>  or an extended keycode. Not sure whether
> this a bug or something desirable though...

IIUC it is usually a side-effect of 'ttimeoutlen' being at its default
of -1 (wait just as long for keycodes as for mappings). With something like

        set timeout ttimeoutlen=100 timeoutlen=5000

keycodes will timeout after one-tenth of a second (fast for a human, but
usually quite lazy for a keyboard driver or a telecom line) while
mappings will only timeout after five seconds (which should be ample for
a human typist). Then if <Esc> is followed by something within one-tenth
of a second it is examined for a keycode, but after that it still counts
for a mapping.

If it still doesn't work, add

        inoremap   <Esc><Esc>  <Esc>

to force the full timeout (5s in my example) on the Esc key when not
part of a keycode.


Best regards,
Tony.
--
Never commit yourself!  Let someone else commit you.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

François Ingelrest

On Wed, Jul 16, 2008 at 16:57, Tony Mechelynck
<[hidden email]> wrote:

>> I've been using something like that for some time:
>>
>> inoremap<Esc>  <Right><Esc>
>>
>> This works in GVim but breaks extended keys in Vim (they send<Esc>  as
>> the first keycode).
>>
>> It seems that Vim doesn't wait a bit to see if another keycode
>> follows, but rather immediately applies the mapping. This does not
>> happen without the mapping, because in this case Vim correctly waits a
>> bit to see whether it's<Esc>  or an extended keycode. Not sure whether
>> this a bug or something desirable though...
>
> IIUC it is usually a side-effect of 'ttimeoutlen' being at its default
> of -1 (wait just as long for keycodes as for mappings). With something like
>
>        set timeout ttimeoutlen=100 timeoutlen=5000
>
> keycodes will timeout after one-tenth of a second (fast for a human, but
> usually quite lazy for a keyboard driver or a telecom line) while
> mappings will only timeout after five seconds (which should be ample for
> a human typist). Then if <Esc> is followed by something within one-tenth
> of a second it is examined for a keycode, but after that it still counts
> for a mapping.

Solely this does not work, because (if I got it correctly) the timeout
is the maximum time that Vim will wait to see whether a mapping has
been matched, not the minimum time. So when I hit <Esc>, Vim doesn't
wait at all, because a mapping already matched.

> If it still doesn't work, add
>
>        inoremap   <Esc><Esc>  <Esc>
>
> to force the full timeout (5s in my example) on the Esc key when not
> part of a keycode.

This works a bit better, but when I hit <Esc> to go back to normal
mode, Vim applies my first mapping and then it still waits during 5
seconds to see whether another mapping will match. If I hit an
extended key within those 5 seconds, the <Esc><Esc> mapping is
matched, and the second keycode is interpreted separately.

The best solution I could come up with was to map <Right><Esc> to
something than <Esc>. I'm used to the movement of the cursor upon
going back to the normal mode, but I still prefer when it doesn't
move.

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

Tony Mechelynck

On 16/07/08 17:18, François Ingelrest wrote:

> On Wed, Jul 16, 2008 at 16:57, Tony Mechelynck
> <[hidden email]>  wrote:
>>> I've been using something like that for some time:
>>>
>>> inoremap<Esc>   <Right><Esc>
>>>
>>> This works in GVim but breaks extended keys in Vim (they send<Esc>   as
>>> the first keycode).
>>>
>>> It seems that Vim doesn't wait a bit to see if another keycode
>>> follows, but rather immediately applies the mapping. This does not
>>> happen without the mapping, because in this case Vim correctly waits a
>>> bit to see whether it's<Esc>   or an extended keycode. Not sure whether
>>> this a bug or something desirable though...
>> IIUC it is usually a side-effect of 'ttimeoutlen' being at its default
>> of -1 (wait just as long for keycodes as for mappings). With something like
>>
>>         set timeout ttimeoutlen=100 timeoutlen=5000
>>
>> keycodes will timeout after one-tenth of a second (fast for a human, but
>> usually quite lazy for a keyboard driver or a telecom line) while
>> mappings will only timeout after five seconds (which should be ample for
>> a human typist). Then if<Esc>  is followed by something within one-tenth
>> of a second it is examined for a keycode, but after that it still counts
>> for a mapping.
>
> Solely this does not work, because (if I got it correctly) the timeout
> is the maximum time that Vim will wait to see whether a mapping has
> been matched, not the minimum time. So when I hit<Esc>, Vim doesn't
> wait at all, because a mapping already matched.
>
>> If it still doesn't work, add
>>
>>         inoremap<Esc><Esc>   <Esc>
>>
>> to force the full timeout (5s in my example) on the Esc key when not
>> part of a keycode.
>
> This works a bit better, but when I hit<Esc>  to go back to normal
> mode, Vim applies my first mapping and then it still waits during 5
> seconds to see whether another mapping will match. If I hit an
> extended key within those 5 seconds, the<Esc><Esc>  mapping is
> matched, and the second keycode is interpreted separately.

Well, hit Esc twice to go back to Normal mode, this mapping (which
doesn't remap) will be used, and there will be no waiting.

>
> The best solution I could come up with was to map<Right><Esc>  to
> something than<Esc>. I'm used to the movement of the cursor upon
> going back to the normal mode, but I still prefer when it doesn't
> move.

Best regards,
Tony.
--
hundred-and-one symptoms of being an internet addict:
77. The phone company asks you to test drive their new PBX system

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|

Re: Five (5) new features request

iler.ml
In reply to this post by smu johnson
On Wed, Jul 16, 2008 at 1:57 AM, smu johnson <[hidden email]> wrote:

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? 

You can find "autopatch" patch on this mailing list  about several years ago.
It was not accepted into core vim, though. But you can try it out, maybe
improve it.

Yakov


--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---