Most of the "main goals" are supported by ... Eclipse!
Consider the following: multi-tools, mess kits, and sporks exist, yet many people prefer using the specialized equivalents.
Design of a Vim-like text editor
51–60 of 92 posts
Re: Design of a Vim-like text editor
#52Earlier quoted context omitted.
IF the project survives.
It may be still too early to tell but it seems there is enough interest to keep it alive. It's been almost a year since the project started and it has over 120 contributors, over 2500 commits and doesn't seem very top loaded on the project owner (who is responsible for only 18% of the commits).
Which was one of the core goals. Spread the load, avoid single points of failure, create a vibrant community of contributors, allow people in.
Re: Design of a Vim-like text editor
#53Earlier quoted context omitted.
At the moment only the line number corresponding to the start of the viewable area is cached. Further requests are served based on that. Since the underlying pieces/buffers remain unchanged, one could also maintain a more complex data structure such as a balanced binary search tree.
What about uncached? Imagine the user opens a file and immediately issues a command "go to line 12345". Or is go to line not implemented at this time?
Then the underlying file is scanned. The performance of this depends on the number of non contiguous changes made to the document. At load time i.e. with no changes this will be relatively fast since it is a single memory mapped piece/buffer.
Further request are then either served from line 12345 or the start of the file, depending on which is nearer.
Re: Design of a Vim-like text editor
#54Earlier quoted context omitted.
It may be still too early to tell but it seems there is enough interest to keep it alive. It's been almost a year since the project started and it has over 120 contributors, over 2500 commits and doesn't seem very top loaded on the project owner (who is responsible for only 18% of the commits).
Which was one of the core goals. Spread the load, avoid single points of failure, create a vibrant community of contributors, allow people in.
I wasn't trying to be negative. There have been a lot of editor projects come and go is all. I like the idea of neovim. I just with Bram was more flexible so that neovim wasn't necessary.
Re: Design of a Vim-like text editor
#55I'm currently building a similar project in Rust called iota: https://github.com/gchp/iota I don't intend it to be a vim clone, however I'm currently adding some features which I've borrowed from vim. The main one being modal editing. Its much earlier on than this project, though. As a side note, building a text editor is great fun, one of the most interesting projects I've worked on!
It looks cool, and I love Rust.
A question, which are your frustrations with other text editors? Can it really be the case that you can't find an existing text editor that you like? :)
Re: Design of a Vim-like text editor
#56Earlier quoted context omitted.
And cpu, and battery.
And sanity. ;) Honestly IDEs in general are the most complex pieces of software that I frequently encounter. Most of that complexity comes in the form of features that I either never intend on using or don't intend on using at the time, which makes that complexity really frustrating. Complexity where it is necessary is fine of course, but I feel like IDEs like Eclipse frequently cross that line.
Eclipse isn't really just an IDE, it's almost an OS in its scope and complexity. I agree it's way too complicated and bloated, and worse: the rewards aren't there like they are in IntelliJ or Visual Studio. It's not as polished and not as easy to set up.
The whole point of integrated software is to be able to do everything in one place: debug interactive in editor, hover to inspect values, edit the code and have the ide recompile and reload the changed program.
The IDE that does that likely does other things, but having unused features should neither add complexity nor incur performance costs!
The complexity of setting up a dev env like the above in emacs or vim is absolutely staggering, but the complexity lies in the configuration and setup, not in the finished env, that's the difference. Personally my tolerance for "configuring" my tools (meaning gluing, telling my editor and profiler where my debugger is) is nearly zero.
Re: Design of a Vim-like text editor
#57So weird to see this at #1 since I was researching this exact topic last night. My idea is a fully scriptable (Racket or CL) editor with modern package management system. A tiny C core would handle rendering (curses, etc.). Very cool write up though!
As an alternative to ncurses, I encourage you to look at termbox[1]. It's small, minimal, and very robust in my experience. (As a side note, the author also wrote a text editor in Go that uses it.) [1] https://github.com/nsf/termbox
I'll check it out. Thanks!
Re: Design of a Vim-like text editor
#58I'm currently building a similar project in Rust called iota: https://github.com/gchp/iota I don't intend it to be a vim clone, however I'm currently adding some features which I've borrowed from vim. The main one being modal editing. Its much earlier on than this project, though. As a side note, building a text editor is great fun, one of the most interesting projects I've worked on!
It looks cool, and I love Rust. A question, which are your frustrations with other text editors? Can it really be the case that you can't find an existing text editor that you like? :)
Another part of it which I didn't mention is that I've always wanted to build a text editor, they've always intrigued me. So this was me scratching the itch if you like. I also used it as an opportunity to learn rust, which I really like, incidentally.
To answer your question, I actually hadn't found one that suited me, fully. There are many that I like, but non which did it for me. It sounds a bit weird, but it needs to feel right, which none of then did for me. So that's why I started it. It seems others are interested in it too which is cool!
Re: Design of a Vim-like text editor
#59The source code of vis looks great, and the executable takes about 100KiB (x86-64). The editor does not behave exactly like vi/vim, but it is quite acceptable.
I like a lot the suckless manifesto, recommended projects, etc. http://suckless.org/
Re: Design of a Vim-like text editor
#60Earlier quoted context omitted.
IntelliJ sort of has this for Scala. Scala Worksheets. They are more useful than a REPL, but not quite to iPython in terms of features (mainly because they aren't browser based). But they also have some advantages over iPython (like integrating many of the IDE features).
PyCharm now offers the ability to open iPython notebooks inside itself - which gives you the nice IDE goodies, plus the notebook goodies. The downside of course is that Python is very dynamic - so IDEs are of relatively limited use.
The downside of course is that Python is very dynamic - so IDEs are of relatively limited use.
I am surprised to hear you say that with "PyCharm" being the first word in your comment. We have had very good experiences with PyCharm + reStructuredText annotations to help it when the return type or arg type is not inferable. Just like its IJ friend, PyCharm has caught quite a few bugs and helps the team edit Python and not text.
PyCharm's usage is not optional on my team; we tried the "use whatever text editor you want" approach and it turns out that people are not as good at memorizing the type signatures of a complicated codebase as computers are.