Vy – A Vim-like in Python made from scratch(github.com)
github.com
Vy – A Vim-like in Python made from scratch
https://github.com/iogf/vy
74 comments
Tell me again about those "python performance limitations".
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.
Personally, I admit I'm not sure that the difference is significant for this particular project.
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.
The actual operations on text buffers are going to be the hardest part to implement in python performantly.
They're the bits you could push down to C and/or use one of many jiting options.
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?
When you're writing all of the main parts of the editor in C, at this point, why are you using python at all?
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.
Sure. But at that point, why not just python script vim?
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.
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.
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.
And no branching out to C, or Cython or Fortran like Numpy is not the same as Python not having those limitations.
There are plenty when it comes to hard number crunching.
Not exactly relevant for a text editor, though.
Not exactly relevant for a text editor, though.
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.
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...
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...
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.
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.
Depends on your definition of huge. On my computer, vim takes about a second to load a 100MB text file, 1.4 million lines - not as fast as less (although less's search feature is slower). Vy's slower but it appears to load the file asynchronously, so at least you can start browsing while it's doing that. But 100MB is fifty times the sibling comment's 2MB for Atom...
For the record, while Python's pure interpreter is always going to be slow at this type of thing, JS's overhead factor compared to C is small enough that it's certainly possible to write an editor in it that feels just as fast as vim - maybe faster in some cases, e.g. since JavaScript engines JIT compile regexes and C regex libraries generally don't, or by making relatively slow operations asynchronous/multithreaded (while vim is highly synchronous). Atom seems to be just badly designed.
For the record, while Python's pure interpreter is always going to be slow at this type of thing, JS's overhead factor compared to C is small enough that it's certainly possible to write an editor in it that feels just as fast as vim - maybe faster in some cases, e.g. since JavaScript engines JIT compile regexes and C regex libraries generally don't, or by making relatively slow operations asynchronous/multithreaded (while vim is highly synchronous). Atom seems to be just badly designed.
>Atom seems to be just badly designed.
I think the problem with Atom speed is using the DOM / web stack, not Javascript itself.
I think the problem with Atom speed is using the DOM / web stack, not Javascript itself.
Atom's filesize limit is 2MB, so it's not really 'massive.' When I was using it, I ran into that limit more often than I would have expected. Mostly when taking a peak at a db dump, or misc files from the odd CTF challenge.
> [..] on top of tkinter which is one of the most productive graphical toolkits.
> ..
> [..] on top of Tkinter that is such a great graphical toolkit.
Right. About as great as pulling teeth. Not that there's many alternatives, of course...
> ..
> [..] on top of Tkinter that is such a great graphical toolkit.
Right. About as great as pulling teeth. Not that there's many alternatives, of course...
Tkinter actually isn't _that_ bad. I've written several fairly large applications with it. You have to re-invent the wheel for several things due to its limited number of "widgets". It used to look very non-native, but that's been largely fixed. Other than that, though, it has a worse reputation than it deserves.
Sure, I'd rather use Qt for something large, but honestly, for a quick-and-dirty gui, it's hard to beat Tk. You can get something reasonably nice looking (at least with recent versions) and reasonably cross-platform very quickly.
Sure, I'd rather use Qt for something large, but honestly, for a quick-and-dirty gui, it's hard to beat Tk. You can get something reasonably nice looking (at least with recent versions) and reasonably cross-platform very quickly.
What sorts of widgets are missing that you are wishing (no pun intended) for.
Yay, puns! :)
The first thing that comes to mind are help tooltips (a.k.a. balloons). There are a few third-party libraries, but none of them that I'm aware of get it quite right (especially for tooltips on menu items).
There are couple of other common widgets as well, but I'm having trouble thinking of them at the moment.
At any rate, there aren't too many (and ttk helps immensely in this regard), but it's something you miss coming from Qt.
On the other hand, being able to put a minimal, but very usable gui together with just a few lines of code is a real strength of Tcl/Tk. (Though I usually use Python+Tkinter as I tend to write scientific applications.) There's a lot to be said for the right level simplicity vs batteries-included.
The first thing that comes to mind are help tooltips (a.k.a. balloons). There are a few third-party libraries, but none of them that I'm aware of get it quite right (especially for tooltips on menu items).
There are couple of other common widgets as well, but I'm having trouble thinking of them at the moment.
At any rate, there aren't too many (and ttk helps immensely in this regard), but it's something you miss coming from Qt.
On the other hand, being able to put a minimal, but very usable gui together with just a few lines of code is a real strength of Tcl/Tk. (Though I usually use Python+Tkinter as I tend to write scientific applications.) There's a lot to be said for the right level simplicity vs batteries-included.
Yeah, I chuckled a little bit when I read this. I suspect that either the author uses English as a second language, or the author is on the young side and enthusiastic.
Tkinter is not a top GUI toolkit, but I use it all the time because it is built in to Python and requires no libraries. This is very valuable in my job. Thankfully it is fairly well documented and perfectly capable of useful desktop interfaces.
Tkinter is not a top GUI toolkit, but I use it all the time because it is built in to Python and requires no libraries. This is very valuable in my job. Thankfully it is fairly well documented and perfectly capable of useful desktop interfaces.
Tk in 2015! its alive!!
> The source code of the syntax highlighting plugin is about 80 lines of code.
Which is not that big of an achievement considering it depends on pygments for syntax highlighting...
Which is not that big of an achievement considering it depends on pygments for syntax highlighting...
I don't believe Bram said it would replace vim I think he took something out of context.
"I'm working on a ncurses based library with a symmetrical archicture to python tkinter". That sounds nice.
I'd suggest don't work trying to replace vim in the future. Work to learn and to fix any necessity that by some reason vim is not fulfilling for you. Then the world will say...
The project has a good architecture (plugins seem interesting). But it could use some tidying up.
I'd suggest don't work trying to replace vim in the future. Work to learn and to fix any necessity that by some reason vim is not fulfilling for you. Then the world will say...
The project has a good architecture (plugins seem interesting). But it could use some tidying up.
> it could use some tidying up.
def beta(area):
print 'shit'
area.chmode('BETA')Looks interesting but why not Python 3.x?
Because there is no good reason to use 3.x and 2.x is the natural choice that makes perfect sense?
For text editor specifically I'd imagine the improved Unicode/bytestring handling would be a benefit.
Why is 2.x the "natural choice"? I'm not saying it's a bad choice, but you seem to be treating it as a given.
Enormous install base.
There are many good reasons to use 3.x
> a great chance to substitute vim in the future.
Presumably because of its modularity and extensibility. He was probably right, just look at Neovim.
Hm, maybe. I quite like the look of 'plugins', even the vi-ness is handled by one. But it seems a strange thing to say in the readme - it's clearly a long way off being close to a contender.
Sometimes, to attract attention, you need to say things that will get people riled up.
Bram Moolenaar is supposedly the author of that statement, which makes it more so relevant.
The keys are bound in the plug-in, and that's it. The (very partial) functionality of vi isn't actually present or implemented there.
Also: the modularity and extensibility doesn't come at the expense of vim's traditional portability: Python 2.7 is a fairly low baseline for Unix servers.
i don't think so
Interesting project. Vim is riddled with issues and we badly need a replacement (coming from a dedicated Vim user). Currently VimR and NeoVim are in the lead for tackling some of the hard problems (async calls, a real plugin system, obvious features like fuzzy finder with good UI integration, etc).
I found this part amusing: "What did Bram Moolenaar say". After using Vim for a few years, and seeing his design choices, I wouldn't personally be interested in his opinion of an editor!
I found this part amusing: "What did Bram Moolenaar say". After using Vim for a few years, and seeing his design choices, I wouldn't personally be interested in his opinion of an editor!
Hm, why do most of his files end with 10 to 15 blank lines of whitespace? Is that a thing or was he just sloppy?
I don't think it's "common", but people do it so they can scroll to the last line and have it appear near the top of the page. It's a matter of personal preference. Some editors allow you to scroll that far without the extra lines, many don't.
What editors don't do that? I'm only familiar with Emacs and Sublime which do. I'd hate to use an editor that didn't. Hopefully he added that functionality to Vy :)
In vim, j and k will only move the cursor between lines that exist, and the screen will follow the cursor. You can scroll the screen past the end of the file using ctrl+e and ctrl+y, but it's annoying.
Vim does by default, which he seems to use judging by the .swp files present in git..
A few examples of editors that don't: Notepad++, ATOM, Nano, etc.
Am I wrong in thinking that this is a Tk Text widget (or possibly several), with a selection of functions atop? Plugins for the most part are just key press callbacks which manipulate this Text widget and associated state?
I know every project must start somewhere but this doesn't seem to have considerable substance for a purported next gen vi(m), and given its heavy reliance on pre-made tools (like text areas), without much abstraction, it seems like it would be hard to get over the hump to make it competitive with existing editors.
I know every project must start somewhere but this doesn't seem to have considerable substance for a purported next gen vi(m), and given its heavy reliance on pre-made tools (like text areas), without much abstraction, it seems like it would be hard to get over the hump to make it competitive with existing editors.
Looks similar to http://www.vixn.org/
Some of the cleanest code I've seen! Pretty fun skimming through files and functions.
There's lots of field mutation in the assortment of classes and functions with no documentation. Also lots of stuff that resembles this:
for ind in chain:
val = execute(ind, event)
if val == True: opt = True
elif val == False: opt = False
return optpyvim (https://github.com/jonathanslenders/pyvim) is also a pretty slick vim clone in python that uses the python prompt toolkit (https://github.com/jonathanslenders/python-prompt-toolkit)
Q
Why Python?
A
The only alternative would be Haskell, but I still have to learn that.
relevant: https://github.com/yi-editor/yi
this is cool.
https://youtu.be/HXvjh1p7gSY
zephod(3)
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:
...and finally,
Right, now you can start playing wading your way through 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.