Add user-configurable distribution path prefixes (implements #822) by JonasPfi · Pull Request #1961 · htop-dev/htop

JonasPfi · 2026-04-16T17:59:45Z

Fixes #822, depends on #637

Problem

The 'Shadow distribution path prefixes' feature (#637) uses a hardcoded list of paths (/usr/bin/, /bin/, /nix/store/, /run/current-system/, etc.) that cannot be changed by the user. This makes the feature unusable for non-standard setups such as Flatpak (/var/lib/flatpak/), custom install prefixes, or other distributions with different filesystem layouts.

Solution

This PR implements two things as requested in #822:

1. A new StringItem settings control

Extends the existing settings UI infrastructure (OptionItem) with a new text input type backed by the existing LineEditor. This gives users a readline-like editing experience with support for:

Cursor movement (←/→, Ctrl+A, Ctrl+E)
Backspace / Delete

The StringItem follows the same patterns as the existing CheckItem and NumberItem controls.

2. User-configurable path prefix list

Replaces the hardcoded CHECK_AND_MARK_DIST_PATH_PREFIXES switch macro in Process.c with a matchesDistPrefix() function that checks against a user-supplied colon-separated list of paths. When the list is empty, the original built-in defaults are used as fallback.

Changes

OptionItem.h/.c — new StringItem type with LineEditor integration
Settings.h — new char* distPathPrefixes field
Settings.c — read/write dist_path_prefixes from/to htoprc
DisplayOptionsPanel.c — new text input field below the existing checkbox
Process.c — replace hardcoded switch macro with matchesDistPrefix()

Testing

Custom paths are highlighted correctly after input
Settings persist across restarts
Empty input correctly falls back to built-in defaults
valgrind --leak-check=full reports 0 definitely lost bytes
Escape correctly cancels editing and restores previous value
Tested on WSL2 (Ubuntu) with Linux build

fasterit · 2026-04-16T18:14:59Z

Undeclared use of AI, please read and understand the AI policy. Review your code and only then submit PRs.

JonasPfi · 2026-04-16T18:24:21Z

I added what I used to the commit. Since its my first contribution I used Claude mostly to get used to the repo and also for some logic.

fasterit · 2026-04-16T18:26:46Z

Did you see the "review your code" part?

JonasPfi · 2026-04-16T19:25:15Z

I've reviewed all changes. I removed a comment I missed earlier but did not find anything else.

Explorer09 · 2026-04-17T04:30:55Z

My question is: Why do we need this? Even though I believe there are demands for a custom list of path prefixes, I don't think the need for a UI for it is guaranteed.
Also, the format for storing those and loading those in the config can be discussed further. (I personally prefer storing the list as a separate file, e.g. ~/.config/htop/pathprefixes.txt, not in htoprc)

Explorer09 · 2026-04-17T04:38:18Z

+typedef struct StringItem_ {
+   OptionItem super;
+   char**  ref;
+   bool    editing;
+   bool    valid;
+   LineEditor editor;
+   bool    (*validate)(const char* text);
+} StringItem;


I'm skeptical of this item. It looks like a duplicate functionality when we have "Screens" whose names are editable.

Could you clarify. Do you mean that StringItem is unnecessary as a new abstraction, and we should instead embed LineEditor directly in DisplayOptionsPanel like ScreensPanel does?

No. I mean there's a significant overlap between the two string editing functionality. It's better to consolidate the two functionality into one code. How to do that is left for you to figure out.

Uhh. Forgot to mention this: LINEEDITOR_MAX is currently 128 (bytes). This is like not enough for editing a list of strings.

Agreed. I'll hold off on refactoring until there's consensus on whether the feature is wanted.

Explorer09 · 2026-04-17T04:39:41Z

 bool NumberItem_addChar(NumberItem* this, char c);
 void NumberItem_deleteChar(NumberItem* this);

+StringItem* StringItem_newByRef(const char* text, char** ref, bool (*validate)(const char* text));


Split the bool (*validate)(const char* text) function definition to its own typedef, please?

Explorer09 · 2026-04-17T04:56:08Z

+   bool    editing;
+   bool    valid;
+   LineEditor editor;
+   bool    (*validate)(const char* text);


Ditto. (Split the bool (*validate)(const char* text) function definition to its own typedef.)

fasterit · 2026-04-17T05:29:32Z

My question is: Why do we need this? Even though I believe there are demands for a custom list of path prefixes, I don't think the need for a UI for it is guaranteed.

We do not encourage editing htoprc by hand.

Also, the format for storing those and loading those in the config can be discussed further. (I personally prefer storing the list as a separate file, e.g. ~/.config/htop/pathprefixes.txt, not in htoprc)

Inside htoprc is fine, we should not inflate the config files for such minor functionality.

fasterit · 2026-04-17T05:30:27Z

Thank you for your review @Explorer09, @JonasPfi you see you have lots to do.

fasterit · 2026-04-17T05:34:12Z

@BenBE, @natoscott, @cgzones:
Do we want this path list to be editable, or do we want to have one canonical list (and add whatever flatpak needs there)?

Explorer09 · 2026-04-17T07:35:48Z

My question is: Why do we need this? Even though I believe there are demands for a custom list of path prefixes, I don't think the need for a UI for it is guaranteed.

We do not encourage editing htoprc by hand.

Also, the format for storing those and loading those in the config can be discussed further. (I personally prefer storing the list as a separate file, e.g. ~/.config/htop/pathprefixes.txt, not in htoprc)

Inside htoprc is fine, we should not inflate the config files for such minor functionality.

My concern is that, if someone needs to ever edit this list, they would likely comment what each path does. The UX requirement for that would be insufficient to fulfill with just a line editor.

Look at how long a PATH variable it is in my system, for example:

fasterit · 2026-04-17T07:46:44Z

Yes, this might need more than the line editor and a full editor panel would probably not be worth it.
At least I would like to keep the scope creep a bit under control.
Let's see what the others say.

Explorer09 · 2026-04-17T07:51:41Z

Another advantage for using an external list file is that distributions can ship with a preconfigured list of paths, freeing the user for needing to configure the list themselves.

If distributions want to ship with a preconfigured list, this list will likely reside in /etc/htop, separate from the per-user configurations.

fasterit · 2026-04-17T07:56:57Z

That would still be in a distro-default /etc/htoprc, we don't read /etc/htop/.

JonasPfi · 2026-04-17T08:20:49Z

My question is: Why do we need this? Even though I believe there are demands for a custom list of path prefixes, I don't think the need for a UI for it is guaranteed.

We do not encourage editing htoprc by hand.

Also, the format for storing those and loading those in the config can be discussed further. (I personally prefer storing the list as a separate file, e.g. ~/.config/htop/pathprefixes.txt, not in htoprc)

Inside htoprc is fine, we should not inflate the config files for such minor functionality.

My concern is that, if someone needs to ever edit this list, they would likely comment what each path does. The UX requirement for that would be insufficient to fulfill with just a line editor.

Look at how long a PATH variable it is in my system, for example:

I do agree with this. Currently you won't be able to recreate the default paths with the custom ones, and I think it looks off from a UX perspective to have such a long string in the display options.

Explorer09 · 2026-04-17T08:24:06Z

That would still be in a distro-default /etc/htoprc, we don't read /etc/htop/.

Um... Putting a settings file inside /etc without a subdirectory is a bad idea... Just FYI.

(If we ever need a system-wide htoprc, it would be /etc/htop/htoprc)

fasterit · 2026-04-17T08:43:36Z

Use the source, Luke. It is what we do. And have been doing for decades.
Ofc, these days people use subdirs in /etc but that was not always the case.

Explorer09 · 2026-04-17T10:04:55Z

   }

   NumberItem* numItem = (OptionItem_kind(selected) == OPTION_ITEM_NUMBER) ? (NumberItem*)selected : NULL;
+   StringItem* strItem = (OptionItem_kind(selected) == OPTION_ITEM_STRING) ? (StringItem*)selected : NULL;


RTTI (run-time type information). This is a smell of bad object/class modeling. Unfortunately I don't have any idea to fix it for now.

Explorer09 · 2026-04-17T10:19:30Z

+         return len;
+      token = *end ? end + 1 : end;
+   }
+   return 0;


There's still a performance concern with this new function. The old code had a switch-case that could make the lookup slightly faster, but now we're forced to perform a linear search...

I wish a slightly faster data structure such as a trie.

In this specific case implementing a trie might be overkill given the small number of prefixes. A full implementation would add significant complexity for what I'd expect to be a minimal performance gain.

I dont know. If it's me I'd implement it. Otherwise I don't like to trade a performance loss for a feature that few people use.

Assisted-by: Claude (Anthropic)

Explorer09 · 2026-04-17T10:28:15Z

+   } else {
+      const char* val = (this->ref && *this->ref) ? *this->ref : NULL;
+      if (val) {
+         RichString_appendAscii(out, valAttr, val);


Don't use RichString_appendAscii for strings read from external sources. Use RichString_appendWide instead.

Assisted-by: Claude (Anthropic)

Explorer09 · 2026-04-17T10:30:12Z

+   const StringItem* this = (const StringItem*)cast;
+   int labelAttr = CRT_colors[CHECK_TEXT];
+   int boxAttr   = CRT_colors[CHECK_BOX];
+   int valAttr   = this->valid ? CRT_colors[CHECK_MARK] : CRT_colors[FAILED_READ];


What does the validate function inside a StringItem do? And what would happen (or should happen) if the validation fails?

Currently its a placeholder. There was the idea of validating if the input path is a valid path in #822 but I did not implement any validation.

And what should be done if the "validation" fails?

The input should be displayed in red as visual feedback.

The "red" visual feedback would be not good enough if you have a list of path prefixes to edit. Also, I saw no code the "discard" directories that don't exist or are exact duplicates of previously specified paths.

Explorer09 · 2026-04-17T10:32:13Z

+StringItem* StringItem_newByRef(const char* text, char** ref, bool (*validate)(const char* text)) {
+   StringItem* this = AllocThis(StringItem);
+   this->super.text = xStrdup(text);
+   this->ref = ref;


What does ref do here and how is this argument different from text?

text is the label displayed next to the input field ( "- Custom path prefixes"). ref is a pointer to the settings field being edited (&settings->distPathPrefixes), so changes are written directly to the settings struct.

Explorer09 · 2026-04-17T10:47:29Z

      this->editBuffer[this->editLen] = '\0';
   }
 }
+StringItem* StringItem_newByRef(const char* text, char** ref, bool (*validate)(const char* text)) {


typedef bool (*ValidateStringFn)(const char* str, size_t len, void* context);

Will consolidate into a typedef. Will use your suggested signature with len and context if the feature moves forward.

JonasPfi mentioned this pull request Apr 16, 2026

Implement text input control for settings #822

Open

JonasPfi force-pushed the main branch from 838a14c to 6659219 Compare April 16, 2026 18:22

JonasPfi force-pushed the main branch from 6659219 to ffa2703 Compare April 16, 2026 18:32