Backslashes in character classes confuse regex support

[cemerick]

This is not highlighted properly:

#"[\\]"

i.e. the closing quote is not colored to match the opening quote. And, though I don't understand how it happens, a regex containing a backslash in a character class causes paredit to "fail" anywhere later in the same file (i.e. matching pairs of parens or brackets aren't inserted); removing the regex in question makes paredit work properly again.

FWIW, the real-world regex I had in a file that prompted this issue was #"[/\\]([^/\\]+)$".

[guns]

Hi @cemerick,

Thanks for reporting this. I was suspicious that we had a bug of this sort months ago, but I was having some difficulty defining the problem.

I believe this addresses your issue:

c331446

I plan on adding some more tests and refactoring a bit, but hopefully it works for you ATM.

[cemerick]

Confirmed that master now highlights the regex as expected. However, paredit remains busted at all points after such regexes. Do you know if that's strictly a paredit issue? I thought perhaps there was an interaction between vim-clojure-static and paredit in this case (since a string containing escaped backslashes doesn't confuse paredit at all).

[guns]

Are you using the latest release of paredit.vim? I haven't used paredit in a long time, but it looks like the author added special support for regexps in this patch (this is from a local git-hg repo):

author Tamas Kovacs <kovisoft@gmail.com> Wed Mar 13 09:40:47 2013 +0100
committer Tamas Kovacs <kovisoft@gmail.com> Wed Mar 13 09:40:47 2013 +0100

Handle VimClojure's #"" regexp syntax definition


diff --git a/plugin/paredit.vim b/plugin/paredit.vim
index 13a14fd..9317ab9 100644
--- a/plugin/paredit.vim
+++ b/plugin/paredit.vim
@@ -1,7 +1,7 @@
 " paredit.vim:
 "               Paredit mode for Slimv
 " Version:      0.9.10
-" Last Change:  06 Mar 2013
+" Last Change:  12 Mar 2013
 " Maintainer:   Tamas Kovacs <kovisoft at gmail dot com>
 " License:      This file is placed in the public domain.
 "               No warranty, express or implied.
@@ -501,7 +501,8 @@ function! s:InsideString( ... )
         let quotes = substitute( line, '[^"]', '', 'g' )
         return len(quotes) % 2
     endif
-    return s:SynIDMatch( '[Ss]tring', l, c, 0 )
+    " VimClojure and vim-clojure-static define special syntax for regexps
+    return s:SynIDMatch( '[Ss]tring\|clojureRegexp\|clojurePattern', l, c, 0 )
 endfunction

 " Is this a Slimv or VimClojure REPL buffer?

[cemerick]

Yeah, I'm effectively running HEAD of paredit. I'll send the maintainer an email to see if he can confirm.

[guns]

Hello,

It appears that the author fixed this issue with the following commit.

Could you please confirm?

Thank you.

commit 44db722da521d76baff2751a6ff368a7716d3bc0
Author: Tamas Kovacs <kovisoft@gmail.com>
Date:   10 days ago

    Handle vim-clojure-static's #"" regexp syntax definition also when
    searching for paren matches
---
 plugin/paredit.vim | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/plugin/paredit.vim b/plugin/paredit.vim
index 2c5118c..3610a58 100644
--- a/plugin/paredit.vim
+++ b/plugin/paredit.vim
@@ -1,7 +1,7 @@
 " paredit.vim:
 "               Paredit mode for Slimv
 " Version:      0.9.11
-" Last Change:  10 Aug 2013
+" Last Change:  13 Aug 2013
 " Maintainer:   Tamas Kovacs <kovisoft at gmail dot com>
 " License:      This file is placed in the public domain.
 "               No warranty, express or implied.
@@ -64,7 +64,7 @@ endif
 " =====================================================================

 " Skip matches inside string or comment or after '\'
-let s:skip_sc = '(synIDattr(synID(line("."), col("."), 0), "name") =~ "[Ss]tring\\|[Cc]omment\\|[Ss]pecial" || getline(line("."))[col(".")-2] == "\\")'
+let s:skip_sc = '(synIDattr(synID(line("."), col("."), 0), "name") =~ "[Ss]tring\\|[Cc]omment\\|[Ss]pecial\\|clojureRegexp\\|clojurePattern" || getline(line("."))[col(".")-2] == "\\")'

 " Valid macro prefix characters
 let s:any_macro_prefix   = "'" . '\|`\|#\|@\|\~\|,\|\^'

[cemerick]

Yes, sorry, I thought you had closed the issue. :-)