Severity: wishlist Hi, I would like to discuss whether it would be useful to ship an example configuration file for helix. I am currently facing some configuration issues while recommending this to others. I think providing a default config file called example would help resolve these problems. First, the theme doesn’t appear after default installation. In many terminals, the `COLORTERM=truecolor` variable has no default setting, so the theme always appears gray. Second, the default purple theme is difficult to read for me (and the posts I see on Reddit). I prefer the catppuccin-macchiato theme. There are also some other personal settings that I won’t go into detail about here. So I propose creating a default configuration—it could be simple, or it could list all available options (which seems to increase my maintenance workload 😆). Here’s the config I’m using right now: ```toml [editor] theme = "catppuccin_macchiato" [editor] line-number = "relative" true-color = true default-yank-register = "+" [editor.cursor-shape] normal = "block" insert = "bar" select = "bar" [editor.lsp] display-inlay-hints = true ```
Quoting Junyong Liang (2026-08-06 19:26:57) An example config is a low-hanging fruit: That is just a file that we ship below /usr/share/doc/hx/examples/ that we imagine has some general use - can be inspirational use, so perfectly fine to share strongly biased or weird configuration examples there. A default config is something else - that should be generally useful not only inspirationally but functionally - so things like "let's hardcode use of 24-bit color disregarding what the terminal says" are unacceptable there, and even "let's use theme foo" is questionable. What would be the proper, elegant approach would be to use debconf: https://wiki.debian.org/debconf This also ties into an old idea of mine to introduce a generic package in Debian for user-facing cross-package choices like "should dark or light be preferred?" and "base tinting color" and "console font?" and "console color depth (and should it be forced)?". Because such debconf questions are relevant not only for helix but for a large range of packages, potentially, if the maintainers ever engage in setting up the needed packaging infrastructure to handle debconf for their default config setup. Helix could be a frontier here: We could do the hard work of setting up proper separation of general questions and application-specific translation of those answered questions into auto-generation at package install time of maintainable default settings. What do you think? The easy part is to compose 1 or 19 example configs and ship those with the hx package... - Jonas
[Replying via the bugreport] Quoting Junyong Liang (2026-08-24 15:26:39) Please elaborate what you mean by debconf not being a good solution. I don't understand your pointing to oh-my-zsh as an example (I have never heard of it before, and I use bash, not zsh), and since it seems to not be an official Debian package, I highly doubt that it is using debconf (or if it does, that it has done so in an optimal way). To experience what debconf can be, try run one of these commands: sudo dpkg-reconfigure fontconfig-config sudo dpkg-reconfigure keyboard-configuration sudo dpkg-reconfigure tzdata If you want to do something quickly, then propose some sample configuration files that the user then can manually look at and copy into place on their own. If you want to help provide a smooth user customization experience that is also strongly maintainable, then debconf is great. But it is a bit complex to understand at first. Please do tell me what level of enthusiasm you have for diving into this, because I don't have debconf prepared on a silverplate for you, but I am willing to spend the time needed to get you accustomed to it if you have the interest in tackling it. - Jonas
Hi Jonas, My point is, debconf configuration handling is very convenient, but it isn’t intuitive for users. I ran the command you provided; take the `sudo dpkg-reconfigure tzdata` command as an example. I can select some configurations during this process, but (assuming I’m a novice) I don’t understand the meaning of these options, and I have no way of knowing the differences between them. Regarding ohmyzsh—I got it wrong. What I meant is powerlevel10k, a script that beautifies zsh, allowing users to set the shell prompt style. Users can preview the results after changes in real time. https://www.youtube.com/watch?v=YfaZ2vfauDQ is a preview video starting at 7 minutes. You can see how users complete the configuration using the preview option. For example, we could ask the user if they can see the current color bar to determine whether truecolor is required. Then we could provide several color options for them to select the theme. I have a couple of questions: First, can debconf implement the above process? Second, when should this configuration process occur? When using apt, there isn’t often much configuration to ask me about. I’m also not in a rush to provide example configurations. As I initially hoped, I want users to be able to display theme colors after installation, as long as their terminal supports it. As for other configurations, since the default installation opens a blank configuration via the `:config-open` command, I attribute my initial confusion to this issue. Best regards, Junyong Liang
Quoting Junyong Liang (2026-08-24 17:03:12) If you are a novice and don't know what a timezone is, then you hit ENTER and hopefully get something sensible (possibly because your system is network-connected and a timezone was signalled via DHCP or some other locale-bound hinting). If you are less of a novice but cannot be bothered with making choices then you can also just hit ENTER and hope for the best, or you can run `sudo dpkg-reconfigure --priority=low tzdata` to tell ahead of time that you don't want to be bothered. As package maintainers we have the opportunity to provide descriptions for each configuration choice, exactly to aid in our users not feeling lost, and when we do we trigger a network of translators that help get our guiding messages across to non-english speakers. debconf is a protocol to separate configuration choices from messages explaining them from routines selecting them from interfaces presenting them. We can add a plugin that calls your mom or ChatGPT to make choices on your behalf, or randomly pick a choice with a priority on prime numbers keywords with more vowels and blueish colors over their counterparts. And users not wanting to depend on their mom or a roulette to setup their systems can bypass our "wonderful" UI and use different interfaces - notably that's what blind Debian-users do: as I understand it, they appreciate debconf-enabled packages and work slower when forced to use "beautified" user interfaces not taking their needs into account. Helix installation experience should ideally be equally optimized for color sighted folks *and* blind folks *and* one-armed astronauts on space-walk. Are you saying that you are open to solving this the solid way, rather than the quick'n'dirty one? - Jonas
Hi Jonas, Although I don’t fully understand your example about mother and ChatGPT, I can see what you mean. For some users, they may not prefer a preview-style interface. From this perspective, I think debconf seems to be our only option. Since I have no experience with accessible software, I can’t say that I can provide a more reasonable configuration process. As for the issue of default options you mentioned, I don’t think it can solve my original problem either. If we keep the default settings in debconf as they are now, there will still be no theme colors after installation. If we enable theme colors in the default settings of debconf, it will cause some additional problems. Moreover, ChatGPT told me that we can use installation scripts to detect the user environment, but I don’t think this is a good idea. Best regards, Junyong Liang
Quoting Junyong Liang (2026-08-25 05:52:40) Let's take the issue of color support as an example. If I understand you correctly, part of the issue is that maybe the monitor can display thousands of colors and the terminal emulator can too but it has not been configured to announce towards CLI tools that it can. So you would like to flip a switch in the setup of hx to say "let's ignore what the terminal emulator is saying and just do colors". I think that is not sensible. What about the systems that genuinely cannot support thousands of colors - they will experience broken rendering when color hinting is thrown at them. The proper approach is for CLI tools to respect signals about the environment provided by its host - typically a terminal emulator. Which means that in order for the installation of hx to be a nice user experience, the installation of the underlying terminal emulator needs to include user-friendly configuration of "should this terminal emulator accept CLI tools signalling color hints or not?". Debian is a system, not tools in isolation. Debconf is the protocol invented to process package installation variability choices - i.e. high-level configuration (not every nitty gritty detail within each package, but the things that sometimes matter to bother asking at install time). - Jonas
Hi Jonas, I agree with you. In fact, HX's default configuration works the same way—it determines this based on environment variables. After looking into it, I found that most terminal emulators inject this environment variable themselves. I haven't been able to reproduce the issue I encountered earlier, so let's put that aside for now. Let's look at what configuration options we can offer users. If the user simply presses Enter through all the prompts, we can keep the current behavior as the default. If we do provide additional options, how can we make them quick to configure while still staying within HX's existing configuration system? For example, could we provide fully predefined configuration presets?
Quoting Junyong Liang (2026-08-25 17:18:04) Yes, we should distinguish between default settings and variability. Upstream provide some internal defaults, and offer wide variability through a user-specific configuration file. What we can do at the package level is a) patch the internal defaults and b) provide a system-wide defaults that a system-admin can alter and c) install-time narrow variability of those system-wide defaults. The answer to that really depends on the flexibility of upstream config handling. To be honest, I am not sure if hx supports system-wide defaults currently. If not, then we need to fix that first, eiter by implementing it ourselves (and offer it Upstream) or by convincing upstream to implement it. The ideal would be to have the application obey XDG standards, in my opinion. When system-wide configuration is in place, then yes, we can ask at install time (and re-ask when running dpkg-reconfigure) e.g. "do you want pink background and german help screen and large font?" as one catch-all preset - but I don't think that is a sensible approach - what if I like pink and big but want french instead? It makes sense to come up with full compositions where all the setting play nice together - but then I expect us to try hard to decompose that into components, and think about how it makes sense to ask choices about those components in a way that supports however it is that they integrate well together. As an example, Debian installer first asks you about your primary language and then about choice of keyboard - there are thousands of possible keyboard layouts but you are first suggested 3-5 layouts tied to the language you chose earlier, and an "other" that gives you a larger list - but you are never offered to navigate all combinations, for that you will need to edit configuration files yourself after the general system setup has completed. I think that similarly we should try to both offer ways to offer reasonable variability but not more complex than is possible for us to guide the user through at install time without it bothering them. - Jonas
Hi Jonas, After looking into this over the past few days, I think the system-wide configuration approach may be larger than I initially expected. I checked the current upstream code and open pull requests, but could not find an existing implementation for loading system-wide configuration. I would prefer the Debian package to stay reasonably close to upstream, so I am reluctant to carry this as a Debian-specific feature patch. We could implement it and submit it upstream, of course. Even if upstream accepted it, though, we would still need to carry the patch in Debian until a new Helix release includes it. There has not been a release since 25.07.1. I have also spent some time considering which questions debconf should ask. So far I have not found a set that I am satisfied with. Theme, keybindings and similar settings seem to be personal preferences rather than suitable system-wide choices. True-color support can also vary between terminals used on the same system. Adding debconf without a clear system-wide choice would introduce quite a bit of packaging and configuration-file handling for little immediate benefit. For this bug, I would therefore prefer to start with the simpler approach: ship an example configuration under /usr/share/doc/hx/examples/, which users can inspect and copy into their own configuration directory. We can still pursue XDG system-wide configuration separately, preferably upstream, if we identify a concrete use case for it later. What do you think? Best regards, Junyong Liang