That'd make sense. Written in python, for python (at least initially) since the author likes python :-) Looks like a neat start to a new project. The built-in IRC client made me chuckle, though.
I doubt you will notice much during regular editing. I once wrote a text editor in chibi scheme which I would estimate to be slower than python,and it was snappy despite doing all redraws and such itself.
What you will notice is of course the GIL. Once any plugin starts doing enough work there will be noticeable lag unless Vy supports plugins using multiprocess python.
I have been toying with writing an editor in guile scheme and despite using _very_ suboptimal data structures and algorithms everything is instant up until maybe 10 simultaneous cursors in a 30kb file.
Due to the shitty implementation (really just a first draft), that was actually creating a new buffer for every insert.
Isn't atom single process? I don't recall any plugins ever seriously hogging it out. Sure you can't get paralleism with the GIL but you can still get concurrency. It's not like these things weren't doable before we got multicore machines. Just requires sensible plugin design.
Edit: Emacs is a great example btw. It is single threaded, and a lot of it is written in elisp, which is slow and makes emacs have noticeable lag if you turn some features on. The question was whether it was instant, rather than usable.
----------------------
First and foremost, atom has pretty much noticeable lag, even for someone like me who thinks emacs is instant (which it isn't).
I agree that it requires a sensible plugin design, but the GIL will only get you so far. I haven't used atom much, but I suspect the heavier plugins rely on async tasks, which can be implemented using python's threads, or for python 3.4 and later using asyncio. This takes me to my next point:
People also under-estimate how FRIGGIN FAST v8 is. JS executed in v8 (or node) will run so many laps around cpython it makes a web-technology-hater (but whatever floats your boat!) like myself cry and bang my head to the wall. People seem to think that they play in the same league. They do not.
TKinter is a bit of a bizarre choice these days, it looks like you're locked into a non-shell non-native GUI for the benefit of being able to natively manipulate TKinter objects. Though, looking through the plugins it is nice to see how simple and isolated the code for each is.
Lack of Python3 support is concerning as always with any modern Python project.
Why anyone would start a project exclusively supporting Python 2 six years after the release of Python 3 is beyond me. (GitHub lists the first commit in Nov 2014).
I don't know the specifics (sort of watching, amuses, from the sidelines) but the 2/3 schism is still very real.
I'm not fluent in Python at all, and so it seems I have to have both, and if `pip install` doesn't work then I `pip3 install`. That seems pretty broken to me.
Python itself has established the convention that the "python" binary is always 2.x, and "python3" is 3.x. Even if Python 2 is not installed at all. This naturally translated to other tools.
The long-term plan is to make "python" version-agnostic. But for the time being, it is acknowledged that compatibility with Py2 is too important to do it just yet.
vy started when python3 was sort of an experiment, i haven't had many people interested in it in the last four years so i decided to keep it on py2, i have python3 support planned it is coming soon.
Python3 support is coming soon as well as cli support. I'll develop a tk binding that works with tcl CTL lib, people will be able to run tkinter applications on CLI with no complex changes.
Simply put: What does it offer which [neo]vim does not?
> Python is such an amazing language; it turns vy such a powerful application because its plugin API is high level naturally.
Ok, so you really like Python.
> You can take the best out of vy with no need to learn some odd language like vimscript or emacs LISP; since vy is written in Python, you use Python to develop for it.
Ok, so you _really_ like Python.
I'd note that Vim also allows writing plugins in Python, so that alone doesn't warrant an entirely new editor. My biggest problem with this is that it doesn't explain what it provides which other editors do not. As such, I'd label this as the author thought "I love Python and want to make an editor which is all about Python, ignoring all existing Python-supporting editors and IDEs."
That shouldn't be enough to get people using it, though. It's not ubiquotous, like Vim; it doesn't have the plugins and wholesome environment of Emacs; it doesn't have the comparable refactoring/debugging/project management features of modern Python IDEs; it doesn't even claim to provide anything new.
Writing a vi clone in any language is worth a "Show HN" by itself, and "not being vi" is justification enough for a toy project.
For me personally "i did a X clone in Python" is always interesting because the language is so easy to read that it makes for a good interface and algorithm documentation. The article made the front page - looks like it is interesting for a lot of other HNrs too.
Actually, writing a vi clone in any language is only worth asking why in the hell someone would do that. And the answer is: "because Python." (and in case you didn't realize it was written in Python, the author has reminded you 13 times in the README, and named the clone after both 'vi' and the 'y' in Python)
I think we usually see "Show HN" threads for projects where the author expects it to grow (either a company or open source project).
I take things like "vy" as the author being proud of what they wrote and wanting to share it. No harm done.
I don't see these posts as the author suggesting this is supposed to be the way forward, the new thing, etc. And to be honest, it's usually technically more interesting.
>learn some odd language like vimscript or emacs LISP
But Emacs Lisp is more powerful and in some cases nicer to use than Python. How old it is doesn't matter. And Guile is even better. I don't understand why I'd want to use Python.
Makes an interesting comparison to kakoune (http://kakoune.org/), at nearly every point the two projects took the opposite decisions.
I'm really not a fan of pip as a delivery mechanism though, if it isn't ready to be packaged properly then git clone and make instructions would be better.
That's an interesting point! I switched over to Kakoune a couple of months ago, from vim, and I'm delighted with it. The idea that what vim needs is Motif widgets and more Python scripting (2.7 no less!) -- it's the exact opposite direction, indeed.
I ended up switching back because I haven't had time to bring it up to the level of vim and the extensions I have, particularly dbext. It's programming model is interesting though, most of my work could be ported but there are still a few that I don't think can be replicated, like the templating plugins.
I think it would have been a lot harder to switch if I had made heavy use of extensions. The only thing I go back to vim for at this point is vimdiff. Kakoune doesn't have anything quite like it at this point, and I'm fine with that. There's enough room in my head for both as long as I don't have to switch too often.
I do use it. Aside from missing plugins of course, Crtl+o to go back to previous cursor locations is unpredictable and Ctrl+p to complete the word if it's appeared in the file. There's also some weirdness in multiline mode.
I have written a toy vi clone in python, based on curses, https://github.com/RealHacker/python-vi. That's nothing compared with Vy, which obviously is a much more serious project.
It's really not unusual for an adjective to be used to mean "thing described by this adjective".
Laptop (computer). Roguelike (computer game). A glass of the house red (wine). Tabloid (newspaper). Convertible (car). Mobile/cell (phone), though these days people usually just say "phone". Etc.
i think you're missing the reference to a "roguelike". Assuming it's meant the same way "vim-like" is a noun not an adjective. https://en.wikipedia.org/wiki/Roguelike - "A roguelike game is one belonging to a subgenre of role-playing video games characterized by a dungeon crawl through procedurally generated game levels, turn-based gameplay, tile-based graphics, and permanent death of the player-character. "
56 comments
[ 3.1 ms ] story [ 99.1 ms ] threadI thought that this was a clone of Vim, not Emacs.
What you will notice is of course the GIL. Once any plugin starts doing enough work there will be noticeable lag unless Vy supports plugins using multiprocess python.
I have been toying with writing an editor in guile scheme and despite using _very_ suboptimal data structures and algorithms everything is instant up until maybe 10 simultaneous cursors in a 30kb file.
Due to the shitty implementation (really just a first draft), that was actually creating a new buffer for every insert.
----------------------
First and foremost, atom has pretty much noticeable lag, even for someone like me who thinks emacs is instant (which it isn't).
I agree that it requires a sensible plugin design, but the GIL will only get you so far. I haven't used atom much, but I suspect the heavier plugins rely on async tasks, which can be implemented using python's threads, or for python 3.4 and later using asyncio. This takes me to my next point:
People also under-estimate how FRIGGIN FAST v8 is. JS executed in v8 (or node) will run so many laps around cpython it makes a web-technology-hater (but whatever floats your boat!) like myself cry and bang my head to the wall. People seem to think that they play in the same league. They do not.
Lack of Python3 support is concerning as always with any modern Python project.
I'm not fluent in Python at all, and so it seems I have to have both, and if `pip install` doesn't work then I `pip3 install`. That seems pretty broken to me.
https://www.python.org/dev/peps/pep-0394/
The long-term plan is to make "python" version-agnostic. But for the time being, it is acknowledged that compatibility with Py2 is too important to do it just yet.
Qt has license issues; GPL wrappers are a no-go and I still can't completely understand LGPL so I'd rather not risk it.
It surprises me that given Python's size there isn't a one go-to permissive licensed GUI library.
> Python is such an amazing language; it turns vy such a powerful application because its plugin API is high level naturally.
Ok, so you really like Python.
> You can take the best out of vy with no need to learn some odd language like vimscript or emacs LISP; since vy is written in Python, you use Python to develop for it.
Ok, so you _really_ like Python.
I'd note that Vim also allows writing plugins in Python, so that alone doesn't warrant an entirely new editor. My biggest problem with this is that it doesn't explain what it provides which other editors do not. As such, I'd label this as the author thought "I love Python and want to make an editor which is all about Python, ignoring all existing Python-supporting editors and IDEs."
That shouldn't be enough to get people using it, though. It's not ubiquotous, like Vim; it doesn't have the plugins and wholesome environment of Emacs; it doesn't have the comparable refactoring/debugging/project management features of modern Python IDEs; it doesn't even claim to provide anything new.
Shameless plug, I wrote Snake https://github.com/amoffat/snake, which makes writing plugins in Python much easier.
For me personally "i did a X clone in Python" is always interesting because the language is so easy to read that it makes for a good interface and algorithm documentation. The article made the front page - looks like it is interesting for a lot of other HNrs too.
I take things like "vy" as the author being proud of what they wrote and wanting to share it. No harm done.
I don't see these posts as the author suggesting this is supposed to be the way forward, the new thing, etc. And to be honest, it's usually technically more interesting.
Seems more like a personal project that they crafted after the original Vim, more than anything else.
But Emacs Lisp is more powerful and in some cases nicer to use than Python. How old it is doesn't matter. And Guile is even better. I don't understand why I'd want to use Python.
I thought everyone always says it stinks and lacks better components.
I'm really not a fan of pip as a delivery mechanism though, if it isn't ready to be packaged properly then git clone and make instructions would be better.
edit: I'm thinking of IntelliJ and realizing I've not used other for-profit IDEs much.
https://github.com/jonathanslenders/pyvim
I've used Vim for years but on cli only as one of many jobs, fzf pydoc grep find ssh etc etc. I don't quite understand the GUI approach but that's ok
"Vim-like" is an adjective, so where the noun it's modifying?
Laptop (computer). Roguelike (computer game). A glass of the house red (wine). Tabloid (newspaper). Convertible (car). Mobile/cell (phone), though these days people usually just say "phone". Etc.
Youth is wasted on the young.