Unmatched close-paren when inside strings

[Patryk27]

Hi,

It looks like parinfer-rust / parinfer-rust-mode doesn't correctly track the context and e.g. writing something like this:

(map! :n "] E" 'next-error-in-different-file)

... will not parse, saying Unmatched close-paren. due to ] being treated as if it was written outside of a string :eyes:

[justinbarclay]

I can't recreate this. If you run this with emacs -Q, do you still run in this issue?

https://github.com/justinbarclay/parinfer-rust-mode/assets/6868388/504bd4bf-1a1d-4b14-972a-b72b8418ad41

[Patryk27]

Yes, same with emacs -Q:

For reference, I'm using:

/Users/pwy/.cache/.doom.local/straight/repos/parinfer-rust-mode
; git log
commit 332c7f47426f0519dc5c24dda82afdb1aa8b61ee (grafted, HEAD -> main, replaced, origin/main)
Author: Justin <justincbarclay@gmail.com>
Date:   Sat Feb 4 11:15:47 2023 -0800

    Add treat-command-as hints for Evil

... and parinfer-rust built from 3c769707ad3b18d530f696fe42a9d495139149ab (built manually since they don't provide binaries for aarch64-darwin).

I think parinfer-rust is able to parse this file correctly, because adding a simple test there:

diff --git a/tests/cases/paren-mode.json b/tests/cases/paren-mode.json
index 777fa85..ada217f 100644
--- a/tests/cases/paren-mode.json
+++ b/tests/cases/paren-mode.json
@@ -14,6 +14,21 @@
       "out": "(let [foo 1]\n foo)"
     }
   },
+  {
+    "text": "(map! \"] E\")",
+    "options": {},
+    "result": {
+      "text": "(map! \"] E\")",
+      "success": true
+    },
+    "source": {
+      "lineNo": 6,
+      "in": [
+        ""
+      ],
+      "out": ""
+    }
+  },
   {
     "text": "(let [foo 1]\n      foo)",
     "options": {},

... passes 👀

[vlnn]

I have same problem, using doom emacs in macos

[Patryk27]

Might be caused by parinfer-rust, after all - https://github.com/eraserhd/parinfer-rust/issues/139, https://github.com/eraserhd/parinfer-rust/pull/133.

[justinbarclay]

Is this still an issue for anyone? I still can't recreate it, but with v0.9.0 there should be better support for comment chars

[Patryk27]

I think it works correctly now 🙂

[justinbarclay]

Awesome, thanks for confirming 😄