Quoting Blair Noctis (2025-03-18 11:35:21)

On 16/03/2025 19:10, M. Zhou wrote:

Do you think it is useful to define some flags for
dh_shell_completions, like --enable-by-default, --disable-by-default
to decide whether a completion file should be enabled by default.

I agree with Blair that shell-completions need no enablement mechanism. Changing subject accordingly for this subtread.

I'm raising this question because I find it somewhat confusing
because different shells do the completions and keybindings in very different ways. For instance, fzf: https://salsa.debian.org/go-team/packages/fzf/-/blob/master/debian/README.Debian

As you can see, key-binding scripts are similar to completion scripts. Maybe they can be dealt by the same dh module as well. Generally key-binding scripts should not be enabled by default due to potential conflicts.

At a glance yes.

But install keybindings where?
Shells have standard locations in which completions are immediately enabled. Keybindings obviously shouldn't be immediately enabled.
But are there such standard locations for "disabled" keybindings?
Your example didn't show existence of such.
If not, where should we install them to?
Maybe we can install them as docs or examples,
but then a debian/$package.{docs/examples} would do.

Regardless of whether keybindings get covered by dh-shell-completions
or end in an independent dh-keybndings package or whatever, I agree that
first some common pattern of how such assets might be organised in the filesystem needs to be established first - either from current praxis
(which keybindings already get installed today in existing packages?)
or from committee.

I am not even sure what "keybindings" cover, and doubt that any of the
700+ packages I am involved in provides any, so I will leave the details
to those actually involved in needing infrastructure for such assets.

One more general remark, though: Do *not* rely on assets located below /usr/share/doc - e.g. don't package some asset there and instruct users
to symlink that asset to somewhere "inside" the core system, because
the system must not rely on that path existing on a system at all
(I think it is covered in Debian Policy somewhere, just too lazy to look
right now). Instead, place assets e.g. below /usr/share/<PKG>/ - or if
you really must put it as part of the documentation then make sure to
only ever instruct to *copy* the asset elsewhere (which is most likely a
bad idea for maintenance of such system).

- Jonas

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/
* Sponsorship: https://ko-fi.com/drjones

[x] quote me freely [ ] ask before reusing [ ] keep private

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)