handmade.network » Forums » Work-in-Progress » EdimCoder
Christian Seibold
12 posts / 1 project

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 year, 1 month 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

Christian Seibold
12 posts / 1 project

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

125 posts / 2 projects

A budding game developer and programmer

#15024 EdimCoder
1 year ago

Nice! Looks good. Do you think you will do a Mac version?
Christian Seibold
12 posts / 1 project

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

125 posts / 2 projects

A budding game developer and programmer

#15038 EdimCoder
1 year 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!

Simon Anciaux
590 posts
#15042 EdimCoder
1 year 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).
Christian Seibold
12 posts / 1 project

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 year ago Edited by Christian Seibold on April 22, 2018, 7:14 p.m.

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.

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.

Simon Anciaux
590 posts
#15050 EdimCoder
1 year ago

Thanks for the answer.
Christian Seibold
12 posts / 1 project

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

#17012 EdimCoder
5 months ago

I've added quite a few things to EdimCoder, however, some of these things are
buggy (working on fixing them up, just fixed a semi-major bug with bookmark
creation). This post will go over some of the updates and bug fixes I have made.


One of the things I have added is called "bookmarks". Other text editors call
these just "marks". Bookmarks do *not* refer/mark a line number. Instead, they
refer to / mark a line *range*. If you mark one line, the line range is just
a range of 1 line. Line ranges are expressed like this in the current command
syntax: '10:50' (line 10 to line 50).

Bookmarks are given names. A bookmark can be used in place of a line number or
line range given to a command. Bookmarks are denoted with a hash '#' in front.
Here's an example: 'j #p3'. This will jump to the first line number of the p3

Commands that take line ranges will use the full range of the bookmark.
Commands that take line numbers will only use either the start or end line of
the bookmark. Which one is used is dependent on the command and should be
intuitive. Inserting before ('i') will use the starting line of the line range,
inserting after ('a') will use the ending of the line range. Inserting before
inserts before the range of lines, inserting after inserts after the range of lines.

You can list the bookmarks available in a file with the 'g' command. You can
create a bookmark with the 'd' command: 'd 10:50 functionTest'. You can check
the starting and ending lines of one bookmark by using the 'w' command (and the
bookmark name *without* the hash): 'w functionTest'. These are all described in
the help screen.


I have added outlines for Lua, C, Markdown, and Text files. I have improved the outline for C
files. Outlines also now automatically create bookmarks for each item. For
example, the C outline provides a list of functions in a file, so the bookmarks
created have the name of the function and the range referring to the range of
lines for the whole function.

Default Bookmarks

I have added default bookmarks. These are bookmarks that will always refer to
something specific for every type of file that is opened. For example, '#f'
is the line range of the whole file. '#p1' refers to page 1 of the file. Pages
are currently around 18 lines (or something like that). '#c' always refers to
the range of one line that is the current line (where the "cursor" is).

Lastly, '#s' always refers to the line range of the bookmark that the current
line is within the bounds of. If I have the bookmark functionTest (from above)
with line range of '10:50' and my current line (aka "cursor") is at line 15,
at that time, '#s' will refer to the line range of the functionTest bookmark,
10:50, because line 15 (the current line) is within it's range.

Additionally, the 'g' command will put an asterisk next to the bookmark with which
your current line is within the bounds of.

Bug Fixes

Fixed a bug where pressing Ctrl-D on the first line of a 'i' or 'a' command (insert
before/after) will result in a segfault. What should have happened is the command
should have canceled - the reason why is being the line you press Ctrl-D on is
*not* included in the lines that are added into the file. If you wanted to just
add a new line, then you should first press enter, then do Ctrl-D on the *second*
line, and then that second line would *not* be added, only the first with the
new line at the end. Hope that makes sense.

Also recently fixed a bug where a segfault could (and did in one of my files) happen
when trying to get a bookmark (which also happens everytime you add a bookmark to check
if it already exists) due to what I believe was the string compare going outside of
the allocated memory for the line because the amount of characters I was checking was
the MAX of the bookmark name being searched for (which was just a pointer into the
line where the name was found) and the current existing bookmark name being compared to.
I fixed this by using MIN instead, and by also checking that the length of the names
are equal.

I've also fixed a bug where the line numbers for the ranges of the bookmarks created
from the outline were shifted one line up/less than they should have been.

Quick Command Mode

Quick command mode lets you run one command while in edit mode (when adding lines,
replacing lines, or creating new file, etc.). After the command is done, you
go back to exactly where you left off when editing. You can use this by starting
on new line (if in a command that support multiline) and pressing ESC twice (which
will appear as a red $) then type the command you want to run. The command will run,
then you will go directly back to the same line number as if you had never typed anything
there at all.

Quick Command Mode is currently a little buggy depending on what commands you run. If you
run any commands that change the current line, the line numbers currently being added/modified,
or buffer, there will be bugs. However, you *can* safely create bookmarks, print lines, enter
preview mode ('p'), and use the help screen with it.

The New Help Screen

I have modified the new help screen to remain within 60 characters, use tabs to align things,
sort commands into sections based on what each one does, and add colors to hopefully make things
more readable.

Ideas for Ruler/Right Margin Line

I have some ideas for how I could add in a Right Margin line feature to EdimCoder. Remember
that EdimCoder is *not* screen-oriented, so drawing an actual line down the screen can't be done.
However, I can, when you press enter in editing mode, draw the line ('|') then, then move the cursor
back to the start of the line. Then, when you hit enter again, I draw the '|' again. However,
with the current way that I do this, that'd be slow since I don't use ANSI escape sequences
(or win32 api) to move the cursor but instead just print a bunch of spaces, then use '\b' ASCII
character to move the cursor all the way back.

Another option is I can just switch the color to red when the user gets past the right margin.

Future Ideas

Here are some other ideas/features that I will be working on in the future:
  • Fixing up Quick Command Mode so things work well
  • Overhauling the Commands to make more sense (I have a plan for this)
  • Command History
  • Input Bugs (Shift-Backspace, and a few others)
  • Correctly Handle Line Endings (based on file or user options)
  • Tab Completion
  • Basic Regex Support
  • Unicode

Simon Anciaux
590 posts
#17018 EdimCoder
4 months, 4 weeks ago

Could you provide binaries ?
Christian Seibold
12 posts / 1 project

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

#17019 EdimCoder
4 months, 4 weeks ago Edited by Christian Seibold on Dec. 22, 2018, 5:02 a.m.

Just fixed a bunch of bugs in EdimCoder and added support for deleting *range* of lines and moving a *range* of lines up/down. Also, I've switched the p and P commands. p is for printing now, and P is for Preview mode.

You can download the x64 Linux release executable here: https://nest.pijul.com/krixano/Ed...der:master/333dc76a8149dda7a9?raw

I don't currently have any other binaries available atm.
I haven't tested newer versions on Windows or Mac, so they may be buggy. I will probably test on Windows soon.