update documentation accordingly

README.md

@@ -45,7 +45,7 @@ The rule section is composed of any number of Rules.
 
 #### Rules
 ```C
-[enter|leave]+ <node-type> { <...> }
+[enter|leave]+ <node-type>+ { <...> }
 ```
 + enter: signals that the rule applies when a node is pushed
 + leave: signals that the rule applies when a node is popped
@@ -54,6 +54,8 @@ the rule fill run on both pushes and pops.
 
 \<node-type\> is the name of a tree-sitter node type.
 The rule will run only if such node is encountered.
+Multiple types can be specified which signals an OR relationship.
+Separate them with whitespace.
 
 \<...\> is the code associated with the rule.
 Its provided in the backend language.

documentation/notes.md

@@ -3,34 +3,15 @@
 I stole the idea from here:
 [https://github.com/oppiliappan/tbsp](https://github.com/oppiliappan/tbsp)
 
-Now, there are some obvious problems with this project:
-+ its written in rust
-+ it tries to be a general purpose language for no reason
-+ "[ ] bytecode VM?"; seriously?
-
-I have tried contacting the owner, the response is pending.
-
-I have tried hacking Bison into this behaviour, its too noisy.
-
 I firmly believe code generation is the way to go, not just here,
 but for DSL-es in general.
 
-This project will heavy depend on tree-sitter,
+I have tried hacking Bison into this behaviour, its too noisy.
+
+This project will heavily depend on tree-sitter,
 there is no sense pretending otherwise with decoupling.
 
 ### Thinking area
 ```C
-// This should be allowed to mean 'a' or 'b'
-enter a b { <...> }
-
-// In the node type, blobbing should probably be allowed, however regex sounds like overkill
-
-/* Checked queries should be supported too.
- * For error handling, say something this could be employed:
- *   enter a { ; } catch { ; }
- * Where 'catch' could be implemented as a goto.
- * I am unsure whether this would be too generic to be useful or not.
- */
-
 // the symbol prefix should be user changable
 ```