|
OpenBSD Packages and Ports Installation and upgrading of packages and ports on OpenBSD. |
|
Thread Tools | Display Modes |
|
|||
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. |
|
|||
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. |
|
|||
Quote:
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. |
|
|||
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. |
|
|||
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.
|
|
|||
Quote:
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 |
|
|||
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. |
|
|||
There is also Neovim in early development stages.
|
|
|||
Quote:
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. |
|
|||
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 Code:
#pkg_add ninja Configure build for OpenBSD: Code:
$ cat local.mk CMAKE_EXTRA_FLAGS="-DENABLE_JEMALLOC=OFF" CMAKE_BUILD_TYPE=RelWithDebInfo 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++" Code:
#gmake MAKE="/usr/local/bin/gmake" install Last edited by e1-531g; 23rd December 2015 at 05:36 PM. |
|
||||
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.) |
|
||||
Quote:
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. |
|
||||
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. |
|
|||
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. |
|
|||
Ok, now I get it. I should also press escape.
NeoVim unfortunately is still slow. 20000 in relation to 10000 is five times slower. |
|
|||
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. |
|
||||
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. |
Thread Tools | |
Display Modes | |
|
|