Shorten path for CWD column when displaying

[BenBE]

As the CWD column is usually shorter than the paths it needs to display it would be nice to shorten the displayed path such that more relevant parts are kept visible.

Full:     /var/lib/postgresql/12/main
Current:  /var/lib/postgresql/12/ma
Proposed: /var/lib/postgre~/12/main

The general algorithm could be something linke this:

0. If string fits into target width, keep as is. Terminate this algorithm as soon as the resulting string fits.

1. Shorten from back of last, non-terminal path component until only one unshortened character remains (skip two-char components):

   /var/lib/postgres~/12/main
   /var/lib/postgre~/12/main
   /var/lib/postgr~/12/main
   /var/lib/postg~/12/main
   /var/lib/post~/12/main
   /var/lib/pos~/12/main
   /var/lib/po~/12/main
   /var/lib/p~/12/main
   

2. Repeat process with all path components before this.

   /var/lib64/p~/12/main
   /var/lib~/p~/12/main
   /var/li~/p~/12/main
   /var/l~/p~/12/main
   /v~/l~/p~/12/main
   

3. combine multiple (shortened) path components

   /v~/l~/p~~/main
   /v~/l~~/main
   /v~~/main
   

4. Shorten the last label from the middle, prioritizing to keep the front (keeping at least first+last char)

   /v~~/m~n
   

If the length that can be gained from shortening the last label exceeds what can be gained from step 3 than step 4 is prioritized.

The overall concept can likely also be reused for the CGROUP column (cf. #217).

[ncqgm]

Food for thought: Oftentimes, the path is looked at in order to then cd to it elsewhere. On Linux, cd'ing is often facilitated by tab-completion. Tab-completion has a higher chance of succeeding the more starting characters have been typed in. Hence it is useful to know them.

The proposal would be to start shortening "lefter" components earlier, say, when only 3 characters are left in a component. Once that has gone down to "root-level component=3 chars left" then start shortening components from the right again.

But, perhaps, this is a misguided adjustment ?

[BenBE]

The intention behind this proposal is based on the observation, that most often you know most of the path components pretty well and don't need to have them written in full. knowing a path is /u~/i~/nc~ already tells the full story (/usr/include/ncursesw, or the non-widechar version). Given some context (which you have with htop) you even can often discern most other cases like /v~/l~/p~/12/main as a process apart from postgresd is unlikely to have this as the cwd.

So why not prioritize from the left? Because on unixoid systems the first few path components usually are the shortest ones, thus having little effect on freeing up space. The less components you need to touch, the more of the unaltered path remains.

The examples above are the extreme cases of each shortening step. In htop the ´CWD´ column is 25 characters wide. Thus you'd end up with something like the first example with merely one directory shortened by 3 characters. Given that /var/lib and /var/lib64 are both common it's more important to distinguish those than whether it's postgresql or postgrey: You can easily figure out that distinction by the existing context.

[ncqgm]

The intention behind this proposal is based on the observation, that most often you know most of the path components pretty well and don't need to have them written in full. knowing a path is /u~/i~/nc~ already tells the full story (/usr/include/ncursesw, or the non-widechar version). Given some context (which you have with htop) you even can often discern most other cases like /v~/l~/p~/12/main as a process apart from postgresd is unlikely to have this as the cwd.

OK, true enough. The human layer inbetween "/u~/i~/nc~" and tab completion makes up for the fact that tab completion doesn't know whether I want /usr/include/ or /usr/ident/ (contrieved example). But I do know and I will easily type "/uTAB/idTAB" because when htop shows /u~/i~ it refers to /usr/ident/ in a given context.

Now, I wonder whether there's a case to be made when it might make sense to keep the last character of a (long) component, exactly because of the distinction between, say 32 and 64, or postgresql/postfix/postgrey ?

Just thinking, Karsten

GPG 40BE 5B0E C98E 1713 AFA6 5BC0 3BEA AC80 7D4F C89B

[arijun]

It might be worth looking at the implementation by powerlevel10k (a zsh theme), it's quite good IMO: current-directory-that-just-works

It:

• Indicates truncated regions with a de-emphasized color instead of an additional character (important when space is limited!)
• Only truncates as long as it can do so unambiguously
• Never truncates "important" directories, e.g. git repo, or the last segment. Also emphasizes these.

The truncated path will also autocomplete if you have that theme installed, but I don't know how common/hard to implement that autocompletion is.

fish shell will do something similar, without the emphasis/de-emphasis.