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

orchard.eldoc/extract-arglists does not handle many special forms correctly #165

Closed
quanticle opened this issue Jan 22, 2023 · 0 comments · Fixed by #166
Closed

orchard.eldoc/extract-arglists does not handle many special forms correctly #165

quanticle opened this issue Jan 22, 2023 · 0 comments · Fixed by #166

Comments

@quanticle
Copy link
Contributor

quanticle commented Jan 22, 2023

This is related to Cider bug #3307. It seems like the actual issue is that extract-arglists isn't correctly processing the forms list for many Clojure special forms. When I run

(pprint (orchard.eldoc/eldoc (cider.nrepl.middleware.info/info {:ns 'clojure.core :sym 'if})))

I get back

{:name "if",
 :eldoc (["if" "test" "then" "else?"]),
 :type "function",
 :docstring
 "Evaluates test. If not the singular values nil or false,\n  evaluates and yields then, otherwise, evaluates and yields else. If\n  else is not supplied it defaults to nil."}

Note that if is the first element of the :eldoc vector, which screws up the eldoc highlighting in emacs, because it expects the first element of the arglist to be test, not if itself.

Similarly, when I get the info for do

(pprint (orchard.eldoc/eldoc (cider.nrepl.middleware.info/info {:ns 'clojure.core :sym 'do})))

I get

{:name "do",
 :eldoc (["do" "exprs*"]),
 :type "function",
 :docstring
 "Evaluates the expressions in order and returns the value of\n  the last. If no expressions are supplied, returns nil."}

Just like with if, do is the first element of the :eldoc vector, which, once again, throws off the eldoc highlighting in emacs.

I got similar results with other special forms, such as, def and fn. The only special form I didn't get this result with was .:

(pprint (orchard.eldoc/eldoc (cider.nrepl.middleware.info/info {:ns 'clojure.core :sym '.})))

which returned

{:name ".",
 :eldoc
 ([".instanceMember" "instance" "args*"]
  [".instanceMember" "Classname" "args*"]
  ["Classname/staticMethod" "args*"]
  ["Classname/staticField"]),
 :type "function",
 :docstring
 "The instance member form works for both fields and methods.\n  They all expand into calls to the dot operator at macroexpansion time."}

So it seems like . is a special special form. I would propose that extract-arglists make a special case for ., and omit the first element when building the arglists for other special forms. I can make the change to eldoc.clj, but I wanted to raise the issue in a bug first, in order to solicit feedback on whether my suggested approach is the best one.

quanticle added a commit to quanticle/orchard that referenced this issue Jan 22, 2023
Fixes clojure-emacs#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.
quanticle added a commit to quanticle/orchard that referenced this issue Jan 22, 2023
Fixes clojure-emacs#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.
quanticle added a commit to quanticle/orchard that referenced this issue Jan 22, 2023
Fixes clojure-emacs#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.
quanticle added a commit to quanticle/orchard that referenced this issue Jan 27, 2023
Fixes clojure-emacs#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.

To do this, the code first checks the `:special-form` property. If it
is a special form, the code compares the `:name` property, which is
the symbol representing the special form, with the first element of
each of the lists in `:forms`. If the two are equal, that element is
omitted.
quanticle added a commit to quanticle/orchard that referenced this issue Jan 27, 2023
Fixes clojure-emacs#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.

To do this, the code first checks the `:special-form` property. If it
is a special form, the code compares the `:name` property, which is
the symbol representing the special form, with the first element of
each of the lists in `:forms`. If the two are equal, that element is
omitted.
quanticle added a commit to quanticle/orchard that referenced this issue Jan 27, 2023
Fixes clojure-emacs#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.

To do this, the code first checks the `:special-form` property. If it
is a special form, the code compares the `:name` property, which is
the symbol representing the special form, with the first element of
each of the lists in `:forms`. If the two are equal, that element is
omitted.
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.

1 participant