Re: Double quotes throws off SQL syntax colouring

On Friday, 30 January 2015 20:05:29 UTC, Paul wrote:
> Paul <Paul.Domaskis <at> gmail.com> writes:
> > I'm editing a file tmp.sql with syntax colouring. The following
> > code all turns yellow after the first double quote (actual file
> > contains a lot more code). I'm in an environment, where upgrading
> > anything is difficult. Is there anything superficial changes I can
> > make to prevent this unexpected colour behaviour?
> >
> > SELECT
> > Field1,
> > COUNT(*) AS Field2,
> > MIN ( LEN( REPLACE( EEEPppp, "\", "" ) ) ) AS Field3,
> > FROM someTable
> > etc....
>
> Ben Fritz <fritzophrenic <at> gmail.com> writes:
> | Why is that unexpected?
> |
> | I'm not familiar with SQL syntax, but some brief searching shows
> | that at least sometimes, '\' can escape a '"' character as it can in
> | many other languages (although I also see that sometimes it cannot
> | escape the quote...so maybe this is one of those times, please
> | correct me if that's the case).
> |
> | So, if I'm reading that right, you're using a single string
> | containing a literal " character, a comma, and a space. Then you're
> | opening the next string. It looks like maybe you wanted to use '\',
> | '' or "\\", "" or something like that instead of "\", "" in your
> | code.
>
> I'm using Access 2010. Unfortunately, from experimentation, a double
> backslash doesn't match a backslash in the data.
>
> William Robertson <william <at> williamrobertson.net> writes:
> |
> | I think the double quotes may be a red herring, as the issue is
> | really the backslash. I've just tried with single quotes and a
> | backslash is treated as escaping a closing quote, despite it not
> | being an escape character in SQL (I'll admit I'm only familiar with
> | Oracle though so perhaps '\' has some special significance in other
> | SQL dialects.)
> |
> | I can't say I've hit this issue before, but if you wanted to replace
> | backslashes with forward slashes and you used
> |
> | replace(somecolumn, '\', '/')
> |
> | that would mess up syntax highlighting as the first quoted string
> | would be treated as ending at the third quote.
>
> I'm actually replacing backslashes with zero-length strings so that I
> can determine the number of backslashes in the string based on how
> much shorter it becomes. So I need to match a backslash.
>
> Tim Chase <vim <at> tim.thechases.com> writes:
> | I'd expect that, as I believe just about every SQL engine out there
> | uses ANSI-standard single-quotes instead of double-quotes. Some
> | might *permit* double-quoted strings, but it certainly doesn't
> | adhere to standards, and double-quotes are used in some databases to
> | quote names of databases/tables/columns.
> |
> | What SQL engine is this for?
>
> Microsoft Access 2010.
>
> John Little <John.B.Little <at> gmail.com> writes:
> | As others have pointed out, standard SQL uses single quotes. Looks
> | like you might be using Informix, SQL anywhere or SQL HANA, because
> | those highlight your snippet properly in my vim.
> |
> | I suggest running
> |
> | :help sql-type-default
> |
> | in Vim.
>
> I tried all 3 SQL dialects in the help:
>
> let g:sql_type_default = 'sqlanywhere'
> let g:sql_type_default = 'sqlinformix'
> let g:sql_type_default = 'mysql'
>
> 'sqlanywhere' and 'sqlinformix' seem to get around the problem, while
> 'mysql' does not. Quick googling shattered my misconception that the
> latter is a Microsoft invention.
>
> Strictly speaking, the dialect for Access use to be JET, and it is ACE
> these days. Because Microsoft Office is so prevalent, I'm surprised
> that there isn't a syntax file for that. Ah well, I will run with
> 'sqlanywhere' until I see anomalies, then switch to 'sqlinformix' to
> see if it circumvents them.
>
> Thanks!

The problem lies in the string definitions in the syntax file. For example, sqloracle.vim contains:

" Strings and characters:
syn region sqlString start=+"+ skip=+\\\\\|\\"+ end=+"+
syn region sqlString start=+'+ skip=+\\\\\|\\'+ end=+'+

I'm not an expert at the syntax region regexp syntax but I think the whole "skip" section should come out because Oracle SQL has no escape character for quotation marks (unless we're counting the q syntax e.g. q'[sometext'sometext]' but let's not go there...) The versions you mention as working don't have these, mysql.vim etc do.

You can edit a copy of the relevant vimfile and place it in your own $HOME/vimfiles/syntax folder, for example on Windows XP mine is F:\vimfiles\syntax\sqloracle.vim.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.