Proposal: corfu-top and corfu-bottom

[mentalisttraceur]

I suggest these two helpers, to round out the options for moving around in the Corfu pop-up:

(defun corfu-top ()
    ;; Go to the top visible candidate.
    (interactive)
    (corfu--goto corfu--scroll))

(defun corfu-bottom ()
    ;; Go to the bottom visible candidate.
    (interactive)
    (corfu--goto (+ corfu--scroll (1- corfu-count))))

There's no strong need for these, but currently this can only be done by relying on Corfu's private functions/variables.

I wanted this because when I'm in a Corfu pop-up, I intuitively expect my keybinds for evil-window-top and evil-window-bottom to work as if the Corfu pop-up is a mini window.

inb4: not the same as corfu-first/corfu-last, those move over all candidates, these proposed functions only move within currently displayed candidates.

[minad]

Hi! Thanks for the suggestion. I think these commands are not generally useful enough to add them to Corfu. Every command we add, has a small cost. It adds to the complexity of the UI, to the list of commands a user may have to understand. I looked at Company and despite it is much older than Corfu, it doesn't offer these commands. If the commands are needed specifically for Evil, my suggestion is to add them to the evil-collection.

[mentalisttraceur]

@minad I agree, but then bigger-picture suggestion/question: are corfu--scroll and corfu--goto public API with stability guarantees or not?

[mentalisttraceur]

I mean: maybe we just have different ideas about what should be public API or what the public/private distinction means... but personally in everything I maintain, if a user has a use-case I don't want to upstream, I'm either saying

• "you can implement what you want with just these public APIs" (and this implies a guarantee that it will continue to work at least until [first release with some well-defined version number change]), or

• "I think doing this is always wrong actually, here's a better alternative".

And this feels like a weird middle-ground where the relevant pieces of Corfu are named as if they're private (== have no stability guarantees) but you're suggesting adding this into the widely used evil-collection (which I would only do if it's basically/realistically stable, in which case I'd say that through code by making the names look like public names).

[minad]

This is Emacs. You can use private APIs. Corfu is reasonably stable, even the private parts (check the history, git blame), but I won't give guarantees that the private parts will stay exactly as is. If your argumentation would hold, either every proposal would have to make it in, or in the end almost everything would be public. Neither are good options.

[mentalisttraceur]

(I probably won't reply again if degree and flavor of disagreement remains similar. But as an aside: thanks for making Vertico, Consult, and Corfu. I use all of those and they're really nice. I think my only nit with them is where you put the public/private API boundary, especially with Consult. Overall great packages which make both the Emacs ecosystem and my day-to-day use of Emacs a lot better.)

You can use private APIs.

Private vs public has almost nothing to do with raw ability to use and almost everything to do with what assumptions a user can reasonably make.

The value-add of "public" is that we users can trust that reading just the docs (docstrings, package description, README, etc) is sufficient for correct usage of public API, and that you'll let us know (in some way that you define) if you change things in ways that any usage which stuck to that the docs described.

but I won't give guarantees that the private parts will stay exactly as is

API stability guarantees have never meant code stays exactly as-is (let alone forever).

In my last comment it's clearly stated that I mean something different: "a guarantee that it will continue to work, at least until [...]".

If it changes in ways that don't break usage which you said would work, that's still stable.

If it changes in a way that does break, but it's clearly communicated by whatever method you said in the docs you'd use to communicate breaking changes, no stability guarantees have been broken.

For example, almost no one would need consult--scroll, the variable - a mere getter function would provide most/all of the value, and can be easily kept stable even if the internals change. (Stability guarantees become even less limiting to changing the implementation if the public interfaces merely make opaque interlocked promises, like if the getter function only guarantees that it returns something that the goto function can use, etc.)

If your argumentation would hold, either every proposal would have to make it in, or in the end almost everything would be public.

In my experience it actually tends to settle into a middle ground where the public API is flexible/composable enough to enable most creative uses (and there's usually still things which stay private because they're just not particularly useful/reusable by themselves in other contexts... but also, in small packages it's perfectly reasonable for almost everything to be public: if you've sliced and covered a problem space really well, most of the building blocks that were useful to you are also going to be very useful to others).

[minad]

I think you simply misunderstand the design of my packages. My packages make all user facing functionality public (commands, customizable variables). Everything else is private. The packages are meant as user-facing and are not meant as libraries or "backend" packages. Nevertheless they are easily hackable and extensible - I take care about this in the structure of my packages and I also try to avoid breakage. There is just no strong guarantee about private APIs.

I probably won't reply again if degree and flavor of disagreement remains similar.

To be clear, this tone is not acceptable. I am glad that you like my projects and that they help you in your workflow. But you cannot come here and put forward demands in this way.