3 ms·

Curious, want to try it yourself before you flame it to death for being in python 2 or claiming to be remotely plausible as a vim substitute? git clone https

Curious, want to try it yourself before you flame it to death for being in python 2 or claiming to be remotely plausible as a vim substitute? git clone https://github.com/iogf/vy cd vy virtualenv . ./bin/pip install untwisted pygments ./bin/python setup.py install You'll probably want to edit /vyapp/plugins/toggle_mode.py to use a KeyPress binding that is valid for your platform at this point, or you'll get: _tkinter.TclError: bad event type or keysym "Apostrophe" ...and finally, ./bin/vy Right, now you can start playing wading your way through https://github.com/iogf/vy/blob/master/INTRO.md https://github.com/iogf/vy/blob/master/INTRO.md and try to understand the command syntax. Good luck! Vim clones are a dime a dozen; this is actually an entirely different thing, and although I can't imagine actually using it for anything... it's interesting to see people work on different approaches to text editors. A simple hackable python text editor may not be useful in the long term for anything (for all the reasons about distributing python and python performance limitations), but its certainly viable for prototyping interesting features.

jdimov9 11y ago
Tell me again about those "python performance limitations".
- dbbolton 11y ago
  Devil's advocate: relative to C (which vim is written in), Python 2 is considerably slower, especially with CPython as its interpreter. Optimization is also tougher. Personally, I admit I'm not sure that the difference is significant for this particular project.
  - Skunkleton 11y ago
    Honestly, python might perform better overall. Not because C is slower than python (ha), but because python probably outperforms vim script. Especially likely because vim plug-ins can be fairly complex.
    - duaneb 11y ago
      The actual operations on text buffers are going to be the hardest part to implement in python performantly.
      - alexchamberlain 11y ago
        They're the bits you could push down to C and/or use one of many jiting options.
        duaneb 11y ago
        Sure. But at that point, why not just python script vim?
        shadowmint 11y ago
        Realistically this is like saying you could rewrite git in python and just push the hard bits down into C; the problem is that you end up writing a significant portion of both the core, and plugins, in C. When you're writing all of the main parts of the editor in C, at this point, why are you using python at all?
        alexchamberlain 11y ago
        I'm not necessarily defending the rewrite here, but writing something like git in Python, profiling then optimising the parts that are slow doesn't sound like a bad idea.
- coldtea 11y ago
  What do you want to know? There are plenty when it comes to hard number crunching. And no branching out to C, or Cython or Fortran like Numpy is not the same as Python not having those limitations.
  - icebraining 11y ago
    There are plenty when it comes to hard number crunching. Not exactly relevant for a text editor, though.
    - coldtea 11y ago
      You'd be surprised. All editors written in scripting languages I've suffer get to their knees for larger files (sometimes even 10MB or so, even more so for really large ones), as stuff like highlighting, parsing etc gets CPU bound soon.
    - andrepd 11y ago
      You need look no further than Atom: a "hackable" text editor that brings mighty computers to their knees in order to display a text file. That's not acceptable to me, even though it would be nice to have a hackable to the core editor. But we already have emacs for that, I suppose...
      - nilliams 11y ago
        To be fair, only very large text files trouble Atom. And when does any dev ever actually open massive text files in text editors. I'm a Vim guy and have only briefly tried Atom, but I still wouldn't dream of opening a huge text file in Vim, even though it would cope a lot better than Atom. If it's a log file or something I'm going to be using tail/grep etc. to deal with it. Yeah exactly emacs is hackable if you want to write lisp, which has a very small audience. So sure there is absolutely a desire for an editor written in a 'nice', hackable language like Python or JS (forgive me JS haters) to prosper.
        comex 11y ago
- shadowmint 11y ago
  You can write C, and pretend its python, but if you're writing C, why are you pretending your project is written in python? Text editors are surprisingly demanding; they require complex bulk operations like search, replace and per word highlighting, which is not inconsiderable in magnitude. Ever tried open a 100MB log file in vim? Now try that in atom... and javascript is easily a magnitude or more faster than pure python. I work with python and love it; its hackable, fun to write. ...but fast it is not.

jdimov9 11y ago

Tell me again about those "python performance limitations".

dbbolton 11y ago
Devil's advocate: relative to C (which vim is written in), Python 2 is considerably slower, especially with CPython as its interpreter. Optimization is also tougher. Personally, I admit I'm not sure that the difference is significant for this particular project.
- Skunkleton 11y ago
  Honestly, python might perform better overall. Not because C is slower than python (ha), but because python probably outperforms vim script. Especially likely because vim plug-ins can be fairly complex.
  - duaneb 11y ago
    The actual operations on text buffers are going to be the hardest part to implement in python performantly.
    - alexchamberlain 11y ago
      They're the bits you could push down to C and/or use one of many jiting options.
      - duaneb 11y ago
        Sure. But at that point, why not just python script vim?
      - shadowmint 11y ago
        Realistically this is like saying you could rewrite git in python and just push the hard bits down into C; the problem is that you end up writing a significant portion of both the core, and plugins, in C. When you're writing all of the main parts of the editor in C, at this point, why are you using python at all?
        alexchamberlain 11y ago
        I'm not necessarily defending the rewrite here, but writing something like git in Python, profiling then optimising the parts that are slow doesn't sound like a bad idea.
coldtea 11y ago
What do you want to know? There are plenty when it comes to hard number crunching. And no branching out to C, or Cython or Fortran like Numpy is not the same as Python not having those limitations.
- icebraining 11y ago
  There are plenty when it comes to hard number crunching. Not exactly relevant for a text editor, though.
  - coldtea 11y ago
    You'd be surprised. All editors written in scripting languages I've suffer get to their knees for larger files (sometimes even 10MB or so, even more so for really large ones), as stuff like highlighting, parsing etc gets CPU bound soon.
  - andrepd 11y ago
    You need look no further than Atom: a "hackable" text editor that brings mighty computers to their knees in order to display a text file. That's not acceptable to me, even though it would be nice to have a hackable to the core editor. But we already have emacs for that, I suppose...
    - nilliams 11y ago
      To be fair, only very large text files trouble Atom. And when does any dev ever actually open massive text files in text editors. I'm a Vim guy and have only briefly tried Atom, but I still wouldn't dream of opening a huge text file in Vim, even though it would cope a lot better than Atom. If it's a log file or something I'm going to be using tail/grep etc. to deal with it. Yeah exactly emacs is hackable if you want to write lisp, which has a very small audience. So sure there is absolutely a desire for an editor written in a 'nice', hackable language like Python or JS (forgive me JS haters) to prosper.
      - comex 11y ago
shadowmint 11y ago
You can write C, and pretend its python, but if you're writing C, why are you pretending your project is written in python? Text editors are surprisingly demanding; they require complex bulk operations like search, replace and per word highlighting, which is not inconsiderable in magnitude. Ever tried open a 100MB log file in vim? Now try that in atom... and javascript is easily a magnitude or more faster than pure python. I work with python and love it; its hackable, fun to write. ...but fast it is not.