`PF_COLOR=0` strips too much

jwodder commented 1 month ago

When PF_COLOR is set to 0, pfetch currently strips colors like this:

https://github.com/Gobidev/pfetch-rs/blob/84243151fa3e1c3b64bf5bd86d7200f571a909fa/src/main.rs#L141-L147

However, this is wrong for the following reasons:

When splitting on \x1b[, the first element of the resulting iterator will be the portion of pfetch_str before the first color sequence, which is a nonempty string whenever PF_PAD1 is nonzero, which means that PF_PAD1 will be reduced on the first line.
The code tries to remove color sequences by skipping the first three characters after each \x1b[, but not all color sequences emitted by pfetch are this length. For example, the bold sequence before the logo & field name and the reset sequence after the field name are each two characters once \x1b[ is stripped. One consequence of this is that the first character of either PF_SEP (if set) or padding3 will be dropped when stripping colors.

For example, if I run pfetch 2.10.0 with the default settings on my machine, then (after independently stripping colors so as not to produce a mess on GitHub) the output is:

       .:'     jwodder@Johns-Laptop-4.local 
    _ :'_      os     macOS 14.5.0 Sonoma
 .'`_`-'_``.   host   MacBookPro16,2
:________.-'   kernel 23.5.0
:_______:      uptime 49d 23h 17m
 :_______`-;   pkgs   177
  `._.-._.'    memory 9340M / 16384M

If I then set PF_COLOR=0, the output becomes:

       .:'     jwodder@Johns-Laptop-4.local
    _ :'_      os    macOS 14.5.0 Sonoma
 .'`_`-'_``.   host  MacBookPro16,2
:________.-'   kernel23.5.0
:_______:      uptime49d 23h 18m
 :_______`-;   pkgs  177
  `._.-._.'    memory9395M / 16384M

Note that the padding between the field names and field values has been reduced by one, resulting in the "kernel" and "uptime" names running into their values.

If I run PF_PAD1=1 PF_COLOR=0 pfetch, the output is:

       .:'     jwodder@Johns-Laptop-4.local
     _ :'_      os    macOS 14.5.0 Sonoma
  .'`_`-'_``.   host  MacBookPro16,2
 :________.-'   kernel23.5.0
 :_______:      uptime49d 23h 11m
  :_______`-;   pkgs  177
   `._.-._.'    memory9441M / 16384M

Observe that now the "title" line is not indented but every line after it is.

In addition, if I run PF_SEP=: pfetch, the output is:

       .:'     jwodder@Johns-Laptop-4.local 
    _ :'_      os:     macOS 14.5.0 Sonoma
 .'`_`-'_``.   host:   MacBookPro16,2
:________.-'   kernel: 23.5.0
:_______:      uptime: 49d 23h 20m
 :_______`-;   pkgs:   177
  `._.-._.'    memory: 9387M / 16384M

but if I add PF_COLOR=0, the colons do not appear:

       .:'     jwodder@Johns-Laptop-4.local
    _ :'_      os     macOS 14.5.0 Sonoma
 .'`_`-'_``.   host   MacBookPro16,2
:________.-'   kernel 23.5.0
:_______:      uptime 49d 23h 21m
 :_______`-;   pkgs   177
  `._.-._.'    memory 9442M / 16384M

Gobidev commented 1 month ago

Thank you for this extensive bug report, adding and then removing colors is a very hacky solution anyways. I wanted to rewrite the main pfetch function at some point already, as it is very convoluted and poorly documented. This issue is a good reason to finally get to that.

Gobidev commented 1 month ago

It was not that big of a change to not add colors in the first place if PF_COLOR=0 is set, so I implemented this for now. I still plan to rewrite the pfetch() function for #61 though.

Gobidev / pfetch-rs

`PF_COLOR=0` strips too much #60