Closed maliayas closed 10 years ago
Thanks! I will check the patch.
The fix have a problem. It is not recognized hline as a table before '---' or '==='. Let's we edit table(for example in pandoc syntax)
| a | b |
+---+---+
| | |
Put cursor after first '+' and click tab. Table will broken. If you put cursor after second '+' all works correct, because before '---'. I checked this in emacs org mode table editor and emacs works correct in this case.
I think it is acceptable. Otherwise occuring bug is far more harfmul than that. Pressing tab in that narrow area (first +---
) looks too rare to me. However you can decrease ---
to --
and ===
to ==
, so the issue you have pointed will occur even more rarely.
I found other solution and commited into HEAD. The idea is split regular expression for normal row and for horizontal line row. For horizontal line row i used next trigger
{ "key": "setting.enable_table_editor", "operator": "equal", "operand": true, "match_all": true },
{ "key": "preceding_text", "operator": "regex_match", "operand": "^\\s*\\+([\\+\\|\\-\\=]|\\s)*", "match_all": true },
{ "key": "following_text", "operator": "regex_match", "operand": "([\\+\\|\\-\\=]|\\s)*$", "match_all": true },
{ "key": "following_text", "operator": "regex_contains", "operand": "[\\+\\|]\\s*$", "match_all": true }
Table Editor still have unwanted cases "+ +" or "++". But I guess it is not very usable when edit wiki text.
Fixed in 1.7.4 as split keybinding for normal row and for horizontal row
It works for my current workflow, thanks.
If there was a
+
at the beginning of the line (ignoring whitespace prefix), this was enough for the plugin to trigger on several keybindings. This caused some unwanted operations in some cases. With this commit, it is now mandatory to have a---
or===
right after the initial+
to trigger the plugin. This complies with Emacs and grid style table syntaxes.