Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Neovim: Rebuilding Vim For the 21st Century

timothy posted about 5 months ago | from the vigor-next-to-be-upgraded dept.

Open Source 248

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.)

cancel ×

248 comments

Sorry! There are no comments related to the filter you selected.

Obligatory xkcd, and rirst post (5, Funny)

Anonymous Coward | about 5 months ago | (#46550881)

http://xkcd.com/378/

Re:Obligatory xkcd, and rirst post (0)

fisted (2295862) | about 5 months ago | (#46551157)

Its one of the most retarded and least funny xkcds in existance.

Re:Obligatory xkcd, and rirst post (1)

webmistressrachel (903577) | about 5 months ago | (#46551259)

Hey, it's not that bad, it's strapline does include "sarcasm", after all. This is an ancient debate and deserves a smile or two on this auspicious occasion - modernising vi / vim is a laudable goal.

Think about the comfort and ease of use, if one could use Alt-Gr for the shortcuts in Vim, and ALT-TAB etc. to switch instantly for other GUI apps (SSH, Seamonkey, etc.). A long-awaited blend of the old and the new.

Re:Obligatory xkcd, and rirst post (1)

K. S. Kyosuke (729550) | about 5 months ago | (#46551381)

Even better, this XKCD reference is also a suitable response to the immediately preceding "Creationists Demand Equal Airtime With 'Cosmos'" submission, making this a double first post! (So far, I've only seen one other like that before...)

Re:Obligatory xkcd, and rirst post (0)

Anonymous Coward | about 5 months ago | (#46551495)

There's no shame in admitting you don't get the joke.

Re:Obligatory xkcd, and rirst post (1)

flyneye (84093) | about 5 months ago | (#46551939)

Hardcore guys ride V-twins and run Emacs on their android https://play.google.com/store/... [google.com] .

Re:Obligatory xkcd, and rirst post (1)

funwithBSD (245349) | about 5 months ago | (#46551597)

Perhaps this one is more appropriate:

http://xkcd.com/1343/ [xkcd.com]

Re:Obligatory xkcd, and rirst post (0)

Anonymous Coward | about 5 months ago | (#46551873)

XKCD is never appropriate.

Trivially accomplished (4, Funny)

smitty_one_each (243267) | about 5 months ago | (#46550883)

Re:Trivially accomplished (4, Funny)

iggymanz (596061) | about 5 months ago | (#46550951)

for those who wonder how Stallman could flounder around for 35+ years and not produce a viable OS, look no further than his "editor"

Re:Trivially accomplished (1)

ButchDeLoria (2772751) | about 5 months ago | (#46550981)

Emacs is a great OS, just needs a good editor, etc.

Re:Trivially accomplished (1)

jd2112 (1535857) | about 5 months ago | (#46551041)

for those who wonder how Stallman could flounder around for 35+ years and not produce a viable OS, look no further than his "editor"

It's a fairly complete OS but needs a good editor.

Viper-mode (2)

tepples (727027) | about 5 months ago | (#46551573)

The editor that comes with Emacs is called Viper [emacswiki.org] . Have you tried it?

Re:Trivially accomplished (0)

Anonymous Coward | about 5 months ago | (#46551005)

Thankfully Emacs has a terminal emulator built-in, so you can you combine its news reader and mail client with a *real* editor like nano.

I'll see myself out, thank you.

Re:Trivially accomplished (1)

morcego (260031) | about 5 months ago | (#46551239)

Right... because emacs is a dropin replacement for vim...
Might as well suggest MSWord, Libreoffice or LaTeX.

Re:Trivially accomplished (-1)

Anonymous Coward | about 5 months ago | (#46551435)

LaTeX eh um sistema de tipografia, nao um editor, seu retardado.

There's a reason people argue about vim and emacs (0, Flamebait)

beelsebob (529313) | about 5 months ago | (#46550919)

There's a reason people argue about vim and emacs...

It's because they're BOTH shit.

Re:There's a reason people argue about vim and ema (1)

Jeremi (14640) | about 5 months ago | (#46550941)

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.

Re:There's a reason people argue about vim and ema (-1, Flamebait)

beelsebob (529313) | about 5 months ago | (#46550953)

Good, so you agree with me then, that pouring money into trying to update vim is pointless, and just polishing a turd.

Re:There's a reason people argue about vim and ema (0)

Anonymous Coward | about 5 months ago | (#46551177)

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!!!!!!

Re:There's a reason people argue about vim and ema (5, Informative)

Waffle Iron (339739) | about 5 months ago | (#46551349)

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

Re:There's a reason people argue about vim and ema (0)

Anonymous Coward | about 5 months ago | (#46551649)

I bet his boss used ZZ to exit all the time. It's the vi lazy way to save and exit, no questions asked.

Re:There's a reason people argue about vim and ema (2)

Waffle Iron (339739) | about 5 months ago | (#46551907)

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.

Re:There's a reason people argue about vim and ema (0)

Anonymous Coward | about 5 months ago | (#46550955)

"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?

Re:There's a reason people argue about vim and ema (-1, Troll)

Anonymous Coward | about 5 months ago | (#46550979)

Use an IDE locally and ship the product to the remote host. It isn't 1972 anymore.

Re: There's a reason people argue about vim and em (0)

Anonymous Coward | about 5 months ago | (#46551059)

I'll have you know that vi was written in 1976, mister.

Re:There's a reason people argue about vim and ema (3, Informative)

EvolutionInAction (2623513) | about 5 months ago | (#46551095)

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.

Re:There's a reason people argue about vim and ema (0)

Anonymous Coward | about 5 months ago | (#46551299)

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.

Re:There's a reason people argue about vim and ema (0)

SuperTechnoNerd (964528) | about 5 months ago | (#46550993)

You know you can forward X11 over SSH right?
So the answer is: anything you want, be it GUI or not.

Re:There's a reason people argue about vim and ema (2)

Antique Geekmeister (740220) | about 5 months ago | (#46551073)

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.

Re: There's a reason people argue about vim and em (1)

loufoque (1400831) | about 5 months ago | (#46551233)

You should automatically check for tabs and refuse any commit that uses them.

Re:There's a reason people argue about vim and ema (1)

smitty_one_each (243267) | about 5 months ago | (#46551079)

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.

Re:There's a reason people argue about vim and ema (1)

beelsebob (529313) | about 5 months ago | (#46551051)

You know you can just mount the file system of the remote host by sshfs, right?

Re:There's a reason people argue about vim and ema (0)

Anonymous Coward | about 5 months ago | (#46551077)

pico

Re:There's a reason people argue about vim and ema (1)

Marginal Coward (3557951) | about 5 months ago | (#46551325)

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.

Re:There's a reason people argue about vim and ema (1)

Culture20 (968837) | about 5 months ago | (#46551697)

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.

Re: There's a reason people argue about vim and em (0)

Anonymous Coward | about 5 months ago | (#46551565)

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:-)

Re:There's a reason people argue about vim and ema (1)

Anonymous Coward | about 5 months ago | (#46551019)

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.

Re:There's a reason people argue about vim and ema (1)

Anonymous Coward | about 5 months ago | (#46551063)

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.

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.

Pico (1)

tepples (727027) | about 5 months ago | (#46551797)

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?

Re:There's a reason people argue about vim and ema (1)

wjcofkc (964165) | about 5 months ago | (#46551033)

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.

Re:There's a reason people argue about vim and ema (1)

Marginal Coward (3557951) | about 5 months ago | (#46551293)

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.

formidable task != $10k budget (5, Interesting)

Anonymous Coward | about 5 months ago | (#46550947)

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.

Re: formidable task != $10k budget (2)

loufoque (1400831) | about 5 months ago | (#46551251)

A consulting company would ask 1,000 to 2,000 per day, so 40,000 to 80,000.

Re:formidable task != $10k budget (2, Interesting)

Anonymous Coward | about 5 months ago | (#46551371)

I'm a Brazilian, though I don't live in Recife.

> Is $5000/mo a reasonable sum in Recife, Brazil? Probably.

Agreed.

USD $5,000 is a hefty sum in Brazil to be earned for a month's work, though it's not obscene. Some things are way expensive here (like cars and houses), some are somewhat more expensive (like computers) and some are cheap (like food). We're more or less like an inverted Japan, in economic terms.

From his previous initiatives, the guy seems to belong to a category with few people who could deserve to be that well paid.

He says he has a son; from experience, considering what is involved when one is not single, I'd say he made a good estimate about what he needs for survival while tackling with this project.

> Is 2 months sufficient time to do all he wants to do? I'm not so sure.

Again, agreed.

But then that's the "stone soup" idea: you call people's help to do something which seems impossible and -- whether it's feasible or not -- something wonderful happens as people join in and make the miracle happen. It's one of the most powerful visions if one has ever witnessed such thing and makes one hope we will one day vanquish things like wars.

By the way, others do that but not always with good intentions. At least, he has clear and valid objectives IMHO.

My point here though is that he wants vim to be made more easy to develop, probably because he likes vim a lot. Even if things turn up up harder to do and it takes him one year to finish, maybe we get a richer development ecosystem and a more modular application.

That would be indeed nice.

We are lucky that he wants to do such things, but I'd advise him to pay greater attention to the incoming baby and get a stable position (e.g. in public service) and dedicate less time to free software.

That said, I had to introduce vim at work because notepad is a piece of garbage and now the problem is lay people want to use it. I'm feeling a bit like Prometheus and scared of having to push big stones over mountains.

Re:formidable task != $10k budget (1)

evil_aaronm (671521) | about 5 months ago | (#46551497)

It depends on the circumstances. As you said, without doing anything different, I could survive for about half a year or more on $10k. Think "slow burn." I don't have kids in the house, most of my assets are paid off, including my house, and it's in an economically depressed area, so most stuff, including taxes, is cheap. I can see where $10k wouldn't get you two months, and I've lived like that, but that's not everyone.

Re:formidable task != $10k budget (1)

funwithBSD (245349) | about 5 months ago | (#46551611)

Depends, are you paying me in BitCoins so I don't pay taxes?

I live on just about $5.3K per month, which is what the government lets me keep of my 6 figure income, and I save out of that amount too.

Re:formidable task != $10k budget (1)

funwithBSD (245349) | about 5 months ago | (#46551631)

(that is for a family of 4, btw, not just myself. Much lower burn rate if it was just me, but I like my family =) )

Re:formidable task != $10k budget (0)

Anonymous Coward | about 5 months ago | (#46551539)

Are you really that out of touch with the rest of the world? In many parts of Canada and the USA it is possible to live on $10,000 if one is careful. With a $10k budget I could easily dedicate eight months to a project where I live. Come down out of your gold tower some time and realize much of the world can accomplish a lot on 10k.

Certainly as a fork... good luck (4, Interesting)

inflex (123318) | about 5 months ago | (#46550987)

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.

Re:Certainly as a fork... good luck (0)

Anonymous Coward | about 5 months ago | (#46551107)

300K of scary C89 code? Obviously the developer has never worked on a large operating system codebase then. That is a small codebase.

Re:Certainly as a fork... good luck (1)

jones_supa (887896) | about 5 months ago | (#46551267)

You can still fit a full operating system kernel and a lot more in 300k lines.

Re:Certainly as a fork... good luck (0)

Anonymous Coward | about 5 months ago | (#46551323)

"large operating system codebase"

Re:Certainly as a fork... good luck (1)

jones_supa (887896) | about 5 months ago | (#46551511)

Large operating system codebases are among the biggest codebases on the planet, so of course they are huge. But then again, that includes all kinds of various specialized APIs and a stock of drivers.

Vim's Bram Moolenaar on 'Neovim' (5, Informative)

RDW (41497) | about 5 months ago | (#46550991)

https://groups.google.com/foru... [google.com]

"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."

Re:Vim's Bram Moolenaar on 'Neovim' (1)

wisnoskij (1206448) | about 5 months ago | (#46551249)

It sounds more like a task that the maintainers of VIM should actually be undertaking on the main branch. One step at a time.

Re:Vim's Bram Moolenaar on 'Neovim' (4, Informative)

jjohnson (62583) | about 5 months ago | (#46551303)

what's the gain for the end user exactly?

The origin of the fork is that tarunna submitted two large patches to vim that would have fixed a lot of process management in vim, and was rejected because the current vim codebase is so large and crufty that it's impossible to make major architectural changes to it, like allowing for async process management, just because the risk is too high (especially when there's literally one person, Moolenaar, with a commit bit and thus accepting responsility for every change). And the risk really is very high, I'm not faulting Moolenaar for this.

The gain is that (neo)vim will be able to keep up with current technologies in its plugins (like non-blocking operations), it'll allow plugin authors to write faster plugins by speeding up the plugin architecture, existing plugins will see a speed increase, and other programs will be able to embed vim as an editor rather than hacky "vim keybindings" plugins. Given time and asm.js, it'll run natively within a web browser. None of these were in reach with Moolenaar squatting on the code rejecting risky patches. Sounds like a lot of gains to me.

Re:Vim's Bram Moolenaar on 'Neovim' (1)

Alomex (148003) | about 5 months ago | (#46551837)

As a data point, a while back I peaked into the Vim source code and was amazed at how complicated the code base was. On the other hand I was very impressed with the sophisticated data structures it was using to support large files efficiently.

Re:Vim's Bram Moolenaar on 'Neovim' (0)

Anonymous Coward | about 5 months ago | (#46551319)

A Total Refactoring if done correctly (Use a god damn flowchart) is actually quite useful as not only are they fixing some older bugs but they're solving many of the design flaws to make it far more modular. Hell this was written in C89 and though I see nothing wrong with a 25-30 yr old standard, they could easily move it to a newer version (C11) and take advantage of it's capabilities.

The alternative is to stick with C89 and do what they're doing - refactoring things to fix the many bugs and improve GUI support

Re:Vim's Bram Moolenaar on 'Neovim' (1)

kthreadd (1558445) | about 5 months ago | (#46551365)

The problem with requiring C11 is that a lot of compilers don't support it. C99 support is getting better, but a lot of compilers are still lacking behind.

Have they talked to Bram first? (1)

kthreadd (1558445) | about 5 months ago | (#46550999)

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.

Re:Have they talked to Bram first? (1)

aardvarkjoe (156801) | about 5 months ago | (#46551181)

Apparently Bram has already said that he thinks it's a bad idea.

A lot of the proposed changes are apparently to remove support for "obsolete" systems and configurations. It's really doubtful that it would ever be merged into the main vim codebase.

Re:Have they talked to Bram first? (1)

kthreadd (1558445) | about 5 months ago | (#46551275)

I see. Well, it's going to be interesting to see what comes out of it.

DON'T DO IT! (0)

ToasterTester (95180) | about 5 months ago | (#46551013)

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!!!!

Re:DON'T DO IT! (1)

jjohnson (62583) | about 5 months ago | (#46551309)

Leaving the original alone is what tarruda is doing. Do you not understand how forks work?

Re:DON'T DO IT! (0)

Anonymous Coward | about 5 months ago | (#46551881)

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.

Vi can very often be found, but Vim does not usually come preinstalled.

Broken link (1, Funny)

gentryx (759438) | about 5 months ago | (#46551093)

You can download the successor to vim [gnu.org] here. FTFY.

Re:Broken link (2)

koinu (472851) | about 5 months ago | (#46551983)

Well, there is no successor to vim without saying that it sucks.

Never understood the modes (0)

jones_supa (887896) | about 5 months ago | (#46551105)

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?

Re:Never understood the modes (3, Insightful)

chispito (1870390) | about 5 months ago | (#46551159)

If you don't care for the modes, why do you still use VIM? I'm sure there are better suited editors to your preferences.

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?

Re:Never understood the modes (1)

jones_supa (887896) | about 5 months ago | (#46551201)

Not necessarily.

Because it's smaller on embedded (1)

tepples (727027) | about 5 months ago | (#46551835)

If you don't care for the modes, why do you still use VIM?

This anonymous poster [slashdot.org] 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.

Re:Never understood the modes (5, Interesting)

zippthorne (748122) | about 5 months ago | (#46551195)

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? [viemu.com] makes a pretty reasonable argument.

Re:Never understood the modes (1)

jones_supa (887896) | about 5 months ago | (#46551283)

Interesting article, have to read that one.

Re:Never understood the modes (1)

fisted (2295862) | about 5 months ago | (#46551241)

because then we arrive at emacs with its retarded hard-to-type and strain-inducing keychords, like Escape Meta Alt Control Shift

Re:Never understood the modes (2)

RabidReindeer (2625839) | about 5 months ago | (#46551247)

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.

Re:Never understood the modes (0)

Anonymous Coward | about 5 months ago | (#46551261)

If you think that vim would be faster by using the control or arrow keys, you're doing it wrong. I know that sounds like a glib throwaway line, but it's true: you're doing it wrong. The idea with vim is that you keep your hands on the keyboard in the natural typing position as much as possible - not reaching for the control or arrow keys.

Re:Never understood the modes (1)

dubbayu_d_40 (622643) | about 5 months ago | (#46551803)

Yes, this.

Re:Never understood the modes (1)

fph il quozientatore (971015) | about 5 months ago | (#46552029)

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.

Re:Never understood the modes (1)

fisted (2295862) | about 5 months ago | (#46551289)

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.

Re:Never understood the modes (1)

fisted (2295862) | about 5 months ago | (#46551301)

the (or Ctrl+[, as you seem to like keychords) to [...]

the <Esc> (or Ctrl+[, as you seem to like keychords) to [...]

FTFM

Re:Never understood the modes (1)

jjohnson (62583) | about 5 months ago | (#46551335)

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

inoremap jj <ESC>

to your .vimrc. Hit jj quickly when you're done typing, and you're back to normal mode

Re:Never understood the modes (1)

Waffle Iron (339739) | about 5 months ago | (#46551469)

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.

Re:Never understood the modes (1)

jones_supa (887896) | about 5 months ago | (#46551559)

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.

Re:Never understood the modes (1)

Waffle Iron (339739) | about 5 months ago | (#46551657)

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.

You know it's time to modernize a program (1)

JoeyRox (2711699) | about 5 months ago | (#46551117)

When the primary forum for discussion of said program is still on usenet.

Re:You know it's time to modernize a program (1)

fisted (2295862) | about 5 months ago | (#46551307)

Please, discontinue your AOL.

Full blown vim in a good IDE:one of my dreams (5, Interesting)

rabbin (2700077) | about 5 months ago | (#46551155)

Vim has to be one of my favorite programs but I rarely use it for any "ambitious" coding project because it lacks critical features that an IDE provides (the plugins don't cover these gaps either). Right now I'm using Netbeans with the jVi plugin (provides a subset of common vim behavior) for c++ programming and it works well, but if an IDE plugin could simply embed instances of vim into the program itself and have it work seamlessly with the existing IDE features (e.g. advanced code understanding of inheritance hierarchies and type deduction) that would be the ideal. With this in mind, the following from the website sounds really promising:

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.

Great. Why? (0)

Anonymous Coward | about 5 months ago | (#46551161)

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!

sdsdsdfsdfasdf (0)

Anonymous Coward | about 5 months ago | (#46551197)

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...

Re:sdsdsdfsdfasdf (1)

kthreadd (1558445) | about 5 months ago | (#46551287)

Vim has had a GUI for quite some time now, since 4.0 or so. It's called gVim and it's actually good.

improve the scripting language (1)

stenvar (2789879) | about 5 months ago | (#46551217)

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.

Re:improve the scripting language (0)

Anonymous Coward | about 5 months ago | (#46551427)

Actually, the plan is to compiler 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. 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 earlier. I have high hopes for this project, it's got great momentum.

ChipWhisperer: An Open-Source Platform for Hardwar (-1)

Anonymous Coward | about 5 months ago | (#46551305)

ChipWhisperer: An Open-Source Platform for Hardware Embedded Security Research

- Document (PDF): http://cryptome.org/2014/03/ch... [cryptome.org]
- View PDF online: http://view.samurajdata.se/ [samurajdata.se]

Partial quote from 1st page (1/18):

"This paper introduces a complete side channel analysis toolbox inclusive of the analog capture hardware, target device, capture software, and analysis software. The highly modular design allows use of the hardware and software with a variety of existing systems. The hardware uses a synchronous capture method which greatly reduces the required sample rate, while also reducing the data storage requirement and improving synchronization of traces. The synchronous nature of the hardware lends itself to fault injection, and a module to generate glitches of programmable width is also provided. The entire design (hardware and software) is open-source, and maintained in a publicly available repository. Several long example capture traces are provided for researchers looking to evaluate standard cryptographic implementations."

Keywords: side-channel analysis, acquisition, synchronization, FPGA

Just saying (0)

Anonymous Coward | about 5 months ago | (#46551421)

In my days kids did this for free.

Get off my lawn (0)

Anonymous Coward | about 5 months ago | (#46551431)

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 (0)

Anonymous Coward | about 5 months ago | (#46551451)

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).

A fork of vim? (1)

peppepz (1311345) | about 5 months ago | (#46551635)

Does this classify as heresy or as a schism?

Integration with modern graphical interfaces? (0)

Anonymous Coward | about 5 months ago | (#46551933)

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 : ?

As a VIM lover ... (0)

Anonymous Coward | about 5 months ago | (#46552019)

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.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>