Skip to content
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

Inconsistent cursor behaviour after evaluation of clojure code resulting in error #3331

Closed
practicalli-johnny opened this issue Apr 5, 2023 · 1 comment · Fixed by #3382

Comments

@practicalli-johnny
Copy link
Contributor

Expected behavior

Consistent behaviour of the cursor after evaluating an expression in the buffer that causes an error.

The behaviour should happen irrespective of if cider-show-error-buffer is set to t or nil (except when t then q should be pressed to quit the error buffer)

Actual behavior

Cursor inconsistent movement after evaluating an expression in the buffer that causes an error (incorrect clojure code)

Steps to reproduce the problem

Open a Clojure .clj file from a project which has a namespace definition:

  1. Call a function that is not defined and the cursor will jump to the opening bracket of the call expression, |(foo)
  2. Call an evaluated function with incorrect number of arguments, cursor does not move
  3. Evaluate a non-existent symbol, e.g blahblah and the cursor jumps to the top of the namespace

It is assumed that 1. and 2. would behave the same, the cursor jumping to the start of the calling expression (or not moving)

Behaviour 3 feels quite strange, I dont know what value is provided by the cursor jumping away (I appreciate this situation would not happen very often though)

Is there a way to customise the cursor movement on error? Or is it simply the way its been implemented?

Environment & Version information

CIDER version information

CIDER 1.7.0-snapshot (package: 20230226.1413)
nrepl 1.0.0

Lein / Clojure CLI version

Clojure CLI version 1.11.1.1252

Emacs version

Emacs 28

Operating system

Ubuntu 22.04

JDK distribution

openjdk version "17.0.6" 2023-01-17
OpenJDK Runtime Environment (build 17.0.6+10-Ubuntu-0ubuntu122.04)
OpenJDK 64-Bit Server VM (build 17.0.6+10-Ubuntu-0ubuntu122.04, mixed mode, sharing)
@vemv
Copy link
Member

vemv commented Jul 26, 2023

Evaluate a non-existent symbol, e.g blahblah and the cursor jumps to the top of the namespace

The root of this issue is in https://github.com/nrepl/nrepl.

CIDER side, this is what we see in *nrepl-messages*:

(<--
  id         "78"
  session    "51c180df-3551-4bcf-a0ec-b228af11aadd"
  time-stamp "2023-07-26 18:21:58.347447000"
  err        "Syntax error compiling at (test/orchard/misc_test.clj:1:8382).
Unable to resolve symbol: asdsad in this context
"
)

The 1:8382 line/colmun info (coming from nrepl) is spurious. cider.el cannot know that.

The problem can be reproduced like so in nrepl by adding the following test to core_test.clj:

(deftest foo
  (testing "Ensure server starts with minimal configuration"
    (let [server (server/start-server)
          ^nrepl.transport.FnTransport
          transport (connect :port (:port server))
          client (client transport Long/MAX_VALUE)]
      (is (= ["3"]
             (-> (message client {:op "eval" :code "foo"})
                 combine-responses
                 (doto clojure.pprint/pprint)
                 :value))))))

...which will print this:

{:err
 "Syntax error compiling at (/private/var/folders/yc/h50n8fgn0h79y848sfkr942h0000gn/T/form-init2709484432919812969.clj:1:6419).\nUnable to resolve symbol: foo in this context\n",
 :id "eaba1de4-c2d7-4d7a-898e-7e74541e569e",
 :session #{"3940485a-460f-42af-b942-02d0db05049c"},
 :ex "class clojure.lang.Compiler$CompilerException",
 :root-ex "class clojure.lang.Compiler$CompilerException",
 :status #{"eval-error" "done"}}

The form-init2709484432919812969.clj:1:6419 part should look familiar: the 1:6419 part is wrong.

In a vanilla Clojure repl, line/column info is cleaner: Syntax error compiling at (REPL:0:0).

So, getting this fixed would involve at least one of these:

  • not including line/col info when it doesn't make sense
    • 0:0 might be too confusing - better to have it absent
  • mark exceptions without a possibly accurate line/col info as such
    • i.e., do include 1:6419, but flag it
      • this keeps backwards compat.

All in all, this seems quite tricky to work on, for what appears to be a relatively minor bug?

From OP, 1. and 2. seem quite correct (although seemingly inconsistent between them), while 3. seems more annoying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants