cider-undef does not unmap vars from other namespaces

[yuhan0]

Expected behavior

Calling cider-undef on a fully qualified symbol foo/bar should unmap the var from the corresponding (aliased) foo namespace.

Actual behavior

The var is not undefined (fails silently)

Steps to reproduce the problem

my/lib.clj

(ns my.lib)
(def abc 123)

my/app.clj

(ns my.app
  (:require [my.lib :as lib])

lib/abc

In the my/app.clj buffer, call M-x cider-undef with point on lib/abc.
Observe: the var is still accessible after the command.

Environment & Version information

CIDER version information

;; CIDER 0.25.0snapshot (package: 20190708.1036), nREPL 0.6.0
;; Clojure 1.10.1, Java 13.0.1

Emacs version

26.3

Operating system

macOS 10.15

[yuhan0]

This should be a relatively straightforward fix I'm willing to tackle, but it's not clear whether it should be the responsibility of cider or cider-nrepl.

Option 1:

cider.el ensures that ns and symbol params are simple symbols

• cider-undef sees lib/abc
  • uses regex to split it into "lib" and "abc",
  • calls (cider-resolve-alias "lib") => "my.lib",
  • and sends the message ("op" "undef" "ns" "my.lib" "symbol" "abc")

Option 2:

cider-nrepl library does the decoding:

• cider-undef sends the message ("op" "undef" "ns" "my.app" "symbol" "lib/abc")
• cider.nrepl.middleware.undef/undef notices that (symbol "lib/abc") is fully qualified
  • calls namespace, name to get "lib" and "abc"
  • (get (ns-aliases "my.app") "lib") => "my.lib"
  • (ns-unmap "my.lib" "abc")

[bbatsov]

Probably option 2 would be more efficient, as you need to call the undef op anyways.

[yuhan0]

Do you mean the resolve-alias op? Both options are calling the same undef op, I don't really think it's a matter of efficiency but whether to narrow the message spec vs. broaden the input parsing on the backend.

[bbatsov]

I'm puzzled. There's no resolve-alias op. My main point was that if the middleware is smarter this automatically benefits all clients using it.