CIDER: wrong-type-argument number-or-marker-p

[manuel-uberti]

Hi,

first of all thanks for a thin variant of Company. I am trying it in combination with CIDER, which is where usually I need code completion the most.

I set up corfu as described in the README (so TAB kicks it in), with CIDER locally setting completion-styles to '(cider). When I hit TAB to complete aero/ I get this:

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p (#("aero/deferred" 0 1 (ns "aero.core" type "macro")) #("aero/->Deferred" 0 1 (ns "aero.core" type "function")) #("aero/read-config" 0 1 (ns "aero.core" type "function")) #("aero/default-opts" 0 1 (ns "aero.core" type "var")) #("aero/map->Deferred" 0 1 (ns "aero.core" type "function")) #("aero/root-resolver" 0 1 (ns "aero.core" type "function")) #("aero/adaptive-resolver" 0 1 (ns "aero.core" type "function")) #("aero/relative-resolver" 0 1 (ns "aero.core" type "function")) #("aero/resource-resolver" 0 1 (ns "aero.core" type "function")) #("aero/resolve-tagged-literals" 0 1 (ns "aero.core" type "function")) #("aero/read-config-into-tagged-literal" 0 1 (ns "aero.core" type "function"))))
  (completion--do-completion #<marker at 475 in core.clj> 480)
  (completion--in-region-1 #<marker at 475 in core.clj> 480)
  (#f(compiled-function (start end collection predicate) #<bytecode 0x17631f3c7348f15c>) #<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil)
  (apply #f(compiled-function (start end collection predicate) #<bytecode 0x17631f3c7348f15c>) (#<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil))
  (#f(compiled-function (funs global args) #<bytecode -0xf9a12fa2f4bda2>) nil nil (#<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil))
  (completion--in-region #<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil)
  (apply completion--in-region (#<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil))
  (corfu--completion-in-region #<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil)
  (completion-in-region #<marker at 475 in core.clj> 480 #f(compiled-function (string pred action) #<bytecode -0xd664e5fa0334041>) nil)
  (completion-at-point)
  (indent-for-tab-command nil)
  (funcall-interactively indent-for-tab-command nil)
  (call-interactively indent-for-tab-command nil nil)
  (command-execute indent-for-tab-command)

FTR, this is on Emacs 28 (2822246b5d8154d0166e17ffd28a1d85b57d68aa) with latest corfu.

[minad]

This sounds like a bug in the CIDER completion style? Why does it use its own? Disable both company and corfu and use default TAB completion. Do you also see the error then? The error occurs in completion--in-region-1 which is the default completion function, Corfu initializes itself only after that.

[manuel-uberti]

You're right, it happens without Corfu nor Company. I'll report it to CIDER. Sorry for the noise.

[manuel-uberti]

Without using (cider) for completion-styles, CIDER offers a buffer with completion. Corfu, instead, offers completions only when I set completion-styles to its default value.

[manuel-uberti]

Note that globally I use orderless for completion-styles.

[minad]

No idea what you are talking about but this is clearly a cider issue :-P

[minad]

@manuel-uberti Can you please link to the corresponding CIDER issue or didn't you manage to reproduce it with default completion after all? clojure-emacs/cider#3005 is not related.

[minad]

I looked again into this and I found a bug in how I handled the return value of completion-all-completions in both Corfu and Vertico. I still wonder if this fixes the CIDER issue. And the completion style installed by cider is questionable, see clojure-emacs/cider#3006.

[manuel-uberti]

Thanks for having looked into it. The issue I reported on CIDER was related to default completion, but I got it wrong because I wasn't setting tab-always-indent to 'complete. As I wrote above, with CIDER + Corfu + Orderless I wasn't getting any completion offered. Now, as soon as 1e966ab is on ELPA I'll give it another try and let you know.

[manuel-uberti]

Actually, I cloned the GitHub repo and give it a spin, but I am still not getting any completion with completion-styles set to '(orderless). If I set it back to its default value TAB works.

[minad]

It is okay if orderless does not work with cider. Completion styles are more problematic with completion-at-point, see also #5. But the error does not occur anymore?

[manuel-uberti]

Correct, there is no error any more. Thanks for the explanation.

[minad]

Okay, thanks. Then the error was me after all since I assumed that completion-all-completions always returns a very specific form with an integer in the last cdr. Nevertheless, the completion style specified by cider is still invalid (clojure-emacs/cider#3006).

[minad]

Btw, does this package work well for you or do you miss something? Maybe I will add history based sorting but this would mean that corfu will has to maintain its own history variable (See the history branch). Then there is the question if any kind of idle completion is needed. I also quickly experimented with this, but I find this more annoying than helpful.

[manuel-uberti]

Generally it works well for me, yes. I am usually happy with dabbrev for quick completion, but there are times where tab-completion is helpful, so this is a nice package indeed.

[minad]

@protesilaos would like to see a capf dabbrev backend such that he can use the normal completions mechanism together with dabbrev. Then dabbrev would also work ootb with Corfu. Right now dabbrev makes its own thing and does not go through capf.

[jaor]

On Sun, Apr 18 2021, Daniel Mendler wrote: Then there is the question if any kind of idle completion is needed. I also quickly experimented with this, but I find this more annoying than helpful.

if you don't mind my interjecting, i use company's idle completion and find it very useful. force of habit has made me not be surprised or annoyed at the little pop-ups if i pause to think, and i very often discover new functions or variables because of them (many times i wouldn't have thought of pressing TAB, because i would have assumed, wrongly, that i know about all possible completions).

[minad]

@jaor

if you don't mind my interjecting, i use company's idle completion and
find it very useful. force of habit has made me not be surprised or
annoyed at the little pop-ups if i pause to think, and i very often
discover new functions or variables because of them (many times i
wouldn't have thought of pressing TAB, because i would have assumed,
wrongly, that i know about all possible completions).

I agree with your arguments. However my negative impression of this feature is mostly based on my experience from quite a while ago where I often had seen a big slowdown or hangups due to LSP servers. It all depends on how well the language backend behaves. I guess the situation also improved.

If we would consider idle completion - how could it look? For example the automatic popup could be made such that it is grayed out and does not immediately install its keymap. Only after pressing TAB you access the normal Corfu popup. But this could also be made optional such that one gets the fully popup directly. This is more intrusive then since the navigation keys are rebound.

[jaor]

On Mon, Apr 19 2021, Daniel Mendler wrote: I agree with your arguments. However my negative impression of this feature is mostly based on my experience from quite a while ago where I often had seen a big slowdown or hangups due to LSP servers. It all depends on how well the language backend behaves.

indeed. i for one find the lsp uis very annoying, and their paradigm not that compelling compared to interaction based on repls such as cider, slime or haskell-interactive. with the latter, that most of the time provide excellent capfs, company-style idle pop-ups are much less intrusive.

If we would consider idle completion - how could it look? For example the automatic popup could be made such that it is grayed out and does not immediately install its keymap. Only after pressing TAB you access the normal Corfu popup.

that's an interesting idea, and most possibly an improvement over what company provides. i guess one could alternatively offer a set of faces to be used for idle display (for instance, one could prefer just a different background, rather than a uniform graying (which could be the default for those faces)).

But this could also be made optional such that one gets the fully popup directly. This is more intrusive then since the navigation keys are rebound.

not rebinding keys sounds definitely useful: if memory serves, i had to train my muscle memory (and perform some customization i've forgotten) to avoid company's pop-ups to mess with my writing. on the other hand, it's true that having the same behaviour in both cases in the long term helps, because one doesn't have to think twice to interact with the pop-up... so i am really on the fence on this one.

[minad]

indeed. i for one find the lsp uis very annoying, and their paradigm not
that compelling compared to interaction based on repls such as cider,
slime or haskell-interactive. with the latter, that most of the time
provide excellent capfs, company-style idle pop-ups are much less
intrusive.

Also your geiser? Before dabbling with emacs code recently I was more into schemes actually, but haven't touched those for a while. But I still appreciate the lsp efforts, this is very good for the general ecosystem. I also have lsp-mode installed currently but maybe eglot fits me better from the spirit (minimal, few dependencies, ...).

that's an interesting idea, and most possibly an improvement over what
company provides. i guess one could alternatively offer a set of faces
to be used for idle display (for instance, one could prefer just a
different background, rather than a uniform graying (which could be the
default for those faces)).

To be clear - it's not my idea. I think Stefan Monnier proposed this in an old thread which I scrolled through recently. But this idea is certainly the one which I would feel most comfortable with, since it could be made non-intrusive. Yes, the idea is to use different faces.

not rebinding keys sounds definitely useful: if memory serves, i had to
train my muscle memory (and perform some customization i've forgotten)
to avoid company's pop-ups to mess with my writing. on the other hand,
it's true that having the same behaviour in both cases in the long term
helps, because one doesn't have to think twice to interact with the
pop-up... so i am really on the fence on this one.

It's worth an experiment I guess :)

[jaor]

On Mon, Apr 19 2021, Daniel Mendler wrote: Also your geiser? Before dabbling with emacs code recently I was more into schemes actually, but haven't touched those for a while.

for guile and racket geiser is decent yes, and chicken 4 wasn't obnoxious. unfortunately, many things broke for chicken 5, and the racket community first duplicated lots of efforts with another mode and now are just becoming python with rhombus... but i digress :)

But I still appreciate the lsp efforts, this is very good for the general ecosystem. I also have lsp-mode installed currently but maybe eglot fits me better from the spirit (minimal, few dependencies, ...).

yes. for erlang and elixir their lsps are the only game in town, and i've used them with eglot (same reasons as yours). i admit it's not bad!

It's worth an experiment I guess :)

i'll be, as always, very grateful for your efforts :) i feel a bit guilty for not having contributed any code to your triumvirate (or omar's embark and orderless), just idle talk, but i hope that'll eventually change!

[minad]

for guile and racket geiser is decent yes, and chicken 4 wasn't
obnoxious. unfortunately, many things broke for chicken 5, and the
racket community first duplicated lots of efforts with another mode and
now are just becoming python with rhombus... but i digress :)

What do you think about Chez? This is the most solid implementation I believe. I also liked Racket since they spent a lot of effort polishing documentation and the libraries. But Racket is ultimately a different language. I've not heard about Rhombus but I stopped using Racket as soon as Chez became available, the Racket runtime is also rebased on that now.

but i hope that'll eventually change!

Yes, I am looking forward to that!

[jaor]

On Mon, Apr 19 2021, Daniel Mendler wrote: > for guile and racket geiser is decent yes, and chicken 4 wasn't obnoxious. unfortunately, many things broke for chicken 5, and the racket community first duplicated lots of efforts with another mode and now are just becoming python with rhombus... but i digress :) What do you think about Chez? This is the most solid implementation I believe.

i haven't tried it in earnest. its geiser module was a contrib and it's never worked for me, so that's been a barrier in my case. exploring it more it's been in my list for ever though, as i keep hearing and seeing good things about it. the last one is that it's one of the runtimes idris2 uses to boostrap itself. i haven't looked closely, but with other schemes the problem is usually that they lack lisp-like reflection APIs, and geiser needs them to really work well.

I also liked Racket since they spent a lot of effort polishing documentation and the libraries. But Racket is ultimately a different language. I've not heard about Rhombus but I stopped using Racket as soon as Chez became available, the Racket runtime is also rebased on that now.

a couple of years ago the core team decided that the key reason racket wasn't adopted by more people was... the parenthesis. and they're moving to a completely new surface syntax and a new renaming of the language to rhombus. that made me lose interest. if you're curious, i think this a balanced (and not too long) piece on the movement: https://beautifulracket.com/appendix/thoughts-on-rhombus.html .

[minad]

i haven't looked closely, but with other schemes the problem is usually
that they lack lisp-like reflection APIs, and geiser needs them to
really work well.

Yes, from my experience with Chez - it is pretty much the best runtime you will find regarding code generation. It would benefit from a better gc though (it has a multi generation copying gc). But besides that it is very bare bone. But for Idris it is a good compilation target.

a couple of years ago the core team decided that the key reason racket
wasn't adopted by more people was... the parenthesis.

Yes, moving to another surface language is not a very reasonable move. But to be fair, Racket always had this concept of multiple languages.