handmade.network » Forums » Work-in-Progress » EdimCoder
krixano
Christian Seibold
4 posts

Going to BriarCliff University as a Computer Science major. I like to read, write poetry, and learn. I mainly use C and Javascript.

#14995 EdimCoder
1 month, 1 week ago Edited by Christian Seibold on April 19, 2018, 4:23 p.m.

It is nowhere near complete, and parts of the code are a mess (I'm working on cleaning it up). I started this project about a week and a half ago as an attempt to create a modern, easy to use, and efficient (as possible) Line Editor based on ideas from Ed/Vim and 4Coder, hence the name: Ed Improved 4coder. It is written in C99. So far, I'm not really using any libraries aside from standard C ones, platform-specific ones (windows.h and conio.h specifically), and the stretchy buffer code taken from the Bitwise project.

The program is functional right now, but is missing some features that I would like to get in there. I've created two demo videos. The first goes through each feature, and the second is me doing some programming with it.



In order to see how well the editor works and find things that need improved/added, I've started doing my programming for my CS classes with the editor. I am also going to start using it for programming the actual editor (I waited because I needed just a few more features done, but now they are implemented). This will allow me to see where the pain points are and exactly what needs to be added and improved.

The Github page is here: https://github.com/krixano/Edim

None
krixano
Christian Seibold
4 posts

Going to BriarCliff University as a Computer Science major. I like to read, write poetry, and learn. I mainly use C and Javascript.

#15022 EdimCoder Progress Update 4/20/18
1 month, 1 week ago Edited by Christian Seibold on April 20, 2018, 7:16 p.m.

These are the things I've added/done:
  • Cleaned Up the code quite a bit
  • Autoindentation - with ability to deindent, currently only works for c, c++, header files, and unknown files.
  • Go backwards in preview mode
  • No more main menu - go straight into '-Scratch-' buffer
  • Passing in a file path into the executable will open the file
  • Create new file in new buffer with 'n' command
  • Some bug fixes

None
OliverMarsh
Oliver
60 posts
2 projects

A budding game developer and programmer

#15024 EdimCoder
1 month, 1 week ago

Nice! Looks good. Do you think you will do a Mac version?
krixano
Christian Seibold
4 posts

Going to BriarCliff University as a Computer Science major. I like to read, write poetry, and learn. I mainly use C and Javascript.

#15029 EdimCoder
1 month ago Edited by Christian Seibold on April 21, 2018, 10:23 a.m.

Thanks! I have Linux and Windows working right now (although, since I've added stuff, I haven't tested Linux again - I'll do that soon). The problem with mac is that I don't have access to a mac to test it on. I believe the main thing that needs tested for macs is just to see if I have the right keycodes for the special keys (arrow keys, end, home, etc.).

None
OliverMarsh
Oliver
60 posts
2 projects

A budding game developer and programmer

#15038 EdimCoder
1 month ago Edited by Oliver on April 22, 2018, 3:01 a.m.

I compiled it on mac using the linux build script, and it runs. I just had to replace malloc.h with stblib.h. Mac must not have a malloc.h? Not sure. It runs, however I'm not sure how to test the special keys. And doesn't seem to like the commands. Anyway, keep up the good work!

mrmixer
Simon Anciaux
371 posts
#15042 EdimCoder
1 month ago

I'm curious about why you use an editor like that ? This is a real question. It seems to me to be really "hard" (or involved) to do simple things, but so was VIM until I really tried it and found some values in it. So what are the benefits of this type of editor ?

It looks a bit like GDB and I wonder if it could benefit from a similar command line UI (press CTRL + X followed by CTRL + A in GDB if you don't know it's graphic mode): the top half of the screen presents the source, and the bottom half allows you to type commands. This made a huge usability difference in GDB for me (even if it's buggy).
krixano
Christian Seibold
4 posts

Going to BriarCliff University as a Computer Science major. I like to read, write poetry, and learn. I mainly use C and Javascript.

#15044 EdimCoder
1 month ago Edited by Christian Seibold on April 22, 2018, 7:14 p.m.

@OliverMarsh
Thanks! The special keys would be the arrow keys, Home, and End. Perhaps the reason why the commands weren't working is because the current latest commits kinda break stuff. I also haven't tested stuff in Linux for quite a while, so Linux may be broken also. I've recently put a notice in the readme to the last revision/commit you should use before all the breaking stuff happened.

@mrmixer
Sidenote: This became pretty long, so sorry about that.
One thing that's interesting is that I've seen some people online say they still use line editors (usually ed) to this day. This project is more of a challenge/test to see if I could make something usable out of a line editor (although, some of my ideas approach on it becoming less of a line editor). Since starting to use the line editor for more and more things (although, I haven't switched to it for everything yet), I think using something like this isn't too hard in these certain cases:
  • Small Files
  • Files where the ordering is simple, where there are not too many different sections, and most of the sections don't overlap. Examples of this would be markdown files, todo files, etc.
  • Switching between some files occasionally/rarely
  • Files where you type very linearly and don't have to switch between sections too often

Here are the cases where the line editor starts to break down and become less usable:
  • Very large files
  • The need to move around a lot
  • The need to break up or join a lot of lines
  • Copying and pasting from one part of the code to another part of the code where these parts are not very near to each other
  • Switching between multiple files a lot

I think many of these benefits and problems boil down to these areas, with the most importance and perhaps the hardest being Explorability and Editability:
  • Commands - prompts and command lexing/parsing
  • Input - Input interface for typing text/commands, shortcut keys, etc.
  • Output - How text and prompts are displayed.
  • Editability - Editing the text in efficient and useful ways
  • Explorability - Ability to explore code in a number of ways, Context
  • Customizability - Settings, Projects, Build system
  • Scriptability - Macros, Repeating actions/commands, Kinda goes with plugins a little

Currently, I have future ideas and I have implemented ideas on how to mitigate some of these. Of course, before they can be confirmed to actually help, I need to be able to test them out (which means implementing the one's that haven't been):
  • Context - All commands give you a little bit of context by printing one line before the operation and one line after the operation. In the future you will be able to configure this to allow for more than just one line being printed. This also includes the user interface making it clearly visible which lines are being modified and for which operation as well as what the current line is.
  • Preview Command - Allows you to quickly preview the file at a given location or at the current location - similar to 'less'. In the future, you will be able to do commands within this also, which means that the commands will have more context than what they usually have (about 1 line) when not in command mode.
  • Preview Line - Will preview the current line or a given line (along with it's context).
  • Quick Command - The ability to suspend your current operation/editing to do another operation/editing in another part of the file. Then, when that's done, go back to where you were before the suspension (possibly updating anything that needs updated, including line numbers).
  • Outlines - The ability to see an outline of the current file. For Code files, this will show all of the function declarations in the file. In the future, I am considering also implementing function outlines, and struct/class outlines.
  • Bookmarks - Will allow you to quickly jump to specific parts of your code or use them directly within an operation. Bookmarks can be associated with one line or multiple lines. Outlines will automatically create bookmarks (based on function/struct name, etc.).
  • Language Specific features - Jump to Definition, Jump to Declaration, Jump to matching brace (line based), perhaps a way to easily factor out code or move blocks of code around.
  • Editor features - These are the one's the are a bit less line editor-like. Keyboard shortcuts for doing specific things when editing a line. Perhaps in the future Emacs shortcuts and Vim mode.
  • Chaining Commands - I got this idea mostly from TECO. Not sure exactly how this will work, but someway to chain commands may be useful.
  • Relative Line Numbers - These may be based either relative to the current line number, or relative to what was previously shown on screen (since almost all commands show at least two lines, usually three)

If I can get this editor to a state where many of the downsides are lowered or non-existent, then this editor can become hopefully as useful or nearly as useful as other editors. In this case, the main advantage of this type of editor would be:
  • Quickly editing files using a combination and chain of commands.
  • Terminal mode starts up very quickly and the interface doesn't suffer from heavy or slow gui
  • Can use over ssh (just like vi, vim, nano, and other terminal editors)

So, there aren't that many benefits. The only real distinguishing factor between this and some of the other terminal editors would be the fact that it's line based, that it's a line editor, and it's possibly different command language and the different features it may provide.

None
mrmixer
Simon Anciaux
371 posts
#15050 EdimCoder
1 month ago

Thanks for the answer.