Vim the best editor

Sudden Disruption wrote:

> When you move the editing primitives (Copy, Cut, Paste and Move) to
> mouse control, you can do an amazing amount of work without EVER
> touching a key, something you can't do that with vi or vim..

It seems that gvim ada vim -g is not known well enough.

Probably because most Linux distribution come with two vims: A scaled
down vim in /bin (for emergeny system repair) and a full feature gvim
in /usr/X11/bin (which often is not installed by standard :-( ).

Martin

Antony Scriven wrote:

> If you really have this problem and aren't trolling, try
> starting vim with vim -u NONE and see if the problem goes
> away.

No it won't go away. The standart keyboard timeout is indeed 1 sec. -
suitable for the slowest telnet/ssh connection one can imagine.

I think the real image problem vim has is that most who want to try
using vim will just open a terminal and hack in "vim". But most linux
systems have two vims installed:

>which vim gvim
/usr/bin/vim
/usr/X11R6/bin/gvim

And they are *NOT* the same:

>la /usr/bin/vim /usr/X11R6/bin/gvim /bin/vim
-rwxr-xr-x 1 root root 1,1M 2004-10-05 02:40 /bin/vim*
-rwxr-xr-x 1 root root 2,3M 2004-10-05 02:44 /usr/X11R6/bin/gvim*
lrwxrwxrwx 1 root root 8 2005-10-17 10:21 /usr/bin/vim -> /bin/vim*

/bin/vim is part of the emergency system-rescue tool set - scaled down
so /bin/vim will work even in the most difficult circumstances.

gvim is the propper editor with all functions enabled. Even is you want
to use a terminal you are better of using gvim.

Martin

"krischik" <krischik@users.sourceforge.net> writes:

> Antony Scriven wrote:
>
>> If you really have this problem and aren't trolling, try
>> starting vim with vim -u NONE and see if the problem goes
>> away.
>
> No it won't go away. The standart keyboard timeout is indeed 1 sec. -
> suitable for the slowest telnet/ssh connection one can imagine.
>
> I think the real image problem vim has is that most who want to try
> using vim will just open a terminal and hack in "vim". But most linux
> systems have two vims installed:
>
>>which vim gvim
> /usr/bin/vim
> /usr/X11R6/bin/gvim
>
> And they are *NOT* the same:

You are one off.

Typical for RedHat would be /bin/vi (a basic compilation without most
add-ons), /usr/bin/vim (a full compilation without X11 support),
/usr/X11R6/bin/gvim (a full compilation with X11 support, I might have
the path wrong).

--
David Kastrup, Kriemhildstr. 15, 44793 Bochum

krischik wrote:

> Antony Scriven wrote:
>
> > If you really have this problem and aren't trolling, try
> > starting vim with vim -u NONE and see if the problem goes
> > away.
>
> No it won't go away.

Sure it will. What is it with people and testing? See :help
'esckeys'. However your diagnosis that, when typing ^]O in
insert mode, waiting for a terminal keycode is causing
a delay, is likely to be correct. (If you hadn't snipped so
much I could have written a shorter sentence there!)
Starting vim as vim -u NONE is the best first step for
tracking down a problem. Since the OP was being an arse
I wasn't planning to help much. I might have mentioned
:help and :help :help.

> The standart keyboard timeout is indeed 1 sec. - suitable
> for the slowest telnet/ssh connection one can imagine.

As a reference point I've found 100ms suitable for general
use, including over a slow dialup. If the OP doesn't want
cursor keys in insert mode then it won't matter -- use :set
esckeys which is the default. If the OP uses viper-mode in
emacs then the same problem will be there except that viper
has a default timeout of 200ms which probably isn't noticed.

> I think the real image problem vim has is that most who
> want to try using vim will just open a terminal and hack
> in "vim". But most linux systems have two vims installed:

Vim has an image problem? It's a very popular editor.
I don't think it's image really needs defending.

> >which vim gvim
> /usr/bin/vim
> /usr/X11R6/bin/gvim
>
> And they are *NOT* the same:
>
> >la /usr/bin/vim /usr/X11R6/bin/gvim /bin/vim
> -rwxr-xr-x 1 root root 1,1M 2004-10-05 02:40 /bin/vim*
> -rwxr-xr-x 1 root root 2,3M 2004-10-05 02:44 /usr/X11R6/bin/gvim*
> lrwxrwxrwx 1 root root 8 2005-10-17 10:21 /usr/bin/vim ->
/bin/vim*
>
> /bin/vim is part of the emergency system-rescue tool set
> - scaled down so /bin/vim will work even in the most
> difficult circumstances.

At 1.1Mb I'd hardly say that was scaled down. Are you sure
you don't have a vim-tiny somewhere else?

> [...]

*Followups set to comp.editors* since this article is almost
entirely irrelevant to emacs.

Antony

David Kastrup <dak@gnu.org> writes:

> Typical for RedHat would be /bin/vi (a basic compilation without most
> add-ons), /usr/bin/vim (a full compilation without X11 support),
> /usr/X11R6/bin/gvim (a full compilation with X11 support, I might have
> the path wrong).

That may be the situation on Red Hat / Fedora Core, but in other
distributions it is in a different way.


--
Juhapekka "naula" Tolvanen * http colon slash slash iki dot fi slash juhtolv
"She turns me on. She makes me real. I have to apologize for the way I feel."
Nine Inch Nails

In article <1143675113.383299.78420@e56g2000cwe.googlegroups. com>,
Antony Scriven <ad_scriven@postmaster.co.uk> wrote:
>davidb@scn.org wrote:
>
> > Uh, right.
>
>Uh, right what?
>
> > Edit a file in vim. Pick a line, any line. Go somewhere
> > in the middle of that line. Type i <space> <esc> . Now
> > type O .
>
>Okay.
>
> > What the?!?! The added line doesn't show for several
> > seconds!
>
>Nonsense. It's just you.

I also was not able to replicate davidb's experience. The added
line showed up on my screen nearly instantaneously. This is with
vim 6.3.

And about how many versions of vim are installed ....

FC4 system here. There seem to be three:

-rwxr-xr-x 1 root root 536176 Apr 27 2005 /bin/vi*
-rwxr-xr-x 1 root root 2584112 Apr 27 2005 /usr/X11R6/bin/gvim*
-rwxr-xr-x 1 root root 2331912 Apr 27 2005 /usr/bin/vim*

Similar results on a RH9 system to which I have access, but all
sizes are slightly smaller.

Another data point (or two).

--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.

In article <491u6vFmi4pdU1@individual.net>, <blmblm@myrealbox.com> wrote:
>In article <1143675113.383299.78420@e56g2000cwe.googlegroups. com>,
>Antony Scriven <ad_scriven@postmaster.co.uk> wrote:
>>davidb@scn.org wrote:
>>
>> > Uh, right.
>>
>>Uh, right what?
>>
>> > Edit a file in vim. Pick a line, any line. Go somewhere
>> > in the middle of that line. Type i <space> <esc> . Now
>> > type O .
>>
>>Okay.
>>
>> > What the?!?! The added line doesn't show for several
>> > seconds!
>>
>>Nonsense. It's just you.
>
>I also was not able to replicate davidb's experience. The added
>line showed up on my screen nearly instantaneously. This is with
>vim 6.3.

And in one of Linux's virtual text consoles. After reading another
post in this thread (about how to reduce the delay), it occurred to
me to repeat the experiment using a terminal emulator under a GUI.
In a gnome-terminal window .... Yes, there is a perceptible delay,
though it doesn't seem as long as a full second.

FTR, FWIW, other acronyms (initialisms?) as applicable.

--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.

Antony Scriven <ad_scriven@postmaster.co.uk> wrote:

> > What the?!?! The added line doesn't show for several
> > seconds!
Not here
maybe you have more than one mapping starting with O, so that it waits
for a possible second keystroke, and only after you haven't typed one
for a second or so, will it default to the regular O command.

Bart van Deenen

Bart van Deenen wrote:

> Antony Scriven <ad_scriven@postmaster.co.uk> wrote:
>
> > > What the?!?! The added line doesn't show for several
> > > seconds!

Actually David Barts wrote that.

Antony

David Kastrup scripsit:
> Typical for RedHat would be /bin/vi (a basic compilation without most

The same for Mandrake/Mandriva.
Second reason to switch to compiled from sources version.

m.
--
LaTeX + Vim = http://vim-latex.sourceforge.net/
Vim Universal Templates: http://vim.sf.net/script.php?script_id=1078
vim.pl - http://skawina.eu.org/mikolaj
CLEWN - http://clewn.sf.net