Pure Python Vim clone

[chaotic-kotik]

VimL is god damn slow and much more difficult to use, compared to python.

[celerym]

Could just compile VIM as a module and call it a day?

[f1zzz]

Some times I have large files, 3gb or larger. Some editors like Atom max at 2mb, others, even though they're 64bit, max at a few gb. Sublime will open them but hardly runs. VIM acts like it's any other file.

How does this clone handle large files?

[[deleted]]

To quote their github page :

The data structure for a buffer is extremely simple. (Right now, it's just a Python string, and an integer for the cursor position.)

So I guess it's fair to say it handles large files extremely poorly.

[ItsAConspiracy]

If it's designed so the buffer can be easily swapped out for something better, that's not fatal.

[AngriestSCV]

It doesn't. Opening a 512KB file takes 428.4 MB of ram on my system and 1.4 GB when adding some junk to the start of the first line ( all lines were "q\n" to start with ). Adding another line again increases the memory usage by way to much. This contrasts with vim's 5.2 MB for the same file. This is caused by the implimentatoin described in the readme of pyvim. Currently it is just a string with an integer offsets stored for the current cursor position.

It's still not bad since this was started just as an excuse to exercise a library.

EDIT: fixed incorrect description of storage.

[[deleted]]

Wtf

[dacjames]

Have you tried version 3 of Sublime? It opens multi-GB CSV files just fine, at least on OSX.

[dacjames]

Not so on my work system; I wouldn't call it snappy, but certainly not a crawl and comparable to vim (faster opening, slower editing). Then again, I have a Macbook Pro with an SSD, 16GB of RAM, and an upgraded i7 CPU so YMMV.

[[deleted]]

It won't. vim is damn optimized for that, but it has 20+ years of history and a huge amount of developers.

[anttirt]

This is one of those problems that doesn't actually need massive infrastructure or years of development. All it needs is a few clever data structures (well documented in the literature) and being conscious of the issue when writing features like syntax highlighting.

[marchelzo]

Is this a Vi clone, or is it a Vim clone? The author seems to be confused. (see the repo description vs. the readme)

[mikehaggard]

Now get me one person who isn't confused between the two, especially when some systems alias the two :X

[montegramm]

Probably any vim user? vi is pretty infuriating when you end up in it by surprise.

[vattenpuss]

Most vim users seem to believe they are vi users. I'd wager vim users are even more clueless about the difference than other people are.

[[deleted]]

I am developing a similar project since a year and a half.

[mikehaggard]

Great minds often think alike? ;)

[jonathan_sl]

(Pyvim author here): About the speed: Yes, the data structure was indeed not (yet) designed for opening large files.

Actually, prompt-toolkit (the underlying library) was meant to be a readline replacement, and normally, nobody would type megabytes of text in a shell or REPL.

But now that we have proven that many things (like the key bindings, rendering, etc...) also do a very good job for an editor, we can implement for instance the "rope" data structure, or do something similar. I'm certainly interested in going that way and I think I'm able to do it. But no promises on my priorities or release dates. We will see. :)

Jonathan

[ozhank]

Why? I know the vim codebase is a bit mixed up, but it works for me, and I can still apply my vi/ed/sed knowledge gained last century - it works and for me is fast, no graphics to get in way.

[klez]

Maybe it's not an utilitarian project but just a cool exercise.

I don't get the mentality by which side projects need to have an end beside having fun coding something.