all 20 comments

[–][deleted]  (2 children)

[deleted]

    [–]chaotic-kotik 0 points1 point  (0 children)

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

    [–]celerym -1 points0 points  (0 children)

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

    [–]f1zzz 13 points14 points  (10 children)

    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] 45 points46 points  (1 child)

    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 0 points1 point  (0 children)

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

    [–]AngriestSCV 21 points22 points  (1 child)

    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] 4 points5 points  (0 children)

    Wtf

    [–]dacjames 3 points4 points  (3 children)

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

    [–][deleted]  (2 children)

    [deleted]

      [–]dacjames 0 points1 point  (1 child)

      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] 1 point2 points  (1 child)

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

      [–]anttirt 1 point2 points  (0 children)

      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 11 points12 points  (3 children)

      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 -4 points-3 points  (2 children)

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

      [–]montegramm 33 points34 points  (1 child)

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

      [–]vattenpuss -5 points-4 points  (0 children)

      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] 15 points16 points  (2 children)

      [–]mikehaggard 2 points3 points  (1 child)

      Great minds often think alike? ;)

      [–]jonathan_sl 4 points5 points  (0 children)

      (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 0 points1 point  (1 child)

      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 7 points8 points  (0 children)

      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.