Currently we have INSERT_BACK and INSERT_FRONT.

If you open a file with only a single-line, and then delete it, you see corrupt data.

Enter one line of text to a file, then edit it:

  deagol ~/viw $ echo "foo" > text
  deagol ~/viw $ ./viw text

Once loaded press dd. Notice the first line shows gibberish?

Hold j and see your cursor go wild

Features

• gg, G

• Insert rows with o, O, Enter in insert mode

• Delete rows with dd, Backspace in insert mode

• Mode indicator on status line

• Line numbers

• Line wrapping (if num of chars of a line exceeds terminal width) this is a fun one

• Responsive (changes layout as the user resizes their terminal)

• Undo/redo

Bugs

• Delay when exiting from insert mode

Time to revisit this project 🙂

When writing C we must ensure we code safely, especially with memory functions, i.e. we don't use-after-free or double-free or null-dereference...

Tools to help discover these issues exist, e.g. splint, cppcheck, infer...

Here is a run of infer against your codebase:

$ infer run -- make
Capturing in make/cc mode...
Found 9 source files to analyze in /dir/viw/infer-out
Starting analysis...

legend:
  "F" analyzing a file
  "." analyzing a procedure

FFFFFFFF...............................F..............................................................................

Found 14 issues

src/buffer.c:40: error: NULL_DEREFERENCE
  pointer `ec` last assigned on line 36 could be null and is dereferenced at line 40, column 3
  38.     echar_t *prev = NULL;
  39.
  40. >   ec->c = c;
  41.     ec->prev = NULL;
  42.     ec->next = NULL;

src/buffer.c:113: error: NULL_DEREFERENCE
  pointer `buf` last assigned on line 111 could be null and is dereferenced at line 113, column 3
  111.     buffer_t *buf = malloc(sizeof(buffer_t));
  112.
  113. >   buf->num_rows = 0;
  114.     buf->head = NULL;
  115.     buf->last = NULL;

<...SNIP...>


Summary of the reports

  NULL_DEREFERENCE: 14

(Most issues detected by infer here are due to not checking if malloc failed, but there is one where a fopen is not checked either.)

I suggest you employ some static analyzers to help you check your code as part of your regular development process (and before accepting PRs). Good luck!

Links:

• https://github.com/mre/awesome-static-analysis
• https://en.wikipedia.org/wiki/List_of_tools_for_static_code_analysis#C.2C_C.2B.2B
• https://security.web.cern.ch/security/recommendations/en/codetools/c.shtml
• https://www.owasp.org/index.php/Source_Code_Analysis_Tools
• https://www.securecoding.cert.org/confluence/display/seccode/SEI+CERT+Coding+Standards
• https://stackoverflow.com/questions/2248995/is-there-a-need-to-check-for-null-after-allocating-memory-when-kernel-uses-over

As @telemachus brought up in #24

Arrow keys are interpreted as raw input:

^C^B^E^D

Make your text file look like the following

a
some text
dank mr goose mr goose is the best

navigate to the last line and hit dd.

the cursor position will be wrong

It will be a fun challenge to replace ncurses with a custom and lightweight rendering lib

Thanks for sharing this and writing up your experiences making it! As the title says, I have two small suggestions.

First, and just fyi for your README, this built for me on macOS (10.12.6) without trouble (I already have the build tools installed for gcc, but many people checking out the repo will too). I have a fair number of packages installed via Homebrew already, but I haven't installed ncurses. Anyhow, you might mention that Apple users can likely try it out too.

Second, maybe consider swapping your default task in the Makefile from run to build? I found it disconcerting to hit make and to end up in the editor. I found it even more disconcerting to have the executable disappear after I quit it! I like the neatness of run for people just trying it out, but it was confusing at first. However you go on the default, maybe say something in the README about the Makefile. (All of this said, it's my own fault for not reading the Makefile before I ran make!)

state.c is getting messy, I should refactor buffer out of state

./state-test.c: In function ‘test_update_cursor’:
./state-test.c:15:3: warning: implicit declaration of function ‘update_cursor_position’ [-Wimplicit-function-declaration]
   update_cursor_position(st);
   ^~~~~~~~~~~~~~~~~~~~~~
./state-test.c: In function ‘test_update_display’:
./state-test.c:29:3: warning: implicit declaration of function ‘update_display’; did you mean ‘test_update_display’? [-Wimplicit-function-declaration]
   update_display(st);
   ^~~~~~~~~~~~~~
   test_update_display

I found a function called update_state in state.h that might be the update_display you refer to in the test. For the second error, update_display is in state.c but I don't how it can be made visible by including just state.h in the test.

Make your text file look like the following

lol
ay lmao
mr goose da worst
jk
mr goose da best

then move your cursor to my favourite line (mr goose da best).

Keep hitting dd until your terminal explodes

The idea

The goal is to use command pattern and event sourcing. We model all state mutation methods as commands and register them in a stack. When the user hits undo button, we pop the first command and replay all the commands on the initial buffer. the popped command will be added to undo_stack. As for redo, we will pop the undo_stack and apply the command to the current buffer.

TODOs

• Refactor state->buffer into state->text_buffer and state->status_line_buffer.

• Clone text_buffer by value (cloning a 2d doubly linked list 😛 )

• undo_stack and history_stack