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
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.
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."
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.
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?
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.
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.
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.
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?
The Daddy casts sleep on the Baby. The Baby resists!
Vim isn't about typing. It's about manipulating text. Some of which involves typing and that's why it has insert mode, but a lot of it is about finding your place in a document or moving one block of text from one area to another area, or changing all of something into something else according to a pattern, and you can do all of this without taking your hands off of the keyboard.
Why, oh WHY, do those #?@! nutheads use vi? makes a pretty reasonable argument.
Can you be Even More Awesome?!
Not necessarily.
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.
because then we arrive at emacs with its retarded hard-to-type and strain-inducing keychords, like Escape Meta Alt Control Shift
CLI paste? paste.pr0.tips!
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?
Vi was originally designed to run over a very slow modem - say 300 baud over a device with minimal keyboard (no arrow/cursor keys).
Once an editor gains a certain degree of power, you run out of Ctrl+ keys.
My gripe with the vi approach is that it assumes that commands are the rule and text entry is the exception. Most other editors - including the ones I grew up with - are of the opposite point of view.
Interesting article, have to read that one.
Vim has had a GUI for quite some time now, since 4.0 or so. It's called gVim and it's actually good.
Oh and for the record, you shouldn't frequently "jump between modes".
The general idea is that you stay in Normal Mode (what you called 'command mode'). Insert mode is only ever entered temporarily, for short bursts of input; the (or Ctrl+[, as you seem to like keychords) to go back to Normal Mode should become second nature. You should never have to ask yourself "What mode am I in, right now?".
Visual mode, OTOH, is rarely a mode to switch to (one exception would be the rectangle-select (Ctrl+Shift+V)). If you frequently need it, chances are you are simply missing some canonical way of doing whatever you attempt to do in visual mode.
CLI paste? paste.pr0.tips!
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.
the (or Ctrl+[, as you seem to like keychords) to [...]
the <Esc> (or Ctrl+[, as you seem to like keychords) to [...]
FTFM
CLI paste? paste.pr0.tips!
Leaving the original alone is what tarruda is doing. Do you not understand how forks work?
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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.
You're doing it wrong... as I was, until someone pointed out that command mode is normal mode. You don't sit in insert mode and jump to command mode, you sit in command mode, manipulating text and moving around, switch into insert mode to add text, and then immediately switch back to command.
Once you get used to doing that, vim suddenly makes a ton more sense, and you start using the keystroke combos to do things much more quickly than before. And the secret to jumping easily from insert to command mode is to add
to your .vimrc. Hit jj quickly when you're done typing, and you're back to normal mode
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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
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?
If you have any issues with RSI, then vim is by far the best editor (especially the GUI mode version).
The command mode allows you to formulate in your mind what you want to do, and accomplish it in the minimum possible key strokes. This is important because your brain won't wear out like your joints and tendons can. The command mode usually allows you to specify repeat counts to avoid repeatedly mashing keys. It lets you make common text selections such as words, nested brackets, statements, etc with a couple of key strokes. It also allows you to create macros on the fly and repeat previous commands further cut down on repetition.
I find that reaching for the arrow keys puts my wrists at an awkward angle which induces more stress. Having to pound on them repeatedly while holding down various combinations of control keys makes things worse. (To address a common complaint with vim, I've added a mapping of Alt+F to ESC, so I don't have to reach up for that key if I don't want to.)
I probably spend more time in command mode than insert mode when I'm using vim to write code. That says to me that keeping an editor always stuck in insert mode may not be the best idea.
I probably spend more time in command mode than insert mode when I'm using vim to write code. That says to me that keeping an editor always stuck in insert mode may not be the best idea.
It's not that bad idea. After all, insert mode is where most of the actual code writing happens.
The editor that comes with Emacs is called Viper. Have you tried it?
Does this classify as heresy or as a schism?
Not really. Most code is highly repetitive, and I typically copy far more words than I type out. I use various shortcuts to create most of the common syntax constructs of the languages that I use.
Moreover, developing software is usually an iterative process, where more effort is spent on revising the code than on entering it.
My whole point was that normal mode is far more powerful than insert mode, and it allows you to accomplish many tasks with a small fraction of the typing you would need with only insert mode.
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?
Yes, this.
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.
The "natural typing position" should be JKL;, not HJKL. That's why all keyboards have a tactile hint on the F and J keys. This is even more relevant for a programmer, who uses lots of symbol keys from the right part of the keyboard.
My first program:
Hell Segmentation fault
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.
You don't know how to use vi(m) then.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
You can switch to Joe's Own Editor: Joe 3.7
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
'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.
After many years of playing with computers, I have recently started learning to use vim, but one thing always drives me crazy.
I have never figured out how to insert one single character at the current cursor position. Replacing one character is easy (r) but how do I insert one? Example: somthing. What's the easiest way to get the missing e into that word?
If you're a zombie and you know it, bite your friend!
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)
That's called emacs. Go try it.
The rest of us like knowing that when we're in insert mode, nothing we type will be interpreted as anything but data -- unless we hit ESC.
- Michael T. Babcock (Yes, I blog)
Personally speaking, hitting 'i', 'e', 'esc' isn't that hard. I'm much more likely in those cases to have run the text through spell check and fold with 'v' and '!'.
- Michael T. Babcock (Yes, I blog)
That's called emacs. Go try it.
I have tried Emacs but the multi-level commands made me nauseous.
The rest of us like knowing that when we're in insert mode, nothing we type will be interpreted as anything but data
What value is there knowing that? You're just typing text and letters appear on the screen.
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
That only makes sense in some bizarro world where your primary use of a text editor isn't adding text.
I'm not sure what development you do, but I'm not really that good at cutting and pasting blocks of text to create entirely new works.
I find it odd that you think its perfectly acceptable to spend most of your time in your editor not adding text, but rather fiddling with it and moving it around.
I'm fairly certain that you're doing it wrong. The guy you're replying to may be as well, but if you spend more time in command mode than insert mode I just can't see that you're really getting that much done. Do you copy and paste individual letters or something?
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
Not really. Most code is highly repetitive, and I typically copy far more words than I type out.
You're doing it wrong, thats the problem.
If you're continually copy and pasting code to reuse it, you are most certainly doing it epically wrong.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
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
Start using alt+... to escape insert mode instead of going all the way over to the escape key. This allows you to make small insert operations repeatedly with very little delay between them.
Your scenarios are way too complicated. It's simple as this: the boss didn't open the files in readonly mode.
If I'm entering a lot of text, then I'll stay in insert mode, typing away, backspacing to delete and tabbing to indent if auto-indent doesn't do it right. What you're missing is that most software development isn't about entering text. It's about reading existing code to understand the landscape, it's about refactoring code by moving chunks around or renaming things or adding comments here and there, it's about searching and finding, it's about structuring the code or grasping that structure. Unless you're the kind of prodigy who just starts typing and then stops when it's done perfectly the first time, then you're likely doing it too, you're just using the mouse a lot or hitting the cursor keys way more than you have to.
If the quality of your code matches the quality of your insights here, I feel bad for your employer.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
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.
I'm not copying and pasting. I'm using things like Ctrl-P to do code completion without having to type out the full name. Maybe I shouldn't have used the term "copy".
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
Why can't we just be in insert mode constantly and use Ctrl+something for all the commands
CTRL-O is your friend.
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.
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.
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.
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.
This "natural typing position" thing has always bothered me.
I tend to shift over to HJKL while editing code, and then shift back to JKL; when writing an email... I think I'd be faster if I could stick with just one.
thoughts?
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.
Because most of the commands accept modifiers, e.g. 10dd to remove 10 lines of text, or }d to delete the rest of the paragraph. Because more complex commands are multiple keystrokes what you suggest would involve typing while holding down the ctrl key - it is easier to hit a key once to enter/exit the mode. For selecting text in vim you can do shift-v and then then select a text range with the cursor keys (or any other movement command).
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
Because most of the commands accept modifiers, e.g. 10dd to remove 10 lines of text, or }d to delete the rest of the paragraph.
All right, I think I've seen enough at this point. I'm leaving Vim-land right now and moving all my programming projects to Visual Studio 2013.
Fear not, there is probably a wizard to do that for you.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
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?
In my view, the fact that VI uses the wrong home keys (or at least, different home keys than all keyboard manufacturers and the rest of the world) is *bad*. It is a relic of ancient 1970s terminals that would better be changed.
My first program:
Hell Segmentation fault
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.
>> 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.
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.
You can. It's call "easy" mode. Just add a "-y" option.
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.
A lot of non-US keyboards have the semicolon key in a different location. For instance, on my (Danish) keyboard, semicolon is typed using shift-comma.
Bram chose HJKL because they're always on the same place on every standard keyboard, apart from Dvorak (but Dvorak sucks anyway).
Eat the rich.
You're looking for Cream for Vim.
There is no need to use a SlashDot sig for SEO...
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)