r/programming • u/omegaender • Apr 26 '15

Pure Python Vim clone

https://github.com/jonathanslenders/pyvim
97 Upvotes

80% Upvoted

20 comments sorted by

13

u/f1zzz Apr 26 '15

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?

46

u/[deleted] Apr 26 '15

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.

1

u/ItsAConspiracy Apr 27 '15

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

23

u/AngriestSCV Apr 26 '15 edited Apr 26 '15

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.

3

u/[deleted] Apr 27 '15

Wtf

4

u/dacjames Apr 26 '15

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

0

u/[deleted] Apr 27 '15

[deleted]

1

u/dacjames Apr 27 '15

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.

3

u/[deleted] Apr 26 '15

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

2

u/anttirt Apr 27 '15

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.

13

u/marchelzo Apr 26 '15

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

-1

u/mikehaggard Apr 26 '15

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

32

u/montegramm Apr 26 '15

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

-4

u/vattenpuss Apr 27 '15

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.

17

u/[deleted] Apr 26 '15

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

5

u/mikehaggard Apr 26 '15

Great minds often think alike? ;)

4

u/jonathan_sl Apr 27 '15

(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

1

u/ozhank Apr 27 '15

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.

7

u/klez Apr 27 '15

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.

0

u/[deleted] Apr 27 '15

[deleted]

1

u/chaotic-kotik Apr 27 '15

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

0

u/celerym Apr 27 '15

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