Vy – A Vim-like in Python made from scratch | Hacker News Reader

Vy – A Vim-like in Python made from scratch

github.com

129 pointsdajohnson8954 comments

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.

For this kind of tool that doesn't seem such a big problem. The presentation screenshots could have done without the Motif theme, though :)

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.

`pip` is dictated by your OS, so you've probably got python2 set as your default python.

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.

I don't think this is necessarily true? It used to be, but I sometimes see "python" being Python 3 and "python2" being Python 2.

It's a PEP.

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.

Arch Linux is significant exception.

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.

Legit question, what's a good alternative for tkinter? I agree it's terribly inconsistent and unpythonic and generally a displeasure to work with.

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.

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.

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.

> I'd note that Vim also allows writing plugins in Python

Shameless plug, I wrote Snake https://github.com/amoffat/snake, which makes writing plugins in Python much easier.

I've been looking for something like this, thanks!

This looks truly awesome.

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.

it doesn't appear to be shared by the author ( iogf ) . It looks like someone who found it ( dajohnson89 ) and thought it worth sharing.

Did the author actually imply they wrote this to show off Python in particular and why "Vy" should be used over Vim?

Seems more like a personal project that they crafted after the original Vim, more than anything else.

Yeah, seems easier to just use Sublime Text, whose plugins are written in Python.

>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.

There's another one over here:

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

See also https://github.com/yi-editor/yi in Haskell , which has vim keymap bindings

Projects like this make me wonder why all the for-profit IDEs can't implement better vi/emacs modes.

edit: I'm thinking of IntelliJ and realizing I've not used other for-profit IDEs much.

Do you use the vim plugin? I find it pretty good. What's missing for you?

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.

Ah. Maybe the difference is that I don't author much content in web.

> vy is built on top of Tkinter which is one of the most productive graphical toolkits

I thought everyone always says it stinks and lacks better components.

Any users of it around? Does being in Python make it seem less responsive than regular Vim/Neovim?

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.

I use it occasionally, as a hobby. I don't notice any lag. But I haven't paid too much attention to performance, nor have I done any benchmarks.

Python and TK and a viable app? I'm impressed. Kudos to the author.

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.

Seems to be python-focused, but looks really nice.

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.

> The built-in IRC client

I thought that this was a clone of Vim, not Emacs.

AHEM, http://www.vim.org/scripts/script.php?script_id=931

No updates since 2005, designed for 6.2... Holy cow you had to go dumpster diving to find that script. I love the guy's changelog, though! :wq

It was the first one that came up on google. I did see someone create a more recent one over on r/vim though.

heh, you know... emacs is 'just' a wapper around a lisp interpreter in a similar fashion.

-EPARSE

"Vim-like" is an adjective, so where the noun it's modifying?

That was my first thought too; either the OP meant to write "Vim clone", or forgot to put "editor" after "Vim-like".

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.

Blessed are the meek.

Youth is wasted on the young.

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. "

awwwww... :( python 2.7

Reply on news.ycombinator.com