On 11 Aug 2010, at 04:39, John DeSoi wrote:
I'm interested in some SQL improvements for TextMate. I'm trying to implement a command to execute the selection or SQL line. Not the current textual line, but the SQL line from the beginning of the command to the ending semicolon which may span many textual lines.
I assume you know there already is such command, though one where the fallback is the physical line and not statement line (which you plan to add).
I've made some progress with the grammar and understanding scopes. I think I need to create a "SQL Statement" scope, but I don't see how to write the ending regular expression for the semicolon. Is there a way to do this in the grammar that ensures the semicolon found is not in a string or comment?
Sort of, yes. A rule should always only match the thing it wants to match, it should generally not try to avoid false positives, instead other rules should be created to take care of these.
So in the case of an SQL statement you would do something like:
{ name = 'meta.expression.sql.select'; begin = 'SELECT'; end = ';'; patterns = ( { name = 'comment.line.double-dash.sql'; begin = '--'; end '\n'; }. { name = 'string.quoted.double.sql'; begin = '"'; end '"'; patterns = ( { name = 'constant.character.escape.sql'; match = '.'; } ); } ); }
Here we match strings and comments between ‘SELECT’ and ‘;’, so if a ; is in a string or comment, it is matched by those rules. Likewise a string like: "foo"bar" has the inner ‘"’ matched by the escape code match, so it will not close the string.
I think most of these rules are already in the current SQL grammar.
Also, you may want to move comment and string rules to the repository so that these can easily be included from your various expression rules.
And TM_SCOPE tells me what scope I'm in, but how to I get the text of the current scope?
Generally never use TM_SCOPE.
Your command should use (for example) ‘meta.expression.sql’ as scope selector and then as input take “Selection or Scope” — then when used w/o a selection, it will get all the text part of the ‘meta.expression.sql’ scope on standard input.
An alternative is to take “Entire Document” as fallback input and then do your own parser, but if it is possible to get this working via the SQL grammar, then that’s definitely to be preferred.