Selectrum: Better default binding for backward-kill-sexp in file completions

[clemera]

As the binding is very useful to act on file paths there should probably be an additional default binding which is less problematic than C-M-DEL and more convenient than ESC C-DEL (see #177). Maybe we could simply add a binding for C-DEL? For word deletion there would still be M-DEL. On the other hand users which usually default to C-DEL for word deletion might be confused to have that binding remapped.

In the discussion of #177 we also noted that configuring bindings only for file completions is currently cumbersome compared to being able to bind keys in minibuffer-local-filename-completion-map which might be worth to change along side with this. Currently one can adjust bindings tailored to file completion like this:

(add-hook 'minibuffer-setup-hook
          (defun my-selectrum-set-file-bindings ()
            (when (and selectrum-active-p
                       minibuffer-completing-file-name)
              (define-key (current-local-map)
                (kbd "<C-backspace>") 'backward-kill-sexp))))

[raxod502]

I think it would be okay to rebind C-DEL -- having used Emacs since 2016, I only just learned that this was bound to backward-kill-word -- as long as it's possible for a user to bind it back if they want.

By the way, it's also possible to define a conditional keybinding by means of an extended menu item with a :filter predicate. We don't want to force people to do that, though.

[lorniu]

Maybe we can add a per-command-hook, so we can increase the flexibility of user configuration. In the same time, the definition of keybinds can also be simplified.

For example, we can adding an extra :id or ivy-like :caller keyword argument to selectrum-read. Then, in selectrum--completing-read-file-name where call selectrum-read can change to (selectrum-read ... :id 'read-file-name). And when I or someone else, who want to customize the behavior of the completion file, whether keybinds or others, can directly customize a selectrum-read-file-name-hook-like. Even we can maintain a global hook alist for this or more.

I am a little dissatisfied with the display face and sorting rules of candidates in file completion, but I have no idea how to do it easily. With this I can directly add my own logic to this hook. This allows more flexibility.

Of course, the disadvantage is that some people may abuse this function.

Personal opinion.

[clemera]

This would be an attempt of porting the configuration system of ivy. Most things you talked about should be possible without inventing a new configuration scheme. The less users depend on selectrum-read the better IMO.

Emacs built in way to configure completions is via the completion table metadata. For example when passing a table to completing-read you can set another display-sort-function in the the metadata of your completion table (see (info "(elisp) Programmed Completion")) to adjust sorting.

For reading files it's a bit more tricky because you don't pass the completion table yourself. Internally completion-file-name-table is used as the table for getting the file names. Here is how you can advice it to get a different sorting (in the example I simply reverse the order):

(define-advice completion-file-name-table (:around (fun string pred action) adjust-sort)
  (if (eq action 'metadata)
      `(metadata
        (display-sort-function . reverse)
        ,@(cdr (funcall fun string pred action)))
    (funcall fun string pred action)))

This continues to work when you disable selectrum or switch to another completion engine which complies to the default interface. I understand that this is not convenient but the benefit is that it's portable user configuration that doesn't depend on selectrum.

[lorniu]

Ivy has advantages also disadvantages. I think that good places can be used for reference, but it may not necessarily be totally denied.

Of course, I agree with you.

In some ways, you are absolutely right.

Keeping it pure is an advantage.

Keeping it less popular is also an advantage.

[clemera]

Maybe we should rethink making #156 part of the public interface. We could use a similar approach that embark uses: There are hooks which run to determine the category. These can be configured by users. The category would then be mapped to a transformer function which can adjust the table. The approach wouldn't make user commands which use completing-read dependent on selectrum although the adjustments by the transformers would be gone without selectrum of course.

[lorniu]

the benefit is that it's portable user configuration that doesn't depend on selectrum

To be honest, your idea of ​​maintaining compatibility and portability is a bit idealistic, sometimes it backfires. Many times, the user wants to configure something, whether faces or keybinds, only because he is currently using selectrum, his configuration is based on the interface and functions provided by selectrum. If he exits selectrum mode, these configurations become meaningless. If you forcefully retain these configurations for the purpose of maintaining portability, it will become inexplicable.

Give a very simple example. In file name completion, the user may want to display a certain icon/description before or after each completion candidate according to the type of the file. This works well in selectrum. But if he switchs to ido/icomplete, etc., and these candidates still carry these icons or description text, it will seems chaotic and unnecessary, because the display style of ido/icomplete is not vertical like selectrum. And, the user hits the probability that he doesn't want to keep the previous face settings. The keybinds and other settings also have similar problems.

most things you talked about should be possible without inventing a new configuration scheme

Of course, this sentence itself is not wrong. But in fact, as long as you dare to use the advice system extensively, you can pass Write a huge amount of configuration to achieve exactly the same function as selectrum. But the question is, why is it so? Use a framework or extension isn't it to reduce these configurations? In particular, there are too many users of Emacs, with various purposes. I have seen many insist on using Emacs just because they like Org-Mode, some just want to use Emacs to write JS. They may be unfamiliar or interested in Elisp, not to mention advice system. For many such people, choose ivy or selectrum or other completion frameworks, maybe more lies in the out-of-the-box experience and the ability to refer to other people's configurations to quickly meet certain natural needs. There are too many users in this part, I don't think that such an excellent framework as selectrum should abandon them.

Finally, I feel that some configuration freedom should be left to users. You can expose some empty public interfaces, whether it is hook/transformer/filter or other. We do not encourage users to use these interfaces, but at least ensure that they can use these interfaces to simplify individual configuration.

[clemera]

Give a very simple example. In file name completion, the user may want to display a certain icon/description before or after each completion candidate according to the type of the file. This works well in selectrum. But if he switchs to ido/icomplete, etc., and these candidates still carry these icons or description text, it will seems chaotic and unnecessary, because the display style of ido/icomplete is not vertical like selectrum. And, the user hits the probability that he doesn't want to keep the previous face settings. The keybinds and other settings also have similar problems.

If you want to display icons/descriptions that is possible without breaking commands when users switch to icomplete/ivy or some other framework which implements the completion API. You would use Selectrums text properties on the candidates and the other completion engine wouldn't care about it. If you use the annotation-function metadata and the other framework is fully API compliant the feature even persists. I don't argue that configuration of Selectrum specific functionality should work everywhere my main point is that we shouldn't introduce more features which encourages users to use selectrum-read instead of completing-read and you proposed to add an :id argument to selectrum-read to configure behaviour based on that.

Finally, I feel that some configuration freedom should be left to users. You can expose some empty public interfaces, whether it is hook/transformer/filter or other. We do not encourage users to use these interfaces, but at least ensure that they can use these interfaces to simplify individual configuration.

As said above I'm not against such features in general as long as they work with completing-read.

[clemera]

Closing this, leaving it to users whether they want to override the C-DEL binding.