Filter special form symbols from eldoc args list

[quanticle]

Fixes #165.

Currently, the eldoc args list for special forms includes the special form itself, which throws off the highlighting in Emacs' CIDER. This patch removes the special forms themselves from the args list. It specifically omits the Java interop special forms, because these, for some reason, do not include themselves in the :forms vector.

[vemv]

Thanks much for the accurate reports and initial PR!

[quanticle]

I updated the PR to take the approach that you described. I've added an option for info*, :dedup-special-forms, which does the special form filtering for eldoc. I've broken out the filtering logic into a separate function, dedup-forms-list, which takes an info map, checks to see that it represents the metadata for a special form (by checking the :special-form flag), and then, filters out the special form itself from the :forms lists. I also added unit tests for dedup-forms-list and an additional unit test for info* that passes the :dedup-special-forms flag and verifies that info* returns the filtered metadata.

EDIT: The code to actually invoke info* with this flag will be in cider.nrepl.middleware.info/eldoc-reply. I'll have that PR up soon as well.

[bbatsov]

I'm a bit puzzled about the need to make this deduping conditional. Are there cases when we'd actually want this?

P.S. I'm also puzzled that for 10 years nobody reported this when in hindsight the problem is obvious. :D

[bbatsov]

I've also been thinking that if want to adjust this only for Eldoc we can just as easily do it on the Elisp side. The current approach will not solve the problem for someone running CIDER without cider-nrepl as nREPL's info op is different (simpler).

[quanticle]

If a user wrote a function whose first parameter was the same name as the function itself, i.e:

(defn foo [foo bar baz]
  (println foo bar baz))

we probably would not want to filter out the first argument because it's the same name as the function itself.

I initially tried to do this in the elisp code, but the obstacle I ran into was the fact that eldoc-info in the elisp didn't have any information as to whether the symbol was a special form or not. As far as I understand, eldoc only expects function or variable, and cider-nrepl pretends that special forms are functions.

[quanticle]

Actually, now that I take another look at it, I see that cider-eldoc-thing-type in cider-eldoc.el, does have code to handle special-form. However, in eldoc.clj, the code only seems to return one of variable or function.

So instead of filtering here, what I could do is update extract-eldoc in eldoc.clj to also indicate whether the value is a special form.

Then, on the elisp side, it seems like it would be more straightforward to implement the filtering logic.

[bbatsov]

I'd be fine with this, although this still leave the problem with nREPL without cider-nrepl (and orchard). This information will be missing there.

Give how few the special forms are and they've never changed I guess we can just hardcode them in the Elisp code as a quick solution.

[quanticle]

I've written up the change on the CIDER side, in PR #3233.

[vemv]

lgtm!

Happy to see a simplified version - the less code the better!

[bbatsov]

@quanticle Don't forget to add a changelog entry for this.

[bbatsov]

@quanticle Ping :-)