start streamlining architecture

All the spaghetti is hiding another issue: when we load editor state,
that code path currently never leads to importing the edited buffer back
into the image.

Yet another attempt at drawing the state diagram:
  Wgetch -> switch_to_editor -> select_view
  select_view -> load_editor_state | big_picture_view
  load_editor_state -> edit_from -> editorProcessKeypress
  big_picture_view -> edit_image -> edit_buffer -> resumeEdit* -> load_editor_buffer -> editorProcessKeypress
  big_picture_view -> recent_changes
  recent_changes -> big_picture_view | edit_buffer

The problem is that load_editor_state doesn't eventually call
load_editor_buffer the way its sibling big_picture_view does.

For starters, it's confusing that switch_to_editor calls
big_picture_view which calls other editor functions. What is 'editor'
here, anyway?

Let's rename switch_to_editor to developer_mode. So the app starts out
in user mode, and might eventually transition to developer mode.
Developer mode is a black hole; to leave it and return to user mode we
restart the entire app.

The architecture in my mind is now:
  - Teliva consists of user mode and developer mode
  - Developer mode consists of multiple views
  - Each view, when it needs to edit something:
      - initializes kilo
      - loads a buffer into it
      - resumes editing the buffer as necessary

1 files changed, 2 insertions, 2 deletions

diff --git a/src/lcurses/window.c b/src/lcurses/window.c
index 8d3d5f1..87c5d08 100644
--- a/src/lcurses/window.c
+++ b/src/lcurses/window.c
@@ -1304,7 +1304,7 @@ Read a character from the window input.
 @see curses.echo
 @see keypad
 */
-extern void switch_to_editor (lua_State *L);
+extern void developer_mode (lua_State *L);
 static int
 Wgetch(lua_State *L)
 {
@@ -1318,7 +1318,7 @@ Wgetch(lua_State *L)
 		exit(0);
 	}
 	if (c == CTRL_E)
-		switch_to_editor(L);
+		developer_mode(L);
 	/* handle other standard menu hotkeys here */
 
 	return pushintresult(c);