Suggest we implement:

int get_lua_variable( char *name, int default )

That would let us get the width of a TAB via:

int tab = get_lua_variable( "tab_width", 8);

And we could replace the hard-coded 8 used in different places.

Rather than load:

• ~/.kilua.lua
• ./kilua.lua

We should load:

• ~/.kilua/init.lua
• If it exists ~/.kilua/$(hostname).lua`

We should no longer load from the pwd/cwd - it is a security-risk.

At the moment the status-bar looks something like this:

 File 2/2: <NONE>          ...    Col:1 Row:1/0

If that was populated by a call to get_status() then it could be updated to show things like:

• The current date/time.
• The size of the buffer.
• The number of words in the buffer.
• Anything else the user wanted.

Suggest we leave the default but only use it if the callback function doesn't exist.

Since it is only invoked by Lua we can use dostring natively.

We should use malloc/realloc and allow it to be unbound.

Currently we track the state of the editor in struct editorConfig. That has two kinds of fields:

• Global fields
  • e.g. screenrows
  • e.g. screencols
  • e.g. status_msg
• Per-file files
  • e.g. filename
  • e.g. Syntax

Split that into two structs:

• global_state
• file_state.

With that done we can then allow opening multiple files, and switching between them with ease.

Once we can have multiple files open, each in a "window"/"buffer" of its own we can see if it would be possible to do screen-splitting, that would be nice but perhaps too complex...

If we have no configuration-file loaded then we should make damn sure that ^q quits regardless.

That would be cleaner.

I guess I've moved far enough away from kilo that this doesn't cause pain.

We should be able to call the lua function on_idle in our main-loop.

Could make the key-reading timeout, and invoke it then?

There are many problems with UTF display but the most obvious is that there is an assumption:

• A row is made of characters.
  • Each row has a literal string of characters row->chars and size row->size.
  • Each row also has a literal string of characters to be displayed row->render, of size row->rsize.

The bogus assumption is that a single character fits inside a single char. Which is not true.

Consider the string "OK" it is two characters in length, and comprised of the two bytes:

$ echo -n "OK" | od -x | awk '{print $NF}' | head -n 1
 4b4f

Looks good. Two characters == Two bytes.

Now consider a failing case:

   $ echo -n "£" | od -x | awk '{print $NF}' | head -n 1
   a3c2

One character. Two bytes. Which means that when rendering this character - which you can't even type - things are off.

There is no way to reconcile this unless we change row->render to containing an array of strings. The obvious idea is that each string will represent one character on-screen, even though the length might be >1 character.

//cc #40.

We read input into a fixed buffer for display in the input-area, but don't implement scrolling.

Enter too much and you can't see it. Enter super-too-much and it will be truncated as get_input uses a fixed sized buffer.

This maybe show them in reverse?

The current behaviour of persisting for five seconds is .. odd.

We can move one line below the end of the file, in a way that isn't necessary.

Ditto for the end of the final line.

The default behaviour is this:

• Run the editor with no arguments.
• Enter some text.
• Press Ctrl-s to save.
  • Receive an error-message: No filename is set!

It would be better if you received a prompt: Filename to save as?.

Right now if you wish to save an un-named file you have to run this:

• M-x save("foo.txt")

which is not user-friendly.

When we move the status-bar into the lua code, #41 , we'll have two obvious problems:

• It isn't possible for Lua to get the name of the file in the buffer, or the buffer-name.
• It isn't possible for Lua to get the size of the terminal, so it won't be able to pad the string appropriately.

We'll need to add those two primitives first.

At the moment it moves to the start of the last line.

This will allow the user to interactively select a buffer.

We should do that:

• In the implementation
• In the README.md file.

PS. Our prototypes are outdated.

To dump out the embedded lua config-file we contain in our binary.

Export select_buffer to lua.

That will:

• Show the list of current-buffers.
• Allow navigation & selection.

Bind to Ctrl-x b|B.

If one put spaces between # and define it should still be treated as #define.

The loading of an untrusted file, from the present-working-directory is a security-risk. Especially when you consider:

 os.execute( "rm -rf " .. os.getenv( "HOME" ) )

Don't do it, either load ~/.kilo.lua, or require the user to specify the path with --config /path/to/lua.lua.

At the moment we have three functions:

• syntax_highlight_numbers
• syntax_highlight_strings
• syntax_highlight_trailing_whitespace

Instead we should use a single function, with a table:

-- Set all three on/off at once.
set_syntax_options( {  numbers = 1,  strings = 1 , trailing_whitespace = 1 } )

That will mean our total highlighting functions will be:

• set_syntax_keywords
• set_syntax_comments
• set_syntax_options

Add the primitive search( "regexp").

Optional extensions:

• Allow searching backwards.
• Allow a starting offset to be specified.

Yes we have find already, but that's interactive.

We should allow Lua to do a search operation, because that will allow us to run a search&replace in the future.

  search( "Steve ")
  search( "Kemp" )
  -- etc

If the search function returns true we know we matched, so we can do a replace like:

   function s_r( orig, new )
       while( search( orig ) ) do
          -- Delete the match
          for (i,#orig) do
             right(); delete()
          end
          -- Insert the replacement
          insert( new )
      end
  end

Or similar.

kilo -> kilua.

That would allow more emacisms:

  keymap['^X^S'] = save
  keymap['^X^C'] = exit

Shouldn't be hard to do, the biggest issue is that at the moment input is blocking.

We can read a key, look for a prefix-match, rather than a literal match, and route as we do at the moment.

I use this on emacs.

(Actually I highlight trailing whitespace by default, and strip it on saves. If we wanted to do that we'd need to add an on_before_save() hook, and rename on_save() to be on_after_save().)

We should show more useful content.

#21 implemented a Lua powered search, which is literal, then 241d059 implemented a trival search/replace function.

It would be nice if the search supported regular expressions. However if we do make that change we cannot easily carry out a regexp-based search/replace -Because the removal of the match will rely upon knowing the number of characters to remove.

e.g. If you search for "Steven*" you'll get a true/false result, but you don't know whether to delete "Steve", or "Steven".

The only way this will be possible is if we change the search function to return two values:

• Did we match?
• The length of the match.

With that change we should be golden.

This works:

touch t.c
kilo t.c

This does not:

rm -f t.c 
kilo t.c

Suspect the on_loaded(filename) callback isn't being invoked if the file isn't found.

The at primitive is supposed to return the chacter at position (X,Y).

At the moment we use ncurses to read the character at the given display-cell. This is broken for multi-byte characters because it returns the wrong value.

It also only works for characters on the current screen, taking no account of the actual position so that's another reason to avoid ncurses in this case.

Since we can handle them via Lua too.

But when I tried it I got tied in knots.

Help welcome :)

Although that's against the spirit of the original project I think it's still somewhat reasonable.

• The current display loop currently is a mess.
• Conceptually it is simple:
  • Move to 0,0
  • For each visible row in the text - draw it
  • Handle colours via hardwired escape-sequences
  • Show the cursor.

Using ncursesw our loop would be equivalent in functionality:

• For each row that is visible
  • Move to (row,0) and draw the string, setting colours appropriately.

Pros:

• We'd be more portable (to terminals, rather htan systems).
• We'd also be able to use keyname to perform the key-expansion in C.
• We could handle Unicode input.

Cons:

• Added dependency.
• More significant code-churn and divergence - though at this point reconciling changes is almost impossible.

I'm not going to hack on this immediately, but I think it's probably something that will happen sooner or later..

Keeping 0.0.1 is a bit of a joke:

• Definitely bump the version.
• Consider a rename.
• Explicitly say that my code is the same license as @antirez's.

Obvious failing:

 char *new = realloc(ab->b, ab->len + len);

Beyond that we have a couple of issues with const char * vs char * - e.g. editorInsertRow and get_input.

Finally we have multiple uses of malloc/realloc which don't have a type-cast and will give warnings about the void * return value.

When the cursor is below the mark the actual point of the mark is not highlighted.

We should be able to create one buffer for each file on the command-line.

Since we can use ctrl-o and ctrl-l save("new/file/name") to open/close files.

This should be pretty simple..

The ordering of the code is somewhat random.

At least put the *_lua functions together. Do this after #2.

The startup banner should be updated to show:

• Is _UNDO enabled?
• Is _REGEX enabled?
• What version of Lua are we built against?

Finally the use of regexps for syntax-matching should be conditional.

Kill it.

At least --config /path/to/lua.lua and --version.

Hard to explain, obvious when you see it :)

There are two approaches here:

• Use a proper parser.
• Clone the old code.

The former has the advantage that it will be easier. The latter has the advantage Lua can be used.

Either is fine.

The following code seems to result in corruption:

  function steve()
     end_of_file()
     local c = 10000
     while( c > 1 ) do
        c = c -1
        delete();
     end
  end

This was actually found via "HOME Ctrl-space END Ctrl-w" (i.e. select who file, and then Ctrl-w to cut). But it turns out deleting a single character, 10,000 times, is sufficient to cause corruption.

• Add copyright header to all files.
• Ensure each function is documented.
• Ensure each function is alphabetically ordered.