DaemonForums  

Go Back   DaemonForums > OpenBSD > OpenBSD Packages and Ports

OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD.

Reply
 
Thread Tools Display Modes
  #1   (View Single Post)  
Old 1st August 2015
cpaulette cpaulette is offline
New User
 
Join Date: Nov 2014
Posts: 7
Default Vim vs vi

A while back, one of the regulars (I think it was Oko but I can't be sure) made a comment along the lines that vim was too big and vi was a better choice in their opinion. I didn't have a username at the time (thanks again for your help jggimi!), but wanted to follow up on that.

I can think for myself and make my own choices, but I'm also learning and always interested in other viewpoints. So, if you're interested, I'd love to hear more from your perspective.

Disclaimers:
- This is not intended to start a flame war, different people use different tools for different purposes.
- I know that emacs and derivatives are options, I tried it and it wasn't for me. If you use emacs or mg and love it, that's fantastic, I'm not trying to push an agenda here.
Reply With Quote
  #2   (View Single Post)  
Old 1st August 2015
TronDD TronDD is offline
Spam Deminer
 
Join Date: Sep 2014
Posts: 304
Default

Well vim is going to be bigger than vi just by virtue of having more features.

I use vim because I use a couple of those features. Visual mode for example and split.

On the other hand, that means I get a huge amount of features I don't use (record, encryption, scripting) and even more that I don't even know exist.

How much bigger is it? I don't know. How comfortable is the project with the vi code base? No idea.

Tim.
Reply With Quote
  #3   (View Single Post)  
Old 1st August 2015
ibara ibara is offline
OpenBSD language porter
 
Join Date: Jan 2014
Posts: 783
Default

Quote:
Originally Posted by cpaulette View Post
I can think for myself and make my own choices, but I'm also learning and always interested in other viewpoints. So, if you're interested, I'd love to hear more from your perspective.
As someone whose name is plastered all over the mg(1) commit logs (http://cvsweb.openbsd.org/cgi-bin/cv...rc/usr.bin/mg/), I think I can offer some viewpoints.

My primary editor is vi(1). Yup, Good ol' in-base vi. Even all those commits I made to mg I wrote in vi (shh don't tell anyone! ).

There's a few reasons for this:
1. When I first started using *BSD, a long time ago, I was using ee(1) (guess which *BSD I started on). I made it a point to learn as many of the base utilities I could, in some sort of attempt to (I guess) be reliant on the OS and not its packages. So that meant ee and vi on this particular OS. I forced myself to use vi for even the smallest editing tasks--if I couldn't edit a file with vi, then I would have to go without it until I could.

By the time I could have even started using vim, the look and feel of vi was already so ingrained in me that I didn't like vim at all. I don't need the colors and I don't need the scripting. Others I'm sure can't live without it. It's not for me.

2. I ride -current on slow architectures, Always have; it's a consequence of developing on them. The downside to doing this is that the latest packages are often incompatible with the latest sets (packages are too old for the sets). So I can't use them. That forces you to be very picky about what ports you want to build on these machines. Turns out that vim isn't small. I need to have an editor the moment I bring a machine up. vi is there. I like using the same tools across all my machines when I can. So I use vi on my fast machines too.

3. The stuff I would use in vim (like splitting windows) I can do with tmux(1).

4. I use mg for free writing. I started using it to take notes in class and it stuck. I draft a good portion of my free writing on mg. I occasionally use it for coding.
One "neat" thing I do is I keep an mg binary in /bin (I call it /bin/mgrescue) that's statically compiled with a version of ncurses that has a vt220 termcap compiled in so that I can use it in single-user mode (never have to learn ed(1)). It has saved me when I've accidentally hosed machines.

5. And yes, I even occasionally use emacs. I even have a modest startup for it, mostly just theming it.
The best use for emacs? A portable IRC client! I never know what terrible (read: not irrsi) IRC clients people use, but I'm almost guaranteed that emacs is untouched (and I know the emacs IRC commands).

There's a place for everything (except vim, as it turns out) in my workflow.
Reply With Quote
  #4   (View Single Post)  
Old 1st August 2015
bsd-keith bsd-keith is offline
Real Name: Keith
Open Source Software user
 
Join Date: Jun 2014
Location: Surrey/Hants Border, England
Posts: 344
Default

Normally vi is available whichever unix-like OS you may be using, therefore, I tend to use it, (even if I know that it is vim in vi mode).

Edit: If mc is available, I will use it, (from within using mcedit), so I'm not a purist.
__________________
Linux since 1999, & also a BSD user.
Reply With Quote
  #5   (View Single Post)  
Old 1st August 2015
shep shep is offline
Real Name: Scott
Arp Constable
 
Join Date: May 2008
Location: Dry and Dusty
Posts: 1,503
Default

If you interest in this thread is due to a preference for command line tools, vim integrates nicely into mutt and the colors are nice in emails to highlight quotes, url's etc.
Reply With Quote
  #6   (View Single Post)  
Old 1st August 2015
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

http://galexander.org/vim_sucks.html
Reply With Quote
  #7   (View Single Post)  
Old 1st August 2015
ocicat ocicat is offline
Administrator
 
Join Date: Apr 2008
Posts: 3,318
Default

Quote:
Originally Posted by cpaulette View Post
...made a comment along the lines that vim was too big and vi was a better choice in their opinion.
It's important to put "too big" into perspective.

In the context of small systems (such as an Alix-like system) with potentially equally sparse disk space (think 4GB CF cards or less...), I don't go overboard with installing third-party packages such as vim or Emacs.

...but on other systems with terabytes of disk space, being concerned about how much space an editor takes is absurd.

I suspect the comment being cited is really focusing on the feature set provided, & how well the code is structured. There was a comment on misc@ some time back questioning how clear the vim codebase was, but I have seen similar comments made about other popular editors too.

Beyond that, vim has a large following, & gross issues eventually get addressed. Otherwise, the userbase would not allow such problems to fester, & would migrate elsewhere.

As mentioned earlier in this thread, vi is likely to be available on every Unix-like installation in existence. Possessing a passing knowledge of how to use it should be in everyone's set of skills. Beyond that, it is really a question of experience & personal preference as to what editor is used for daily tasks.

...& for the record, I use vi(1), mg(1), & Emacs. It is not so much a question of what editor do I use as much as it is a question of how much work do I get done.

Last edited by ocicat; 1st August 2015 at 05:18 PM. Reason: correct verb tense
Reply With Quote
  #8   (View Single Post)  
Old 2nd August 2015
thirdm thirdm is offline
Spam Deminer
 
Join Date: May 2009
Posts: 248
Default

My number one pet peeve with vim is what ctrl-a does. i.e. different from nvi on an important command and in a dangerous way. In general it seems to not make enough effort to provide a proper superset of vi, elvis, and nvi commands but instead changes some key bindings completely or fails to include settings (wraplen?). Probably I can change the key bindings as I start to use it more. What you can't do is make :se all return something you could realistically scan for the setting whose name you forgot.

I've been mostly an emacs user but used nvi for root and light editing off the command line. Yet lately I'm attracted more to vi key bindings and spending more time at the command line rather than using emacs as an IDE and command shell. For more features I'm wondering whether to learn vim or to simply continue to use emacs with viper. The latter is kind of like vim except with more I'm familiar with. Of course my complaints about vim not being close enough to vi could apply to viper twice over, depending how you set it up. But there I forgive since there are obvious reasons to do things differently in viper and because it documents and advertises itself as emacs with some of the good things of vi (primarily the keybindings) pulled in. You're supposed to want both emacs and vi if you're in viper. Why you would want changed features + new features in vim is not something I understand.
Reply With Quote
  #9   (View Single Post)  
Old 2nd August 2015
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

There is also Neovim in early development stages.
Reply With Quote
Old 4th August 2015
Carpetsmoker's Avatar
Carpetsmoker Carpetsmoker is offline
Real Name: Martin
Tcpdump Spy
 
Join Date: Apr 2008
Location: Netherlands
Posts: 2,243
Default

Quote:
vim was too big and vi was a better choice in their opinion
If you don't use any of the extra features that Vim offers, then yeah, nvi is better. If you do use those features (like many people), then Vim is probably better.

Quote:
Originally Posted by thirdm View Post
My number one pet peeve with vim is what ctrl-a does. i.e. different from nvi on an important command and in a dangerous way.
Vi never had a CTRL-a mapping; both nvi and Vim "extended" Vi with this mapping. You can't be compatible with everyone.

In any case, making <C-a> behave like nvi can be done with nnoremap <C-a> *.

Quote:
Originally Posted by thirdm View Post
I'm wondering whether to learn vim or to simply continue to use emacs with viper
Vim has a *lot* of limitations that Emacs doesn't have. Vi(m) has the better idea, but Emacs certainly has the better implementation.

Quote:
Originally Posted by ocicat View Post
Beyond that, vim has a large following, & gross issues eventually get addressed. Otherwise, the userbase would not allow such problems to fester, & would migrate elsewhere.
I believe this has already happened, and it's called NeoVim ;-)

Vim has many problems, and very few fixes get applied. It has a *single* developer with commit access, and many patches simply get ignored (simply because he has no time to check them all, or forgets).

Not that I'm not convinced that the NeoVim folk got the right idea, but that's a different story.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Reply With Quote
Old 5th August 2015
thirdm thirdm is offline
Spam Deminer
 
Join Date: May 2009
Posts: 248
Default

Quote:
Originally Posted by Carpetsmoker View Post
Vi never had a CTRL-a mapping; both nvi and Vim "extended" Vi with this mapping. You can't be compatible with everyone.
Yeah, my criticism didn't account for the real genealogy here. vim
seeming like the most modern of vi, nvi, and elvis I'd assumed it
followed each of those. But it appears to have pre-dated nvi and be
based on stevie which even predated elvis. I was thinking I'd make an
ascii art genealogy of vi and clones but it gets messy fast. e.g. newer
versions of elvis seem to sit somewhere in between nvi and vim in terms
of feature count (a happy medium?). And then nvi is based on elvis's codebase but made to
resemble traditional vi more closely.
Reply With Quote
Old 23rd December 2015
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

Have you experienced any instability using NeoVim?
I have just compiled it from source.


Installed dependencies and environment variables listed on this page:
Code:
#pkg_add gmake cmake libtool unzip autoconf-2.69p1 automake-1.15
export AUTOCONF_VERSION=2.69
export AUTOMAKE_VERSION=1.15
and also for faster build devel/ninja
Code:
#pkg_add ninja
and lang/gcc from ports.

Configure build for OpenBSD:
Code:
$ cat local.mk                                                                                           
CMAKE_EXTRA_FLAGS="-DENABLE_JEMALLOC=OFF"
CMAKE_BUILD_TYPE=RelWithDebInfo
fetch code and build. It will automatically use ninja build system:
Code:
git clone https://github.com/neovim/neovim.git && cp local.mk ./neovim/ \
&& cd ./neovim/ &&  gmake MAKE="/usr/local/bin/gmake" CC="/usr/local/bin/egcc" \
CXX="/usr/local/bin/eg++"
and install:
Code:
#gmake MAKE="/usr/local/bin/gmake"  install

Last edited by e1-531g; 23rd December 2015 at 05:36 PM.
Reply With Quote
Old 23rd December 2015
scottro's Avatar
scottro scottro is offline
Real Name: Scott Robbins
ISO Quartermaster
 
Join Date: Apr 2008
Location: NYC
Posts: 652
Default

I'd like to see someone mimic that test shown in the article that Oko linked. I remember in the double oughts, vi wouldn't do Japanese characters (at least for me) and I needed vim just for that. These days, however, nvi is fine with that these days.

As for sp (split) in nvi you can use N (upper case necessary) as in Next and it will do the same thing.

The visual is definitely useful for large blocks of text, but I try to be elite and do it by line number. (I mostly use it for moving blocks of text around.)
Reply With Quote
Old 24th December 2015
Oko's Avatar
Oko Oko is offline
Rc.conf Instructor
 
Join Date: May 2008
Location: Kosovo, Serbia
Posts: 1,102
Default

Quote:
Originally Posted by scottro View Post
I'd like to see someone mimic that test shown in the article that Oko linked. I remember in the double oughts, vi wouldn't do Japanese characters (at least for me) and I needed vim just for that. These days, however, nvi is fine with that these days.

As for sp (split) in nvi you can use N (upper case necessary) as in Next and it will do the same thing.

The visual is definitely useful for large blocks of text, but I try to be elite and do it by line number. (I mostly use it for moving blocks of text around.)
BSDs are using nvi version 1.79 due to licensing differences between Berkeley Database 1.85 and the later versions by Sleepycat Software. IIRC people were actively hacking on "OpenBSD version" of 1.79. If you need Japanese I would suggest you install nvi from the ports. OpenBSD version is the latest and the greatest nvi2 version 2.1.3.

https://github.com/lichray/nvi2

FreeBSD has in ports nvi-1.81.6_9 which is the last version of nvi before nvi2 fork has occurred.
Reply With Quote
Old 24th December 2015
scottro's Avatar
scottro scottro is offline
Real Name: Scott Robbins
ISO Quartermaster
 
Join Date: Apr 2008
Location: NYC
Posts: 652
Default

The default nvi now works with Japanese. I may not have been clear, I meant that in the mid 2000's,
the default FreeBSD's nvi wouldn't input Japanese--IIRC, I think there was a port under Japanese for it, but I couldn't get that working either, and in the end, used vim. However, these days, once I have Japanese input set up, the default vi, that is, the one that comes with the system, inputs Japanese with no extra work.
Reply With Quote
Old 24th December 2015
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

I am curious if NeoVim is still that slow as Vim.
I started learning Vim yesterday (V I M T u t o r - Version 1.5),
so I don't have any skills. If you could provide me commands to make 4MB
(maybe smaller also if it is that slow), I could test that.
I only ask for patience, because I have installed new snapshot and I started to
have problems with OpenBSD-current for the first time.
Reply With Quote
Old 25th December 2015
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

Ok, now I get it. I should also press escape.
NeoVim unfortunately is still slow. 20000 in relation to 10000 is five times slower.
Reply With Quote
Old 10th February 2016
e1-531g e1-531g is offline
ISO Quartermaster
 
Join Date: Mar 2014
Posts: 628
Default

News is based on Phoronix
https://groups.google.com/forum/#!to...ev/_SbMTGshzVc
Vim now have Asynchronous Processing Support.
It was in first place adopted by NeoVim, albeit I don't know if implementation is taken from NeoVim.
Reply With Quote
Old 11th February 2016
Carpetsmoker's Avatar
Carpetsmoker Carpetsmoker is offline
Real Name: Martin
Tcpdump Spy
 
Join Date: Apr 2008
Location: Netherlands
Posts: 2,243
Default

Quote:
Originally Posted by e1-531g View Post
I don't know if implementation is taken from NeoVim.
No.

Some async support has already available in Vim for years if you use Python, by the way. My auto_autoread plugin uses that. Basically, you can just start a thread.

This doesn't work with NeoVim, by the way. NeoVim seems to launch a new Python process and pipes the code to that, while Vim links to libpython and initializes a Python interpreter from there.
__________________
UNIX was not designed to stop you from doing stupid things, because that would also stop you from doing clever things.
Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT. The time now is 08:09 PM.


Powered by vBulletin® Version 3.8.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Content copyright © 2007-2010, the authors
Daemon image copyright ©1988, Marshall Kirk McKusick