Publish extensions on ELPA

[minad]

Let this settle first a bit. The extensions are still new. The packages can be installed by hand via package-install-file for now and are in any case more interesting for experienced folks, who want to tweak Vertico more heavily.

Naming discussion:

• vertico-ext
• vertico-extras
• vertico-extensions

Alternatively make the extensions part of the Vertico package. But I intend to keep the package itself small and focused. The extensions are there, since there does not exist the one solution which fits everyone, e.g., in particular users may like to adjust the display code (vertico-buffer, vertico-reverse, vertico-flat).

cc @manuel-uberti, see also discussion in minad/uchronia@f677368

[manuel-uberti]

Let me keep the focus here instead of over at the uchronia repository.

First of all, I agree with you: let's keep Vertico as small as possible. It'll be impossible to please everyone with a single package and on the long run you risk adding hacks over hacks to make everyone happy. Not feasible, IMHO.

As for the package name, I like vertico-extensions because it sounds clearer when I think of the scope of the package.

[minad]

One technical issue with the extensions is that some of them are mutually exclusive, for example the display extensions (flat, buffer, reverse). You can install them of course at the same time, but you can only activate one of them at once. The extensions require more thought from the side of the user, while Vertico is easy to use.

Another option to consider - do not package up the extensions at all, but this is probably too inconvenient. A vertico-extensions package is a compromise.

[manuel-uberti]

One technical issue with the extensions is that some of them are mutually exclusive, for example the display extensions (flat, buffer, reverse). You can install them of course at the same time, but you can only activate one of them at once. The extensions require more thought from the side of the user, while Vertico is easy to use.

True, but the documentation can highlight this mutual exclusion and make the user decide what suits their needs. I mean, Vertico is already working fine out of the box, so you can expect the user to read the documentation before running wild on all the extensions at the same time.

[minad]

Sure, what I mean is that it is justified to have these as extensions then, packaged up separately or not at all, since they have a slightly different level of "robustness", "ease of use" etc. The main Vertico is a starting point and then users can go from there. I mean this is one of the main ideas of the whole Consult/Embark/Orderless/Vertico ecosystem, that you can adopt these things step by step.

[iyefrat]

True, but the documentation can highlight this mutual exclusion and make the user decide what suits their needs.

You can also add checks that sent a warning/error to *Messages* on load if you load two incompatible extensions at the same time (and a way to turn that off)

[minad]

You can also add checks that sent a warning/error to Messages on load if you load two incompatible extensions at the same time (and a way to turn that off)

Yes, of course I could. But probably I won't do this. This is the responsibility of the user. I can document it though that some extensions are incompatible with each other, if that isn't kind of obvious. But even if you turn on multiple incompatible extensions there won't be errors, you just don't see the desired effect if you enable for example vertico-flat and vertico-buffer at the same time. On the other hand, where it is easily possible to make extensions compatible, I do that. For example vertico-flat is compatible with vertico-quick/vertico-indexed.

[daviwil]

Is it possible that you could make separate package recipes for each of them that target the individual extension files? It seems like that's possible on MELPA, not sure about ELPA.

[minad]

Of course I could package them up all separately (both on ELPA or MELPA). But this is an unnecessary maintenance burden I would like to avoid. Furthermore it is too limiting when extensions are removed, replaced etc, since you are committed to the packages. I would like to have the possibility for more experimentation.

[jaor]

Naming discussion:

vertex :)

[minad]

Haha @jaor, this is just too good. I have to grab this name ;)

EDIT: The problem is that the naming convention won't be clear. There must be a vertex.el file and then the other files will be called vertico-*.el, which is not consistent. I could also call them vertex-*.el, but I don't want to introduce different names, e.g., vertex-buffer-mode. So probably this won't work out.

[hmelman]

Not a vertico user (yet) but I think packaging these up together is fine. A single top-level readme with specifics about what each does and which don't work together is I think completely sufficient. Vertico-extensions is a fine name. Vertico-experimental is another option if you want to stress the aspect that the user is required to do a little more with these. To follow the dired example you could name it vertico-x.

[bdarcus]

I say keep the extensions here, as is, but add a README to that directory?

Maybe can reconsider later?

[tumashu]

+ ("vertico"
+  :url "https://github.com/minad/vertico"
+  :doc "README.org"
+  :ignored-files ("extensions" "*.svg")
+  :auto-sync t)

hello, I have found that extensions directory is ignored, so do you mean user should download and install el files by hand?

[manuel-uberti]

hello, I have found that extensions directory is ignored, so do you mean user should download and install el files by hand?

The fact that the extensions do not show up when installing Vertico from ELPA was the main reason I raised this question to @minad in the first place. :)

[jdtsmith]

Yes, agreed. The example in the vertigo config README further confuses this, because it suggests you can load an extension like vertigo-directory with use-package (actually I've always wanted to know how to do just that for some local package under development if you care to share!).

But obviously this doesn't work out of the box.

[stevenbagley]

Yes, that example is slightly confusing.

With use-package you can use :load-path to load from a local directory.

With use-package and straight, add this to your vertico form:

  :straight (vertico :includes vertico-directory
                     :files (:defaults "extensions/vertico-directory.el"))

[minad]

For now I moved the vertico-directory configuration example to the extensions section to reduce the confusion, see https://github.com/minad/vertico/#extensions.

[rememberYou]

IMO, vertico-directory-up should be part of the vertico package. Rare are the users who will prefer the following behavior:

• without vertico-directory-up:

Find-file: ~/.emacs.d
C-<backspace> 
Find-file: ~/.emacs.

• with vertico-directory-up:

Find-file: ~/.emacs.d
C-<backspace> 
Find-file: ~/

There are a large number of possible extensions for a completion system. Therefore if you would like to separate them from vertico, maybe we could follow the model of LSP mode where lsp-mode (here vertico) is the main package and other users who would like to implement an LSP server (here a vertico extension) have to follow a certain pattern?

[Crandel]

Please add extensions to at least Melpa. I don't want to use straight and this is not working for me either

(use-package vertico-directory
  :load-path "vertico/extensions/vertico-directory.el"
  :bind
  (:map vertico-map
        ([left] . vertico-directory-up)
        )
  )

Cannot open load file: No such file or directory, vertico-directory

[jdtsmith]

Try just :load-path "vertico/extensions/".

[Crandel]

@jdtsmith The same result
I clone this repo in the folder with my init.el

[Crandel]

Sorry I found the reason.

(setq user-emacs-directory (expand-file-name "~/.cache/emacs/"))

I moved repo to cache and everything works fine

[astoff]

I'm not using any of the extensions, and I wouldn't be bothered in the slightest to have those files sitting in my hard drive... What's the advantage of a separate package?

[maisiliym]

(when unusualCodeStructure
  (moreWorkFor [ nixUsers guixUsers ])
  (when codeIsTooGoodToBitrot
    (inevitableDuplicateWorkFor everyone)))

[minad]

The sentiment here seems to be that the extensions should be distributed together with the package. I am not opposed to that - as far as I can tell the extensions are mostly stable enough. Originally the extensions were thought as a staging area. In any case I don't want to move extensions functionality to the main library.