From 7a6b21de6514736ef5f0a7cbdf429b8f38c25016 Mon Sep 17 00:00:00 2001
From: Nicholas Marriott <nicholas.marriott@gmail.com>
Date: Wed, 13 Mar 2019 09:30:30 +0000
Subject: [PATCH] Add to TODO.

---
 TODO | 39 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 34 insertions(+), 5 deletions(-)

diff --git a/TODO b/TODO
index 7a4a7a7d..1a25d9b0 100644
--- a/TODO
+++ b/TODO
@@ -155,9 +155,9 @@ TODO soonish maybe:
           #{W:#{window_name} }.  It would need to be able to reach
           into a window's options in order to allow different windows
           to have different format, maybe an operator to evaluate an
-          option value as a format, maybe make it so ! on evaluates
+          option value as a format, maybe make it so E: on evaluates
           the result as a format again something like, so end up with
-          something like #{W:#{!window-status-format} }
+          something like #{W:#{E:window-status-format} }
 
        2) Some way to include alignment information for part of a format.
 
@@ -167,16 +167,45 @@ TODO soonish maybe:
           status-left and right and the default status-format becomes
           something like (plus some bits for current window):
 
-	  #{L:#{!status-left} #{M:#{W:{!window-status-format}}} #{R:#{!status-right}}
+	  #{L:#{E:status-left} #{M:#{W:{E:window-status-format}}} #{R:#{E:status-right}}
 
 	  Where L = left, M = middle, R = right; W = for each window;
-	  ! = get option value and evaluate as format.
+	  E = get option value and evaluate as format.
 
        4) Also need a way to return mouse positioning, so a format
           like the alignment that stores the offset/size for
           Mouse*Status{Left,Right}.
 
-       5) Then status-format can be an array option specifying
+       5) Likewise, styles. Alignment, mouse, styles can all be done
+          similarly - format_expand can be given the available width
+          and then build a list of format_range with type (ALIGN_LEFT,
+          STYLE, MOUSE_LEFT and so on) which a format_draw function
+          can use to draw the format, and can be stored to be used by
+          the mouse positioning check code.
+
+       6) status-left-length and similar will need to be taken into
+          account, perhaps add an alternative form of the length limit
+          eg #{l:#{status-left-length},#{...}}.
+
+       7) Supporting trimming the window list and adding <> might be
+          tricky, probably a second pass over the format_range list to
+          trim as appropriate. But it will need to know which element
+          to trim first, so some way to mark that is needed (maybe a
+          priority or something in the alignment/length limit).
+
+       8) Formats are going to get very long so perhaps standardize
+          them a bit so they are all something like #{F/argument:text}
+          then then could be #{A/foo;B/bar:text} rather than
+          #{A:foo,#{B:bar,text}} and so on. Need to keep the old style
+          for compatibility, at least for the most popular formats. So
+          the status-left part would be something like:
+
+	  	    #{A/left;S/#{status-left-style};M/left;l/#{status-left-length};E:status-left}
+
+          Where A = alignment, S = style, M = mouse, l = length limit,
+          E = expand again.
+
+       9) Then status-format can be an array option specifying
           multiple status lines. Perhaps one option for top and one
           for bottom.