Allow to mark, and act on, multiple candidates in collect buffer

[bdarcus]

The conversation here has me wondering:

Would it be possible, and wise, to allow one to mark, and act on, multiple candidates in a collect buffer, as in helm?

Use case:

I want to open multiple files, so I:

1. narrow the candidates
2. run embark-collect-snapshot
3. mark the three I want, using some keybinding
4. hit return for the default action (open the files)

PS - I'm new to embark, so recognize I may be missing some nuance.

[oantolin]

To be clear: we are only talking about applying the same single-argument action to each one of several candidates, right? We aren't talking about a new kind of actions that receives multiple candidates at once?

I have considered a feature to mark candidates and apply the same action to each one, and am of two minds about it.

If the only way to mark candidates is one at a time, like, you move to a candidate and press a key to mark it, then move to another, etc., then it's probably not worth it, since it hardly saves any keystrokes: you could just activate embark-collect-direct-action-minor-mode-map, which binds the actions directly without needing to call embark-act first, and go down the list of candidates running the actions.

If I added more ways to mark candidates, say, mark all, marking all that match a regexp, toggle marked/unmarked, etc. I'd be reimplementing politza's great tablist package. So I'd be inclined to instead make a small embark-tablist package, that depends on both embark and tablist, and provides an embark-tablist-act-on-marked command.

By the way, even without the embark-tablist package existing yet, I think it's already worth using tablist with embark collect buffers.

[oantolin]

Note that for example Ivy doesn't (or rather, didn't back when I used it) have a way to mark a bunch of items first and act on them later. Instead, it just has a way to set an action that will take a single keystroke to execute, and then you march down the list and run it on the items you want.

[minad]

You mentioned this tablist package multiple times already. How is it useful for embark snapshots? Do you enable some tablist-mode by default in your collect buffers? I need a simple example to understand what you use it for right now, since this embark-act-on-marked command does not yet exist :)

But it seems that such an embark-act-on-marked would satisfy the use case by @bdarcus perfectly.

[oantolin]

Without the embark-act-on-marked commands, it's mostly useful to focus Embark collect buffers to a subset of lines. Of course we now also have consult-focus-lines. But even with consult-focus-lines, the tablist package might still offer some advantage: it has commands to mark by regexp, to mark a single line, to mark all, to unmark all, and to toggle marked/unmarked (just like dired). You can easily remove the lines that are marked and restore them later.

[oantolin]

One very minor advantage of tablist over something like consult-focus-lines is that with tablist you can easily search just the candidates or just the annotations. (I don't consider this an important advantage.)

Another potential use of tablist, is that you can define your own predicates and then use them to mark lines. By default there are predicates to (1) check if a column matches a regexp or (2) is literally equal to some value. But you could add a predicate to check modification times for when the candidates are files, etc. A bunch of these predicates could be added to the hypothetical embark-tablist package.

[oantolin]

I think personally I don't need tablist with collect (thought I do love using tablist with pdf-tools annotations). I usually manage to narrow to exactly the candidates I want before I even run embark-collect-snapshot. And once I have a collect buffer I hardly every focus on subset of lines, I'm more likely to just use isearch (or the avy-embark-collect functions) to move to a specific candidate.

[minad]

Sounds goods. Thank you for the explanation. I think such an embark-tablist package would be a great addition, but I would still consider it as an advanced feature which is probably rarely needed.

[bdarcus]

To be clear: we are only talking about applying the same single-argument action to each one of several candidates, right? We aren't talking about a new kind of actions that receives multiple candidates at once?

That was my thought.

I have considered a feature to mark candidates and apply the same action to each one, and am of two minds about it.

If the only way to mark candidates is one at a time, like, you move to a candidate and press a key to mark it, then move to another, etc., then it's probably not worth it, since it hardly saves any keystrokes: you could just activate embark-collect-direct-action-minor-mode-map, which binds the actions directly without needing to call embark-act first, and go down the list of candidates running the actions.

Ah, that's one of those "nuances" I had missed. Agreed.

If I added more ways to mark candidates, say, mark all, marking all that match a regexp, toggle marked/unmarked, etc. I'd be reimplementing politza's great tablist package. So I'd be inclined to instead make a small embark-tablist package, that depends on both embark and tablist, and provides an embark-tablist-act-on-marked command.

By the way, even without the embark-tablist package existing yet, I think it's already worth using tablist with embark collect buffers.

I'll take a look; thanks. Perhaps you can include an example config with this on the wiki at some point?

[oantolin]

One small problem with trying to use tablist for this is that it would only work in list view. That's my fault: to be honest, tabulated-list-mode is really meant to used in a row-oriented fashion, and embark collect grid view is an abuse; a row in embark's grid view is meaningless, whereas in tabulated-list-mode or tablist, some things sort of assume that each row is a meaninful entity. In particular, in tablist you don't mark cells, you mark entire rows.

[oantolin]

@bdarcus

Ah, that's one of those "nuances" I had missed. Agreed.

So for now, let's just run actions individually, possibly using embark-collect-direct-action-mode to save a keystroke for embark-act. But we can keep thinking whether some sort of marking and batch execution makes sense. I think that actually embark-collect-direct-action-mode is a little more flexible than "mark & act", because you can use single keypresses to run different actions as you go along. It's probably good enough for the "run single action on each of several candidates" problem.

But it's still worth thinking about "mark & act", specially if there turns out to interest in "multi-argument actions": a single action that receives a list of candidates. I think Helm does have those.

I'll take a look; thanks. Perhaps you can include an example config with this on the wiki at some point?

Just install tablist, run M-x tablist-mode in an embark collect buffer, if you want to play around with it. If you like it and want it automatically on, add tablist-mode to embark-collect-mode-hook.

[minad]

I think mark and act is also useful if you want to mentally separate the steps. Like mark all, check again and delete.

[oantolin]

I think mark and act is also useful if you want to mentally separate the steps. Like mark all, check again and delete.

True.

[bdarcus]

possibly using embark-collect-direct-action-mode

Am I missing something, or is this not documented ATM?

I guess if using this option, one saves a keystroke, but gives up a which-key menu?

[bdarcus]

I was digging a bit into how helm-bibtex deals with this, here's a description:

https://github.com/tmalsburg/helm-bibtex#apply-actions-to-multiple-entries

... and a screenshot (light green rows are marked, darker green is the selected item):

BTW, do either of you know whether selectrum allows highlighting the matched text like this?