package-lint VS vertico

Exactly! This is also why I like Compat. I have to read through the Emacs NEWS anyway, then I can just as well add the functions directly to Compat. The small downside however is that Compat pretends that some function is available in your Emacs. If you write a package you must look twice where a function is coming from. This should not be a problem if you use package-lint, which you should! But see also https://github.com/purcell/package-lint/issues/227.

Thank you for reading that far. If you have feedback, questions or improvement proposals, please let me know. I hope that Compat is useful for you. If you miss some important functionality, feel free to open an issue on the issue tracker. Any help in adding missing functionality is welcome. In case you are interested in upstream development, you may want to help with scanning through years of the Emacs Git log for added functionality. A laborious process, but the Emacs library diffs from package-lint are useful. Unfortunately package-lint does not yet support Compat and warns if you use compatibility functions. Also package-lint does not yet track argument number changes. Help with those package-lint issues would be greatly appreciated.

I would suggest using the checkdoc command in each of your package buffers. It will point out stylistic errors. flymake-mode will help catch byte-compilation errors as well. You should also install https://github.com/purcell/package-lint and M-x package-lint-current-buffer to get these up to par for MELPA.

(Note that the current minimum requirement for Emacs is set to 27.2, I'm pretty sure this can be lowered but I'm waiting on this issue for confirmation. Until then, if you have an older version, you should probably be able to install with quelpa just fine).

Also consider using checkdoc and package-lint before you publish stuff, it is really annoying to get warning pop-up for docs wider than 80 chars. Those are so easy to catch up. Generally, it is good to follow Melpa guidelines even if you don't plan to publish your package in Melpa.

I strongly suggest you to use package-lint when writing packages. It will point out all version mismatches, and some other things.

It would be great if you add your snippet to the Vertico wiki. Such tweaks can be quite instructive for others who want to achieve the same or similar effects for other completion commands.

If you want completion to be sorted by your "most recent" I suggest you have a look at completion libraries. One example is vertico; when you enable savehist mode, the variable magit-revision-history, containing the branches you visited is persisted between sessions and vertico use that offer completions by most-recently-used, by default.

I think vertico is best alternative recently, really fast on Linux, macOS and Windows.

(use-package modus-themes :vc (:url "https://gitlab.com/protesilaos/modus-themes" :branch "main")) (use-package vertico :vc (:url "https://github.com/minad/vertico" :rev :newest :lisp-dir "extensions/"))

An example relevant to your list would be some changes many people are taking with their completion framework - using package that leverage core emacs functionality rather than replacing it with a complete package that 'overrides' it. Consult, vertico, orderless and associate packages come to mind here. If you do a bit of a search you'll find plenty of info. Here is a video from Prot on the subject, but there are many others as well. I think Prot actually went on to write his own completion system to overlay native emacs functionality as well.

Next you "only" have to remember (elisp) function names. "Completion UIs" like ivy/counsel, icomplete, helm or vertico/consult, give you a nice auto completion list on M-x (choose the one of them, you like the most). Some of those Completion UIs will display existing keybindings and a short documentation for commands, near the auto complete candidates. So you will start to remember more keybindings without "learning sessions", just because invoking functions via keybindings is much faster (more convenient).

Wow, interesting that my response is getting down voted. It seems not enough that I give away my work for free. Nevertheless I appreciate support from the community, as other Emacs package developers. The support is actually helpful. To clarify, publishing my configuration would translate into quite a bit of work, requiring separation of private and public bits.

I thought that lsp and rtags were different tools to do different things. Regarding lsp, I configured lsp-mode in my init file indeed! Currently I'm using Vertico (plus recommended sub-packages at github repository) and lsp-mode.

Hey! There has already been a horizontico.el. ;)

FYI, selectrum is getting deprecated in favor of vertico. https://github.com/minad/vertico/issues/237