-
-
Notifications
You must be signed in to change notification settings - Fork 646
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Eval'ing (keyword "\"|") gives "Search failed" error #1971
Comments
This appears to be a bug in Here's a stacktrace:
|
Garbage in, garbage out. I think we should close this, not complicate the code with this strange edge-case, and direct work toward useful features. |
@expez I agree to some extent, but I think we should at least handle this error, so it doesn't propagate to the users. I think in the case of garbage in we should apply no font-locking. That'd be simple and better UX imo. |
Probably adding handling for those chars would not be complex either, but I don't have time to look into this. |
While the reader allows it, the spec does not include
But then again, a number of libraries grossly violate the ban against
|
Maybe this should be a separate issue, but I get the same error when evaluating the following:
Ran into this because I needed to generate ASCII characters sequentially. I reduced it down to this particular range in this particular order, which is:
If you start higher than 33 or end lower than 41(40), it will print just fine. Runs fine on repl.it, and also works fine if you just It will also choke if you just try to evaluate the string itself:
And I found that you can strip out all characters except the following to reproduce it:
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contribution and understanding! |
This issues been automatically closed due to lack of activity. Feel free to re-open it if you ever come back to it. |
I get this often when printing a large map or vector to the REPL. I updated today to clojure-mode-20191112.1948 but it doesn't help. You should be able to reproduce it with the attached file: |
Here is another interesting case of this. This prints fine for me:
While this fails:
The only difference is that the first one (working) is a vector and the second one (failing) is a list. Seen in
Hope that helps. |
Interesting! I still get these "process filter" errors often, but I can't grok the regular expression reported; you can find it in clojure-mode.el. I just don't know what it is trying to do, much less why it should throw an error rather than just give up. Your test cases suggest that it needs to gets engaged in the search to fail. It gets engaged with it with the list owing to \( in the regex. I wonder whether changing \( to \[ and \) to \] would cause the first test case to fail and the second to succeed (reversing the situation). |
Yeah, we'll have to see what exactly's wrong with the fontification regex, although this bit of code fontifies fine in Btw, I don't recall if I mentioned this, but that's another problem related to @yuhan0 Do you have some time to look into the the regexp in |
Hi Both! I appreciate your time and consideration. Here is the regex in question: It looks like the elisp function in play here is Which has a @bbatsov - is the stuff we're handing over to be fontified sliced on the arbitrary 1kb buffers we were discussing on the other thread (#2628)? If so, there may be assumptions in the clojure-mode code that what is to be fontified is somehow more well-formed than the input we're giving it ends up being in some cases. Another idea would be to catch the error, maybe here:
And then (if possible) do something better than just silently dropping the rest of the output and leaving the REPL in a funny state. Just thoughts, hope that helps. Thanks, all. |
Yeah, exactly. Funny enough both unrelated issues are related to the same fontification code. :-) Both options you mentioned are valid approaches to tackle this, although ideally we should see if we can refine the regexp. I'll think about this a bit more. |
Perfect - let me know if there's more I can do to help. Fontifying arbitrarily cut snippets seems tough in general - no surprise there are complications in this area. Keep up the awesome work! |
Btw, I made a mistake above - obviously the two issues are quite related. :-) In general both would be addressed by something trying to apply the font-locking only to a single chunk result. I'm also thinking that if we simply check if the form we send for fontification is balanced that would also solve both problems. You can really enter something unbalanced in the REPL anyways. Fix incoming. :-) |
I came up with a simple fix that seems to work - if an expression is not balanced we simply don't try font-lock it. As chunks are not balanced - magic... :-) |
Expected behavior
When evaluating
(keyword "\"|")
, the keyword:"|
should be displayed in the minibuffer.Actual behavior
When evaluating
(keyword "\"|")
, the minibuffer displays a regex error:Steps to reproduce the problem
Evaluate
using cider-eval-last-sexp or a similar command.
Alternatively, evaluate
and try evaluating k.
Environment & Version information
Using the clojure configuration layer in spacemacs
CIDER version information
Lein/Boot version
Lein 2.6.1
Emacs version
Gnu Emacs 24.5.1
Operating system
OS X Sierra
Other notes
xiongtx on Slack brought up a good point that
"
and|
are technically not considered valid characters for clojure keywords and symbols, even though they generally work in practice.The text was updated successfully, but these errors were encountered: