Slashdot Mirror
Neovim: Rebuilding Vim For the 21st Century
An anonymous reader writes "Neovim is a major overhaul of the vim editor to provide better scripting, cleaner support for plugins and integration with modern graphical interfaces. Modernising the large and complex codebase of Vim is a formidable task, but the developer has a clear plan, and has already begun work. There's a Bountysource fundraiser running to support the effort. If Vim is your editor of choice, check it out." (The crowd-funding effort has only one more day to go, but has well exceeded already the initial goal of $10,000.)
http://xkcd.com/378/
http://www.emacswiki.org/emacs/GnuEmacs
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
There's a reason people argue about vim and emacs...
It's because they're BOTH shit.
Do people in fact still argue about vim vs emacs?
It seems to me the the vim-vs-emacs wars ended in a stalemate decades ago, and everybody who participated is resigned to the fact that nobody will ever switch from one to the other. Meanwhile, all the young'ns are using IDEs anyway, and have only a vague idea what vim or emacs is, so they don't really care enough to argue about which is better.
I don't care if it's 90,000 hectares. That lake was not my doing.
if someone came to me to evaluate their budget reasonableness for something they described as a formidable task taking more than a week or two, and asked for $10k, I'd know they were egregiously underestimating or something is missing.
(and as TFA says: "Over its more than 20 years of life, vim has accumulated about 300k lines of scary C89 code that very few people understand or have the guts to mess with."... that's pretty formidable)
I suppose some ambitious person living in a low cost of living locale could survive for 6 months on 10k, and that would be a fair amount of work time; toiling in their barren garret or tower.
TFA says "$10,000 will allow me to dedicate two months of full time work to this project, which will be enough to implement the following:"
Is $5000/mo a reasonable sum in Recife, Brazil? Probably.
Is 2 months sufficient time to do all he wants to do? I'm not so sure. That's a pretty long list of things he wants to do.
"There's a reason people argue about vim and emacs... It's because they're BOTH shit."
If you SSH to a remote host and want to use a powerful editor, what do you use?
I admit to being curious to see how this one goes as a fork off the existing vim codebase, but I'm not sure I'd be putting any bets on its long term viability. I suspect an overdose of optimism and insufficient compelling reasons for users to shift from vim will starve this project out.
Good luck to the developer - it's going to be one hell of a learning experience.
https://groups.google.com/foru...
"It's going to be an awful lot of work, with the result that not all systems will be supported, new bugs introduced and what's the gain for the end user exactly?
Total refactoring is not a solution. It's much better to improve what we have. Perhaps with some small refactorings specifically aimed at making Vim work better for users."
You know you can forward X11 over SSH right?
So the answer is: anything you want, be it GUI or not.
It's a pretty big step to just fork a major project like that. Have they actually talked to Bram and the other vim hackers first? I can only assume that if their ideas are sound that he would have no problem integrating them upstream.
vi and vim have been around for decades becasue they fullfil a need of a text editor that can be found on every Unix box you might have to work on. They have a command set most know enough to use even if they prefer other editors. It has enough features to use as an development editor and most important there are tons of other editors to choose from.
Don't screw with vim you want to make you idea of a better vim fine just leave the original alone!!!!
The other day I was tasked with uploading a shell script displayed on a web page to an embedded device running Linux. For reasons unknown the only editor installed was on the device Vim. Instead of learning how to copy/paste in Vim, it was faster to use Nano on my local computer to copy the script into, and then SCP the saved file to the embedded device.
I think there's something to be said for simple editors.
I care for neither Vim nor Emacs. But only because they are overly powerful for my meager scripting needs. Basically, Vim's complexity actually slows me down. However, having taken the time to actually learn Vim, I fully appreciate why it is loved by more hardcore programmers and why it increases their productivity. The complexity of coding in Vala or Objective C, etc... is a match for the complexity of VIM - so to speak. I have yet to grow a beard long enough to try out EMACS.
Brought to you by Carl's Junior.
You know you can just mount the file system of the remote host by sshfs, right?
I'll have you know that vi was written in 1976, mister.
Because, at the end of the day, you can compile Vim with only core vi commands and features so the resulting executable is tiny and usable on an embedded device with limited resources.
I'd fire anyone that installed Nano (or, heaven forbid, Emacs) on an embedded device.
It doesn't work as well as you might wish. X11 has, historically, not compressed well for remote graphical interactions. The problem is compounded when running X sessions over a VPN to a remote environment, and using the graphical environment hosted inside the GUI to the virtual machine manager.
I've found vim very useful when memory or resource squeezed. Emacs's tendency to leave temporary scattered copies of large edited files is particularly dangerous when trying to salvage database backups on a cramped partition. But the tendency of vi users to confuse their personal display settings for indentation with the actual text in the files they edit has caused enormous problems. This especially happens they submit code following indentations standards that exist only in the .vimrc somebody has been mailing around for the last six years, and which no other group in the world uses, and then they complain when the authors of the original software regularize the whitespace on submitted patches.
pico
Sure, but, if you're really packin' the gear, you know that:
-- Real men leave their Xs in Texas, and
-- X11 is a waste of admin bandwidth; command line or bust.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
You can download the successor to vim here. FTFY.
Computer simulation made easy -- LibGeoDecomp
It's pretty obvious that you've never had to debug deployed embedded systems. This isn't ancient history buddy, it's something I have to do regularly. Certain fields have requirements that just aren't going to go away.
Vim is nice and I actually use it for programming, but jumping between the command mode, insert mode and visual mode still slows me down a lot. Why can't we just be in insert mode constantly and use Ctrl+something for all the commands? Also use Shift+arrows to select text?
When the primary forum for discussion of said program is still on usenet.
First class support for embedding
Since Neovim will be provide the interface to interacting with text, any program will be able to tap into this potential and be able to include Neovim commands right in the application.
Vi and it's many variants over the years have been my primary editor of choice for over 20 years (let's not talk about Unix editors before then; let's simply call that time "the dark ages"...). I like it because it's simple and it works. I appreciate more recent features like syntax highlighting to let me know where I missed something in my code. But I think vi has been extended about as far as it can, without becoming Emacs.
If someone wants to clean up Bram's codebase because the cobwebs make it difficult to maintain - great, fine, I can appreciate that. But "modernizing" vi to bring it to the "next generation" of users is a fool's folly because the environment vi thrives in is not even on the radar screen of current CS/CE/IT students - the "next generation" of potential users.
Like the lovely idiom says: If it ain't broke, don't fix it!
I got bit on this. I use Emacs for various source code, because my hands know it, and it does indentation correctly, and I prefer its indentation standards for well known text types such as C and bash and perl. It also has hooks into certain source control systems, like CVS and RCS, to handle locking and unlocking.
Enter the new job, and a new manager, who would review work I was doing before I did commits to critical environments. He would open the files with "vim -R". I would do the work, we'd agree on it, I would save my work, then *he would quit vim and it would overwrite my saved work*. Worse, he would quit vim and it would overwrite the local copy of my *source control committed file*. Vim is not a pager! It is an editor, and this is broken behavior!!!! You *NEVER NEVER, NEVER* allow something in "read-only" mode to overwrite the original file unannounced!!! NO! BAD TOOL! DO NOT USE!!!!
Fortunately, I was able to show the source control history and that I'd saved the correct work. But *man*, that screwed things up repeatedly. Editors should *never* overwrite the original source file without being told explicitly to do so. NEVER, NEVER, NEVER!!!!!!
I don't want vim to have a GUI, I don't care about plugins, and as far as I'm concerned -- there's absolutely ZERO reason to change its code base one iota.
Some things, are simple 'done'. Completed. They do not need to be worked on, or enhanced. They merely need updates to keep up with code changes in support libraries/etc, and bug fixes.
No new features!
Hell, context highlighting alone is the most annoying thing recently...
I think instead of rewriting the C part, they should improve Vim's scripting language to the point where it can be used for moving larger portions of the editor into it. Vim script is a decent effort, but it feels a bit cumbersome and non-standard. I think they'd be better off with something that more widely used and possibly JIT compiled.
You should automatically check for tabs and refuse any commit that uses them.
There's a reason people argue about vim and emacs...
Vim: Oh look, this isn't an argument.
Emacs: Yes it is.
Vim: No it isn't. It's just contradiction.
Emacs: No it isn't.
Vim: An argument is a connected series of statements intended to establish a proposition.
Emacs: No it isn't. Not if it's written in Lisp.
Use an IDE locally and ship the product to the remote host. It isn't 1972 anymore.
But I'm a sysadmin and need to adjust config on the host because the developers keep making the same mistakes that were made back in 1972, and the QA department has questionable judgement on a Friday.
This is precisely the reason I learned Vim: it's installed on every Linux system and it works well over SSH. It's great for the small amount of remote administration I do on my shared web hosting account.
I tried your scenario.
If play your boss and I exit with ':q', no problem. Your version is still there.
If I exit with ':wq', vim says: "E45: 'readonly' option is set (add ! to override)"
If I exit with ':wq!', vim says: "WARNING: The file has been changed since reading it!!!
Do you really want to write to it (y/n)?"
So I conclude that one of the following is likely the case:
a) your boss is was an idiot who would ignore a message ending with three exclamation points
b) you boss installed a bizarre custom vim config file that somehow allowed silent overwrites of modified files from readonly mode
c) your story is a fabricated troll
In my days kids did this for free.
I chose not to support you cause you mentioned what the fox said on your web page. Get off my lawn you whippersnappers!
The plan is to compile VimScript to Lua so that backwards compatibility is maintained, and that new plugins will be written in any language that we can make a plugin container for. Lua is guaranteed to be present though.
Neovim will embed the LuaJIT interpreter/jit, which is widely known to be the crown jewel of script interpreters when it comes to raw speed. It helps that Lua is a beautifully simple language as well (eye of the beholder, but still...).
The efforts for a VimScript to Lua translator are already well underway: https://github.com/ZyX-I/neovim/tree/luaviml
The Neovim codebase is already much cleaner than legacy vim in many respects. It also uses continuous integration, many warnings and the LLVM sanitizers to detect memory leaks and undefined behaviour as early as possible. I have high hopes for this project, it's got great momentum. If you have a smidgeon of free time, please contribute, the project is very open. In this respect I can liken it to mpv, which has taken mplayer and accelerated its development 100x (exaggeration, but still).
That's a quite simple question, I'll use KWrite or Kate. Locally of course, opening the remote file with the fish: kio slave. Same way as ever for the last decade, it's not even new tech. So why insist on stone age workflow:-)
The editor that comes with Emacs is called Viper. Have you tried it?
Does this classify as heresy or as a schism?
I bet his boss used ZZ to exit all the time. It's the vi lazy way to save and exit, no questions asked.
It's not on gentoo. Annoyed the hell out of me when I did a gentoo install from the ground up; had to edit everything with nano.
I'd fire anyone that installed Nano (or, heaven forbid, Emacs) on an embedded device.
That's unfortunate for me because I prefer Nano. But I understand that the GNU project has made a design choice to optimize for functionality and maintainability on PCs, not necessarily the smallest devices. How small is such an "embedded device"? And is Pico (Alpine Composer), the editor on whose user interface Nano was based, likewise too big?
If you don't care for the modes, why do you still use VIM?
This anonymous poster claims that his employer mandates a stripped-down version of Vim because it's smaller than GNU Nano. This means it more comfortably fits into the memory of a small embedded system to which someone connects through an RS232 terminal.
I bet his boss used ZZ to exit all the time. It's the vi lazy way to save and exit, no questions asked.
I tried that, too. It still won't let you write in readonly mode without warning you.
That sounds like the Vatican considering how to best employ porn for spreading, uh, their message.
We are still talking about a clone of vi, the editor turning into a clone of ed upon pressing Q or even : ?
This makes me sad. "Rebuilding VIM for the 21st century" is like rebuilding the hammer for the 21st century. It's a very basic tool and it does what it does extremely well. I'm not saying it's impossible to improve it; I'm saying I'll be skeptical until they demonstrate that something has fundamentally improved.
How is Escape at the top left corner to enter single-key command mode any better than Control at the lower left corner or arrow keys at the lower right corner?
You keep using that word. Notepad is "simple". This is not. Powerful, yes. Simple, no.
My first program:
Hell Segmentation fault
You should/could also slap some mod lines at the start of your files. Ex:
# ex: set tabstop=4 expandtab smarttab softtabstop=4 shiftwidth=4:
# -*- Mode: tab-width: 4; indent-tabs-mode: nil; basic-offset: 4 -*- #
You could also just run it through a tidy program and a site-specific config if you really want to be a formatting nazi.
Meanwhile, all the young'ns are using IDEs anyway, and have only a vague idea what vim or emacs is, so they don't really care enough to argue about which is better.
The IDE users have been on their way out for quite some time now. The young'ns are using TextMate, BBEdit, Sublime Text, Espresso, ...
If you SSH to a remote host and want to use a powerful editor, what do you use?
If I have an ssh port open, I type on my running copy of Emacs on my local system
C-x C-f /username@hostname.net:filename.ext RET
and Emacs will open an ssh session into the remote system and use it for transferring filename.ext between my local copy of Emacs and the remote file system. If I use M-x shell RET or M-x compiler RET in that buffer, Emacs will again employ ssh for executing the respective command on the embedded system.
I don't even need to install an editor there in order to do my editing there with Emacs. And a perfectly customized version of Emacs, to boot.
'Rebuilding Vim for the 21st Century' says it all. The problem with the 21st century from what I've seen, is this insistence that we must re-invent the ENTIRE wheel.
I'm going to suggest that if you feel it's time to re-invent vim, that it target a universal platform. There's really only one - the web. You can use it on every platform. Using the project node-webkit, there's really no reason not to use HTML5 and Javascript to develop an honestly modern application. (The sarcasm is dwindling, I'm half serious.)
I use vim myself, and generally stick to the basics of it because they allow me to edit very quickly. I don't really see the benefit of rewriting it, especially if you're going through so much trouble to retain compatibility with old plugins by compiling them to lua. Basically, you're setting yourselves up to run into the situation of having to re-implement vast portions of the PROBLEM you perceive with vim for that singular point.
Point: Just use vim.
The three things: Plugins, GUI, embedding
New plugin architecture retaining compatibility - already covered.
GUI - gvim's GUI has taught me just one thing over the years, that vim is not a GUI program. The GUI has the potential to make advanced functions more accessible, but re-implementing vim means you're starting without those functions in mind...
Embedding - this is one area where my interest is piqued. Embedding vim into other applications could be more elegant, but then embedding applications into other applications has always been a little odd, and this is one of those cases where you can run into some serious platform issues. This might actually be a case where that web technologies idea could bring incredible flexibility to the table.
Then there's always the option of using vim as an editor for the way it edits, and not getting caught up in the advanced functionality such as the GUI, and plugins, and embedding it as a plugin. Then we find a case where the entire effort is wasted, especially if it gets any of the details wrong in the basic functionality.
alias vim emacs
i quit using vim because the god damn Ugandan orphan spam in my face every time i opened it, if i see that in neovim i will not use it either,
Politics is Treachery, Religion is Brainwashing
As long as it passes VSC5, I don't care.
They could put antlers on the thing, as long as it continues to pass the POSIX conformance test suite Validation Suite for Commands version 5, it doesn't matter, my medulla will be able to still type the commands to operate it while I'm up in my cerebral cortex thinking about higher level problems than "will typing this command too many times give me carpal tunnel syndrome like RMS has from emacs use?" or "how an I get a graduate student to take dictation into an editor for me, rather than aggravating my carpal tunnel syndrome acquired from emacs use?".
You would have to break all the things that cause people to use it ... and then its not going to work the same on EVERY unix machine on the planet. vi's strength lies in the fact that as crappy as it is, its consistently crappy, the same way (vi feature set) across all machines, even the crappiest tiny embedded linux distro, to full server and desktops. I don't have to wonder what editor I'm going to have to find and use nor how it works.
Stop fucking with vi.
If you want a non-shitty editor, stop using a shitty editor thats meant to be tiny and 'get the job done', its like you guys think notepad (I know vim is not anywhere near the same class as notepad) is actually a GREAT DEVELOPMENT TOOL.
I'm sorry, and I know half of slashdot is about to asplode at my comment, but if you think vi/vim is a good editor choice, your choice in editors is fucking retarded and you need it beaten out of you. And yes, I know some of your biggest celebraties use vim with pride and brag about it ... and the other half eats their own toe jam in public. Think about it. Not everything these developers do is a good idea, even if they are remarkable and prolific developers.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
As much as I love forwarded X11 apps, its rarely efficient over moderate to slow links. I can't justify using over 1Mbit of uplink traffic just to use my editor over the wire when even a VNC session is more efficient.
FYI, I've often run vncserver on a remote machine, forwarded 5900 over my SSH session and then viewed it locally to launch X11 apps. This has the advantage of not killing the apps if the link goes down. It saddens me a lot that X11 isn't as powerful or useful in these scenarios as VNC.
- Michael T. Babcock (Yes, I blog)
I love VIM because I can guide a user remotely through exactly what to type and know exactly what response they'll get without depending on them to click on the right button or highlight the correct piece of text.
Ever edited /etc/ppp/chat-secrets with an accountant over the phone blind?
- Michael T. Babcock (Yes, I blog)
The editors vi/vim are brilliant - regardless of whether my keyboard has a CTRL key or whether I have a high bandwidth connection, it permits me to do a halfway efficient editing job.
However it has a problem. It's not that there's a command mode and an edit mode. The main problem with vi/vim is that it gives you NO VISUAL CLUES.
You cannot use it without memorizing half the manual, and even then, years after I've started using it, I still see people use shortcuts and features that I wasn't familiar with.
Point being: https://xkcd.com/1343/
Java on a embedded device
http://www.drdobbs.com/jvm/its-a-java-embedded-world/240005983
Evolution:
Vi -> Vim -> NeoVim
Analogy:
Asm -> C -> C++
My previous employer did work in CICS for years, he's well out of the development game now and a 'serial startup guy' as he likes to call himself.
He KNOWS how to code, or at least, once did, I've heard from enough people that knew what he did at some large companies and validate his skills.
He will straight up ignore every fucking popup window that gets in front of him and just next -> next -> next -> finish through (windows user now) everything, or click whatever button seems most obvious on the popup ... never reads anything.
We had a 'bug' in the installer I wrote. He and another 'old dude' who used to be on the xml standards committees (again, this guy has clout in technical circles of yester year). The bug was that it would reboot your machine, without asking you, during install if you had Outlook open and it would close ALL of your apps without prompting for saving or anything else ... (it was an outlook plugin, easier to not install with Outlook open than to tell people they need to restart outlook for reasons that will become clear shortly).
So after explaining that I never could get that to happen to me in my environment (was working out of the country at the time, getting to stand next to them and watch them wasn't happening and for some reason I can't recall, vmc wasn't really an option either) I finally got back to the office where I could watch the process, where I was waiting to see how my NSIS installer was magically making things like Excel and Word close without saving files ...
BOTH of them, got to the point where a popup came up and said 'Outlook is open, close outlook to continue ' and they'd just click next ... at which point the installer says, Outlook is still running ... a reboot is required to complete this installation, do you want to reboot now?' and they click next so fast I couldn't even stop them.
Better still ... when Excel started asking them if they wanted to save ... ON THOSE DIALOGS they fucking clicked NO, so fast I couldn't even say 'whoa, wait a second' their machine was already rebooting ... after they clicked AT LEAST 4 boxes from different applications trying to slow them down and prevent the mistake.
The bug, was a PEBKAC bug with a bit of ID10-T thrown on top. I had to physically remove the mouse from one of their hands and run the installer myself to get them to actually read the message that they claimed they weren't seeing.
Another related story. I'm an IT guy, I have all those same IT shitty users stories most of slashdot has :) My pet peeve (like many of us) is people who don't read the message, and my wife, who has known how much that pisses me off since at least 2001 when it became a bigger issue for stupid reasons at one job calls me up the other day from her new job.
They sent her an email that she needed to change her password, they rotate on 90 days intervals. Its a university with some sort of identity management system in place that syncs all their systems and password changes are done via a website, fairly common setup for a university it seems though I don't know the specifics of the software involved yet.
So she clicks the link, changes her password and then tries to go visit some research paper website they have internally for internal releases of research papers for internal review and discussion before submitting to more formal publications, so she gets there and it says something wrong with her login/password. It never asks for a login password, just says no. So my eyes, recognizing that kerberos and/or ntlm is in play here said to her 'look sweetie, I don't know your setup, but since its not prompting you for a password, I bet if you just logout and log back in, it'll work. (Windows 'auto-corrects' a lot of silly issues for kerberos stuff on login and of course reinitializes your authentication ticket at login so your
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
I'll just note that nobody I know of who runs servers enables X11 on them.
This largely depends on things like coding standards in the shop, the language in use, etc. Tabs vs. spaces for indenting is largely a stalemate as well - those who use tabs point out that this allows each programmer to set tab width as desired, without messing with anyone else's visual preference. It also means that there is one character per indent. Of course mixing is bad, but the only language I can think of offhand where the use of tabs vs. spaces can be a real problem is Python.
And some people type too much.....
done
You know lots of Linux/Unix/*BSD systems don't have an X server, right? (Actually the majority of them don't)
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
You know that most Linux systems don't support sshfs, because they don't have and SFTP server, right?
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I'm vimemacsidextrous you insensitive clod!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
Your scenarios are way too complicated. It's simple as this: the boss didn't open the files in readonly mode.
The other day I was tasked with uploading a shell script displayed on a web page to an embedded device running Linux. For reasons unknown the only editor installed was on the device Vim. Instead of learning how to copy/paste in Vim, it was faster to use Nano on my local computer to copy the script into, and then SCP the saved file to the embedded device.
I think there's something to be said for simple editors.
At this point, I drag up the story of the Sun workstation where the prat given root access couldn't handle vi, so to add a user account he ftp'ed the password file to his PC, edited in Word, saved it, ftp'ed it back up, moved it into position, and voila! locked everyone out of the machine.
Yes, boys and girls, Solaris might have been clever, but reading Word document formatted password files wasn't one of its tricks... still, that incident kept me amused for a couple of weeks (and gave me the ammo to keep idiots like this away from root/admin passwords).
people wonder why I got out of IT....simple answer, google The Marching Morons...
You're right, they both kinda suck UI wise and they carry over their 70s design decisions 40 years later. But in vim's defense, if you have a lot of commands to execute in command mode, there's very little finger effort (i.e. typing) required to execute a series of editing commands (dd, yy, p, etc). Doing the same in your typical IDE would require you to constantly hold down the ctrl, command, alt and/or shift keys while executing a command modelessly. This causes finger strain over time, not to mention it is slow. I don't think any other editor gives you cruise control like vim in command mode.
..Ever edited /etc/ppp/chat-secrets with an accountant over the phone blind?
Umm, no, sounds like fun, ever tried dictating to someone how to make specific changes to a graphics file using xv over the phone(from another country, into the bargain)?
It rather begs the question WTF was an accountant (of all the minions of satan) doing with admin rights on a unix/linux box, and, more importantly, how much did he charge you for doing the work?
joe!
(GDR...)
and it's called Notepad++ with support for something magical called a computer mouse.
There are two elephants in the room when it comes to vim that really need to be addressed:
1. Its pattern or "regular expression" support. I'm talking about things like :%s/// for matching/replacing but it can be used in other places. I'll refer folks to the docs, which they should read (or if you just want to skim, go to the vim wiki link):
http://vimdoc.sourceforge.net/htmldoc/pattern.html
http://vimdoc.sourceforge.net/htmldoc/usr_27.html
http://vim.wikia.com/wiki/Search_patterns
Take a very, very close look at how parenthesis work under the section called Magic. It's completely inverted compared to every other expression/RE, even base system regex.
Any vim user who has been using this functionality knows how painful it is; it can literally take you 20 full minutes to come up with a vim :%s line that does what you need, and most of the time the user ends up just shelling out to the CLI and using sed or perl or whatever else to do the replacement because of vim's awful pattern syntax.
"21st century" (I hate this term) vim should just use PCRE and be done with it. I'm a KISS principle minimalist and don't like the idea of tying vim to another 3rd-party library, but I think this would be acceptable given PCRE's prevalence.
2. Bram's absolutely horrible laziness when it comes to making actual releases. For those who don't follow vim regularly, you probably don't know of this problem, but its existed for years. Basically someone submits a patch to Bram, he approves it, and the patch gets made and dumped as a single patch/diff file in the patches directory:
ftp://ftp.vim.org/pub/vim/patches/
Take 2-3 minutes of your time and go to that directory and look around. For starters, look at the 7.3 directory and how many patches there were between 7.3 and 7.4. The answer? 1314 patches. Yes, over THIRTEEN HUNDRED patches before 7.4 was made. Now look at the 7.4 directory (7.4 is the current release of vim); there are already 211 patches.
The problem is that Bram lets things sit in this condition for ages -- often YEARS -- before making a release. He needs to make releases more often. And in case you think I'm whining, I'm not: even Bram himself has admitted that "there's too many patches between releases":
http://www.vim.org/news/news.php
Quote:
There's hilarity in the fact that he admitted this in May 2013, but didn't do anything about it for another 3 months (vim 7.4 came out August 2013), during which time nearly 400 patches were submit/accepted.
Yet this problem continues on and on (cue Journey's Don't Stop Believing). The only person to blame for it is Bram. He should make an effort to actually roll a new release when he reaches an arbitrary number of patches -- say, 100 or 150. 1300+ is literally insane, because by the time someone upgrades from 7.3 to 7.4, and finds something broken, there are _1300+ patches_ to go through to figure out the regression. It's not manageable, and I'm sure he knows it. So he should step up to the plate and stop playing with drills.
OpenSSH comes with an sftp server and enables it by default (only through the SSH tunnel of course). Very few admins actually turn it off.
I stand corrected. Thank you for pointing that out, as I was completely unaware of this, but it does indeed turn out to be true!
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
those who don't understand vim are condemned to re code it
That may be the most incorrect xkcd.
Self-explanatory tools (knowledge in the world) is great for a newbie doing a one-time task. Four minutes hunting through menus is better than 10 minutes hunting through the manual.
For routine tasks or experts, two seconds typing "find . -atime -1" is much, much better. For tasks you do regularly, you want knowledge in the head. For rarely performed tasks, you want knowledge in the world.
What you've described is, I'm afraid, the technical approach to what is a workflow problem, not a technical problem.
Yes. I can clean up after the fact, with every single source file my team uses, re-indent all of them, and institute my particular site's arbitrary white space coding standard on every open source project or shared development project I work with, and mandate that they all use "vim" even in their Macintosh and Windows development environments. I can also completely break the revision history when I reset the history by general whitespace changes across every single file that uses a non-standard indentation format. I can also break, and manually resolve the problems with configuration tools that edited those files for deployment based on particular text, including the whitespace.
Now please pay my contracting rates or salary rates to resolve the disputes in every project I work with about whose coding standard we should follow, and which editor settings we'll enforce in every development environment, and the time getting such wholesale document changes through code review. I'm afraid it adds up very, very quickly to a lot of wasted resources.
I'm trying to read this in church. Stop making me laugh.
Good, so you agree with me then, that pouring money into trying to update vim is pointless, and just polishing a turd.
No. What it will mean is that of a whole lot of people who don't use IDEs because it doesn't allow them to use vim properly (yes I have tried the vim plugins to IDEs), will be able to access the benefits of an IDE without feeling like they have been suddenly lobotomized by it.
My ism, it's full of beliefs.
Use an IDE locally and ship the product to the remote host. It isn't 1972 anymore.
....aahhhh, so little knowledge for such a big mouth...
As much as I love forwarded X11 apps, its rarely efficient over moderate to slow links. I can't justify using over 1Mbit of uplink traffic just to use my editor over the wire when even a VNC session is more efficient.
FYI, I've often run vncserver on a remote machine, forwarded 5900 over my SSH session and then viewed it locally to launch X11 apps. This has the advantage of not killing the apps if the link goes down. It saddens me a lot that X11 isn't as powerful or useful in these scenarios as VNC.
I've noted on these links that when I use vim over the wire (so to speak) that the noise is so bad that it actually inserts characters into the session, which I thought that TCP/IP would make impossible however, sometimes, it still happens. When it happens I scp the files I need, edit locally and then scp them back.
Having said that do you compress the ssh session that you -X? or is it the latency of the gui response that you are talking about?
My ism, it's full of beliefs.
I'll just note that nobody I know of who runs servers enables X11 on them.
You must be new here.
The worst is the gpg plugin for editing encrypted files in vim. You hit ":wq" and fudge up the password so you get an error "warning the file may be empty" then it quits. Now you have a 0 byte file which wiped out everything. What a stupid design, I have actually lost money due to that shit. This isn't vim's fault per se but it's still fucking broken.
vim is still the best editor though
False his scenarios are as simple as they can get given vim's behaviour.
Regardless of what option you set at command line when you open a file, if that file changes before you exit you get the warning. It doesn't matter if the file was already open and you told vim you want to write to it, it doesn't matter if you were the first person to open the file in write mode.
By the way the warning is white text on a bright red background, has three exclamation marks, has green text underneath it, and you need to answer yes or no. It's not an easy warning to miss.
You CAN run a GUI app over the internet and slowly, painfully peck out letters with latency reminiscent of a cheap 4800 baud modem because typing each letter requires generating and downloading an image of the application.
Or you can work literally a thousand times faster by editing text in text mode.
I'm shocked that anyone knowledgeable enough to know what X forwarding is could also be clueless enough to suggest it's a good way to edit text.
I wish there were more posts like this on Slashdot ^H^H^H^H^H^H^H^H the internet.
> you can compile Vim with only core vi commands
You can compile Vim TO HAVE only core vi commands.
You can compile Emacs WITH only core Emacs commands.
Vim means "vi, improved". Vim is great. Part of why it's great is because vim is a drop-in replacement (upgrade) for vi.
This guy proposes to do the same thing again, another round of improvements. I believe he intends it will still be a drop-in replacement. Nothing will be lost by symlinking "vi" to nvim instead of vim. Everything will still work the same, only faster and more reliably. I see no reason to think it won't be just as smooth as the transition from vi to vim.
I think he should automatically check for four spaces and replace them with a tab. That's a 75% reduction in whitespace size with the same meaning!
The points you mention are the reason why I advocate the use of tabs rather than spaces. I kinda feel like the guys who use spaces don't actually understand what they're doing when they indent, especially if they can't decide how many spaces an indent should be. Tab. One character. Indent.
There's plenty of editors that support opening/saving from/to an SFTP account.
You know lots of Linux/Unix/*BSD systems don't have an X server, right? (Actually the majority of them don't)
And they don't need one--the post you're replying to is suggesting to run the X server on the local machine and run X clients on the remote machine, forwarding the connections over SSH.
I appreciate vim for the same reasons. It's easy to delete entire lines, and I can assign quick keys to short-cut common text (ie, typing class names over and over again).
However, don't forget that many other more-GUI-like editors support drag and drop text and simple clipboard action. You can work pretty fast if you take full advantage of those tools. One of my favorite editors (besides vim/gvim) is part of qt creator. In addition to processing my .vimrc and having a vim mode, it almost always auto-completes code as I am typing it. It has a nice class/member navigation tool, intelligent find and replace, and code refactoring. Yes, vim can do all this too, but this is about as good as it gets for a GUI tool, and it is often faster. Also works different muscles, so it's good for variety on your hands.
As much as I love forwarded X11 apps, its rarely efficient over moderate to slow links. I can't justify using over 1Mbit of uplink traffic just to use my editor over the wire when even a VNC session is more efficient.
1Mbit? Back in the day, we ran X11 over dialup modems, and we liked it. Or at least thought it was semi-OK.
what brad says is good enough for me.
Disallowing tabs is simple to enforce, works with all editors, supports all coding standards and it allows the code to look the same in all text editors and environments.
Tabs have variable sizes depending on editors and environment, so mixed tabs and spaces leads to disasters when people use slightly different setiings, and it's difficult tobenforce that people all use the same settings. It's better to just use spaces as this guarantees the code will look the same everywhere.
It's gonna have the same problems either way. That's why it's so ridiculous and nobody can agree.
Because vim allows you to edit at the speed of thought, that's why. ISBN: 1934356980
Why UNIX?
Do people in fact still argue about vim vs emacs?
I stopped on the day I found myself writing:
vim ~/.emacs
... Though I never have quite forgiven myself.
Crumb's Corollary: Never bring a knife to a bun fight.
A long while back, after getting into Python development, I learned to always use the expand tab option (which always puts in the correct number of spaces to reach the tab stop when you hit tab) and never looked back.
Yes, what you've mentioned is true. But it does not address a single one of the problems _I_ had mentioned, which have to do with workflow and different coding standards from different groups, "Disallowing tabs" can be a reasonable internal coding policy, but the migration to it is likely to be filled with pitfalls, especially if any of your group's code involves older projects or third party code that has to be kept in sync and patch compatible with outside code.
i'm giving courses on an it topic every now and then. at some point, i place basic instructions on screen, with one of them being "change variable n in config file f".
~ 50% of the participants change it in the wrong file (there are only two of them). the exchange goes something like this..
"so what did you modify ?"
- "param n"
"and where did you change it ?"
- "in file x"
"oh, but what do the instructions say ?"
- "to change param n"
"and where ?"
- "in file x" (slight annoyance can be heard here)
"and if we read that sentence till the end?"
- "OH"
Rich
Great point! That's MUCH easier than just using vim on the target ... NOT.
Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
I never said over the internet.. Local LAN only. I would never run X over the internet.
I use VIM daily and find it a very powerful tool. Every couple years I try to write or modify a vimscript plugin and am rediscover the horror that is the vimscript syntax and API. I would really appreciate a more readable script system.
The VIM plugins for browsers no longer work for me. I was using ItsAllText until is stopped working during a distribution or firefox upgrade, I forget which event it was. I would really like an embeddable version of VIM that works more reliably with my browser and any random IDE that I happen to be using.
For these reasons I contributed to the project and I hope it succeeds in forking VIM.
>> If you SSH to a remote host
> xforwarding
!?!?
> local lan only
Yeah, if by "remote" you mean "local", then yes that makes sense.
I have used X forwarding over the internet and for brief periods it IS usable with compression turned on. (Usable in an emergency, or a single brief task etc.) It seems we agree it's not a reasonable workflow for day-to-day text editing.
The only criticism I can think of for vim, and a very significant one, is that there's a very significant learning curve in the beginning. You can learn enough in a couple hours to use it to accomplish whatever you need to do, but then you can spend years learning to tricks to make your work time more productive and more interesting by disposing of the drudgery. Whatever transformation you want done to some text, vim can do it in under a second, but only if you've learned the magic keystrokes.
We need a cloud-based version of vim. Where multiple users can edit simultaneously.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Young un here. I wouldn't touch an ide with a 10 foot pole. I use both emacs and vim combined with command line.
Emacs TRAMP or VI.
I could be wrong, but I think he's saying that you should set up your repository to reject submitted files that contain tabs. I've never done such a thing, but I know you can get SVN to run a script on the file pre-commit. Implement that, and as each file gets checked out the person using it has to convert it before committing again. Easy, they can still check out old files, revision history remains intact, everything is good in the world.
Again, that's applying technology, after the fact, to fix the _workflow_ problem that introduced mixed coding standards. Cleaning up the existing code base, especially for collaborative projects and groups that have distinct standards and refuse to follow each other's layout practices, makes this a very expensive proposition to enforce.
> Easy, they can still check out old files, revision history remains intact, everything is good in the world.
As soon as you do "svn blame" or "git blame" or extract "diff" outputs from revisions before and after the white space synchronization, you've a change tracking difficulty. I'm not saying this is impossible to do, I'm pointing out that it's expensive. It also _breaks_ many revision analysis tools.
You're right, but in the end you can't fix that kind of thing at all. All you can do is try and make your code base cleaner as time goes on. You call it a workflow problem, but the fact is people update coding standards all the time. If you can't use technical means to fix these problems (and you're right, there's very little one can do about how it breaks diffs and such) how are you supposed to fix them? The only 'workflow' answer I can see is "don't do it in the first place" which is like the trivial solution to a calculus problem - true, but not at all useful.
Sucks to be you. The rest of us should be held back because of "deployed embedded systems" because...why, exactly?
It's really not that hard. I've been through it on big projects with extensive history and multiple sync'd outside projects with internal patches and the whole 9 yards.
Start with what you own. If you don't own it, leave it be. Do all files in one big patchset. That'll be the point in time where stuff before and after won't diff very nicely, It sucks, but a year from now, it won't really matter.
Include a per-commit check. That way, no new problems get introduced.
Include the header. One does HAVE to use vim or emacs, but the mode lines I supplied work with those two. If your group has another common editor, add its mode lines if it supports it. It's just a helpful extra, and is safely ignored by other editors. And if none of you use vim or emacs, disregard those lines.
If someone has a branch that was cut prior to the big reformatting patch, they'll have to deal with it at merge, or rebranch or rebase. Sucks, but it's a one time thing.
The alternative sucks more - having code with mixed standards. How do multiple groups deal with that? Your patches are going to be even worse! Someone uses their editor to indent a block or copy/paste it, and all those mixed tables and spaces go to whatever they're using, causing all lines to diff poorly, instead of just the little pieces they touched. It's awful, as you noted.
Your specific problem you referenced was users that were using an outdated 6 year old .vimrc that had been mailed around, and it caused problems with your code because of the difference in coding standards. ADDING THE MODE LINE FIXES THAT!
The rest of it sounds like you just don't want to be bothered to clean up the problem, and just want to complain and blame others. It's trivial to fix. It comes with a small cost (one time giant ugly patchset), but it's easy. And you don't need that one time giant patch.. you could let them be fixed as changes are made, but I wouldn't recommend that as every future patchset will be more complicated than it needs to be. Just get it all out of the way in one go and move on.
For integration with external code/repositories, work within the standard of the governing body. If they have a well defined standard, you can even add the pre-commit checks to your personal repository if you want. In general, this doesn't matter as much as the above, cause either your guys are behaving well and working with the external group, or they're not - manage accordingly.
Wasn't the original editor "ed"? Then someone put a visual interface onto ed.
Vim hasn't been bundled in non-Linux OS'es because of its wacky license. A license is a legal threat that people outside the Linux world take seriously. It isn't a good place to ask for donations for charity. As the result, many people are stuck using nvi. 8~(
--libman
Back in the day you weren't cursed with GUIs made in Gtk+
Yes, there's a pun in there. ;-)
- Michael T. Babcock (Yes, I blog)