ReVi is a cross-platform terminal based Vim inspired text editor. Currently ReVi is in heavy development and it's probably not good idea to use for every day use but I have been using ReVi to work on ReVi to help find bugs. Editor inception
😲
! If you like what you see help the project out with a github star. If you find a bug please feel free to open a issues for it.
Formatting the screens display will need to be reworked but this will help add flexibility to enable word warping as well. The text format function will just need and x offset.
I dont think this would be to hard to add command history. The fact that our command mode is really a window we could scroll the commands. The only thing we would need to do is add the keep the buffer of old commands instead of clearing it and placing the cursor at the end of the file when done.
Running Shell commands from within ReVi is extremely important and as I use ReVi I find my self needing this more and more.
I want to add this but I am not sure its worth it before we add a better interface and a real parser.
For More then one Window to be on the screen Window will need to to be moved into a new struct Called Pane or Frame?
We could make this so that Line Numbers are a Pane without a buffer and this would mean added Tab support would be that much closer.
What is windows job now?
Window will hold a Vec of Pane's/Frame's they in turn will hold almost everything that a Window now holds.
Opening more then one file is a major feature/requirement for making any text editor usable. Currently in ReVi Window Hold a buffer and that ties it down to that window. I think a window should have a current_buffer variable that looks into a buffer list and move the Buffer's to a Vec in ReVistruct . Although this may be hard to use without the support of Command mode.
I have thought about this command a bit and all has came to mind so far is pretty straight forward. Grab from current cursor position to end of line and look for text then jump to next line and keep going. I wanted to use the as_str (aka it returns a Option<&str> to get the &str version of the line but I have had that fail before when a line should have returned a Some. It says in the docs that ropey can fail on this when the string is over lapping memory chunks. Just using the normal string.find really seems like a bad idea cause then you would need to turn the RopeSlice into a String. Although that seems undesirable, is it any worse then just iterating over each char on the line? Do we find all locations of this word and store them? Why would we store them? What if we want to highlight all the text on screen above the cursor or below? Seems better to just store the location but then that fails (or needs to be updated) when the user adds or removes text. I could most defiantly make a typical school boy algorithm that does the job but I am no master at any coding for sure.
enhancement
opened by cowboy8625 1
Releases(v0.0.0-beta-1)
v0.0.0-beta-1(Jul 28, 2021)
Changelog
------------- Version 0.0.0-beta-1 (Jul 2021) -------------------------------------------
With this update there was a lot of redesing with the rendering and also the file formating with the removeal
of the command file out of revi-core. Made a lot of new bugs but I think they were also fixed with the
help of some new test modules. As I work on ReVi more and more things are clear on what should come next
and also what I need to keep in mind for the further.
------------- Version 0.0.0-beta-0.6 (Jun 28 2021) -------------------------------------------
Enhancements Add
In these update brought a lot of structural changes to ReVi in the regards to breaking up some
of it into there own packages. Now ReVi has revi-core and revi-ui so that we can
abstract away the drawing of the screen and the core part of this program. In doing so I do not
see way we could not support a GUI state as well. I just wanted to say that making the w and b
commands was extremely harder then was expected. The implementation of it is certainly not the best
but it gets the job done for now. Getting this working and worrying about how it is implemented on
the first go around is ok. Its helped me see how to make such an algorithm for this and things I
can do to make it better.
Kibi: A text editor in ≤1024 lines of code, written in Rust A configurable text editor with UTF-8 support, incremental search, syntax highlighting, li
Ginkgo is a text editor built entirely in Rust. It supports cursor movements, CTRL commands, select vim commands, insert vs. normal modes, and more. Ginkgo is based on my text editor JED, which itself was based on the popular online editor Kilo.