building menus per selection's type

7.20: adde/gui/building menus per selection's type:

. when any content is selected,
the menu should reflect appropriate commands;
and, that will typically be depending on
the selection's datatype,
but there can be several:
. all code can be seen as a character string,
then there are generic types
and finally there could be specific types;
eg, select a list, and maybe there's some
type that is based on a list (its literals use
a constrained version of list syntax).
9.5: eg,
when you've imported type spreadsheet,
and have selected a list of lists,
then one of the available menu options
is a list of spreadsheet commands
that treat lists of lists
as if they were spreadsheet tables .

automated menuization:
[9.5: intro:
. menuization means the process of
converting a module's interface
into a human-usable menu that is
just as powerful as the module's API
(application programmer's interface).
]
. any module menuization can be automated
from reading a module's code,
so how to know when a module is a typedef,
and the definition includes value literals
that match words in the current selection?
any subtle cases? .
...
. one thing that helps adde identify types:
it tries to parse as much into adda as possible;
so if that parsing found any type info,
the code will already be tagged with type info,
and all operations related to that type
would be presented in the current menu .
9.5:
. one thing adde can do when the selection contains
english words that match imported type literals
is tag those words as being of that type
rather than english type (being of english type
means the exact meaning of the word
can be found in an english dictionary).
. given a selection, the menu can help you find
the meanings of each word,
according to every imported dictionary
including the value literals of typedefs .
. eg, if you selected green after importing trafficlight,
then one definition of that would be
trafficlight`image#3 .

7.22: automated menuization/handling non-terminals:
. part of auto-menu-ization needs to deal with
the params of control types:
eg, when the menu provides an if-then stmt,
it inserts a string with params like this:
if<truth> then <subprogram>;
then if you select <truth>
the menu needs to show all this:
[current truth vars...], [make new truth var];
[functions that output truth...];
[operations that inout truth ...], etc .
. say you replace <truth> with
<truth> = <truth>
then you repeat the process .
. it should use a context menu tip too:
the moment you select a <truth> text
the right menu is open,
and your mouse focus is in it .
-- that would be like writing only better .
9.5:
. while there are <VAR> texts in place,
the editor is in a different mode:
where the tab and other navigation keys
are hopping between <VAR>s,
and the enter.key is opening the menu .
. when the menu is closed,
then the focus is on the
newest left-most <VAR> .
. the up-arrow.key goes up the expression tree;
down goes to the left-most child node;
right-arrow.key, and tab.key move linearly right,
left-arrow.key moves linearly left to next <VAR> .
. the esc.key toggles between {text, <VAR>} modes .

7.23: automated menuization/handling non-terminals:
. we could do the same thing for
teaching natural language to foreigners,
helping them build expressions in a 2nd lang .