zdharma-continuum/fast-syntax-highlighting

[bug]: Man command highlighting as error

SystematicError opened this issue · 6 comments

Describe the bug

The argument passed to man is always highlighted as red, indicating something is wrong when the command is perfectly valid

Steps to reproduce

Install and source the plugin

Expected behavior

The argument passed should be colored red only if the man page does not exist

Screenshots and recordings

image

Operating System & Version

linux-gnu | pc | x86_64 | x86_64 | x86_64 unknown

Zsh version

zsh 5.8.1 (x86_64-pc-linux-gnu)

Terminal emulator

xterm-kitty

If using WSL on Windows, which version of WSL

No response

Additional context

No response

From what I tested, this only happens in Arch-based distributions.

WORSE I type man and it delays for about 30 seconds!
macOS arch64

From what I tested, this only happens in Arch-based distributions.

Sorry for the late reply, I indeed am on an arch based distro

Similar to/duplicate of #27.

I think I have finally found the reason why this bug occurs (at least in Arch Linux). This plugin seems to be using the whatis command to highlight the man argument. If this bug occurs on your system, whatis probably does not work properly either. You can check this by typing the command whatis ls for example.

The thing is that whatis depends in a index of all the available man pages in the system and Arch Linux does not generate it if you don't tell it to do so.

How to fix it?

If you are using man-db (most likely):

Arch Linux has a service called man-db.service as well as a timer called man-db.timer, which runs man-db.service daily.
This service is responsible for generating the index of the man pages, so the bug should be fixed executing the following command:

sudo systemctl enable man-db.timer

You must run sudo mandb if you want to create an index instantly.

If you are using mandoc:

I don't know if there is a similar service as in man-db, but you can do sudo makewhatis /usr/share/man to generate the index.

I hope you find it helpful!

@warbacon I came to a similar conclusion,see #27 for details and another possible workaround.