I'm getting the following error from selectrum a19bbe9 when trying to use an environment variable to change directories in find-file.

Error in post-command-hook (selectrum--update): (file-error "Getting attributes" "File name too long" "/home/mohkale/.config/dotfiles/core/org/notes/
    --bind ctrl-j:down
    --bind ctrl-k:up
    --bind ctrl-u:page-up
    --bind ctrl-d:page-down

    --bind alt-u:preview-page-up
    --bind alt-d:preview-page-down
    --bind ctrl-n:preview-down
    --bind ctrl-p:preview-up
    --bind ctrl-i:toggle-preview
    --bind alt-i:toggle-preview

    --bind shift-left:backward-word
    --bind shift-right:forward-word
    --bind ctrl-b:backward-word
    --bind ctrl-f:forward-word
    --bind ctrl-h:backward-char
    --bind ctrl-l:forward-char

    --bind alt-return:print-query
    --bind alt-bspace:clear-query

    --bind alt-j:accept
    --bind alt-k:accept-non-empty
    --bind alt-q:jump
    --bind ctrl-q:jump-accept

    --bind alt-a:select-all
    --bind alt-x:deselect-all

    --bind \"ctrl-y:execute-silent(echo {} | clip)\"

    --bind ctrl-s:toggle-search

    --bind ctrl-space:toggle+down
    --bind ctrl-o:top

    --history /home/mohkale/.local/share/fzf/history/default
    --history-size 1000000
    --bind alt-j:next-history
    --bind alt-k:previous-history

    --color dark
    --color fg:-1,bg:-1,fg+:-1,bg+:-1,hl+:#e93c58,hl:#df5273
    --color info:#af87ff,prompt:#5fff87,pointer:#ff87d7,marker:#ff87d7,spinner:#ff87d7

    --cycle
")

The long string shown above is the value of my FZF_DEFAULT_OPTS environment variable.

I don't recall encountering this before, but it's strange that emacs is considering inputs that aren't file paths as possible environment variable completions in find-file.

I'm not getting this error any more. This can be closed for now :smile:.

@oantolin Did you have another chance to look at this PR?

Well, not everything, just things with those letters in any order, which is what I thought you wanted.

But yes, that does typically lead to way too many matches, which is why I predicted you wouldn't like it. For my taste even flex matching produces too many matches.

@oantolin for me it just started matching everything, in kinda random way

there might be a way to also type deletepa to get the same result

You can try the advice in my previous comment, I'd say that is a way to get the same result.

@oantolin yeah i knew about adding spaces i just thought that just like i can type padelete to get package-delete there might be a way to also typedeletepa` to get the same result

Well, if you are willing to add spaces, pa delete and dele pack both match package-delete even with just the literal matching style. I think this is what I recommend: turn off flex, and just add spaces to your input. You can do it liberally, for example, I never remember if the command is package-auto-remove or package-autoremove so I conservatively type au re pa and it would match either way.

But if you really want adeeeplt to match package-delete, you can replace the orderless-pattern-compiler:

(defun orderless-ultraflex (pattern &optional _styles _dispatchers)
  (mapcar #'string pattern))

(advice-add 'orderless-pattern-compiler :override #'orderless-ultraflex)

I suspect you won't really like the letter matching in absolutely any order.

I wonder if it's possible to set orderless to match package-delete by typing either padelete and/or delepack setting completion style to orderless-flex only achieves the former

Improves on the horizontal scrolling so that it behaves more like Emacs' autmoatic hscrolling.

Thank you @minad !

There is also https://github.com/minad/vertico/pull/64, you can give this a try.

Another option would be to implement it on the level of the completion UI - adding commands there which reorder the groups. The grouping feature is a bit more general than Consult, it is implemented even in Emacs 28. The advantage of implementing the feature in the completion UI directly would allow to work with all commands supporting groups, not only consult-buffer.

There is no exact equivalence of the functionality you are asking for - cycling the sources. However for example Vertico has vertico-next/previous-group commands which allow you to jump between groups. These commands are bound to M-{} (remapping forward/backward-paragraph). We could also add such source cycling commands to Consult directly, which would work with consult-buffer. So far nobody has requested this feature and I am generally fine with having a slightly leaner feature set in comparison with Helm. But having such a cycling feature does not sound unreasonable to me - I may write a small prototype to see how it will look.

I used Helm last 3-4 years, but some time ago I realize I use only a few commands on daily basis. So I found a Consult+Selectrum as lightweight replacement of Helm.

I used to helm-multi-files command which has almost the same output as consult-buffer. I changed sources using [C-right], [C-left] bindings. If I press [C-right] the top source changed from buffer list to recent-file list, next press changes top source to bookmark list, etc.

If I press [C-left] top source is recent-file list again.

Can I configure the same behavior for Consult(Selectrum)?

Org already provides a rich set of keybindings for all the various operations one may want to perform on the object at point. What do we win by embarking these commands?

Good question.

I guess it's only valuable if you want to add access to additional contextual actions beyond those provided in org.

It makes sense for the new org-cite, for example.

To repeat my opinion regarding this generic org target finder and org actions in general:

1. I prefer to have a flat list of finders, not something nested. While one saves the parsing effort with the nesting, the advantages are marginal. Embark target finders are not really performance critical.
2. The first step should be to identify the actions we want to have here. There are two other projects we can use for reference:
   • sheijk's transient org-menu
   • jyp's cmap, which started as a fork of Embark and only provides the at-point functionality
3. How can one add such target finders, such that they are not always loaded? Only enable it in orgmode I suppose. There is however one scenario, where this approach is lacking: I would like to have global org link actions, in the style of org-open-at-point-global. There are org link regular expressions which could be reused. This allows to use org links as Hyperbole-style buttons everywhere. See my Hyperbole/Org comment on reddit.
4. For org actions at point it may be useful to have repeatable actions (see #244 and #245). cmap has repeatable actions too mainly for org actions at point.
5. Of course there is the question if we need this at all. Org already provides a rich set of keybindings for all the various operations one may want to perform on the object at point. What do we win by embarking these commands?

@oantolin Which concrete sexp-at-point actions would you like to see here? We could normalize the commands by calling (bounds-of-thing-at-point 'sexp) and then moving the point either to the beginning or the end depending on what the command requires.

Per my comment over there, just wanted to make sure you're aware of the native org-cite functionality that's about to be merged.

That includes new citation and citation-reference org objects.

At bibtex-actions, we're actually including a target finder for it, with the intention to turn it into a "follow" processor.

https://github.com/bdarcus/bibtex-actions/pull/143 https://github.com/bdarcus/bibtex-actions/issues/141

@oantolin

I think using the very numerous commands that act on the sexp before or after point would be better.

Actually I would like to have both string commands and the at-point commands. If we don't use strings we cannot reuse the embark-general-map. Therefore I think my current approach is justified.

Putting the at-point commands into the embark-expression-keymap is a bit more problematic, since these commands require a specific point location. It seems to me that we cannot reuse any of the existing commands as is. We would have to write wrappers for all of the at-point commands, which adjust the location. This is an open end in my PR #248.

In comparison, the defun commands in the defun map are also at-point commands. The target finder also returns a string target to support the general-map. The difference of the defun commands is that these work everywhere inside the defun, while the sexp commands are more strict regarding the point location.

load would be another.

Don't you have to call load with a string?

Ah, yes, you're right.

The one thing I'm not sure about with #248 is using strings for s-expressions. I think using the very numerous commands that act on the sexp before or after point would be better.

(Decided to commit from my phone.)

This is indeed a pressing issue which required intermediate intervention. What about my PR #248? I recommend to merge it without proper testing or review from the phone. This is what the github webui is for, isn't it?

load would be another.

Don't you have to call load with a string?

(Decided to commit from my phone.)

load would be another.

For my taste the ffap file finder conflicts too often with the symbol target finder. I would prefer the file finder to only match filenames with extensions or slashes. Probably this can be configured by modifying the ffap-alist. However I want to keep the more fuzzy ffap functionality enabled globally. Should I use an advice around the file target finder or should we improve this in Embark itself?