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