Add ignore functionality to Yazi based on gitignore and user overrides

[carlosedp]

This pull request introduces a new ignore filtering system to the file manager, adding support for .gitignore and custom ignore patterns. It enables users to control which files and directories are hidden from view, either by leveraging Git ignore rules or specifying their own patterns. The changes span configuration, core logic, and integration with the actor and file management systems.

Key changes include:

Ignore Filter System Implementation

• Added the IgnoreFilter struct and logic in yazi-fs to support filtering files and directories based on Git ignore rules and user-defined patterns. This includes methods to build filters from a directory or patterns and to check if files should be ignored.
• Updated the Files struct to store and apply an IgnoreFilter, ensuring ignored files are dynamically filtered out during file operations.
• Registered new dependencies in Cargo.toml for git2 and ignore crates to enable Git ignore and pattern matching functionality. The git2 library is used on apps like eza to provide a similar functionality.

Configuration and Integration

• Extended the manager configuration ([mgr]) to include gitignore_enable and ignore_override settings, allowing users to toggle Git ignore integration and specify custom ignore patterns.
• Implemented the Ignore actor in yazi-actor to manage ignore filter application based on configuration, and integrated it into the folder refresh and directory change workflows.

Sample configuration:

[mgr]
gitignore_enable = true
ignore_override = [
  # "*.log",              # Additional ignore pattern - hide all .log files
  # "tmp/",               # Hide tmp directory
  "!target/", # Negation - show target/ even if git ignores it
]

Command and Event Handling

• Updated the command/event system to recognize and handle the new ignore action, ensuring it is properly dispatched and executed in response to relevant events.
  Module Organization
• Registered the new ignore module in the appropriate places to ensure correct linkage and initialization across the codebase.

These changes collectively add robust and flexible ignore filtering, enhancing the file manager's ability to hide unwanted files and directories according to user preferences and project standards.

[carlosedp]

Docs for this PR have been added at yazi-rs/yazi-rs.github.io#294

[sxyazi]

Sorry! There are no plans to support gitignore because it conflicts with another planned, more general file hiding feature, #694, which is more easier to extend to the virtual file system. Ideally, I want to avoid having multiple implementations for similar features to reduce maintenance costs.

Next time, it would be very helpful to open a discussion first to see if it aligns with the project goals to avoid any risks of re-work 👍

yazi/CONTRIBUTING.md

Lines 142 to 144 in 46569a1

	If you have an idea, before raising a pull request, we encourage you to file an issue to propose it, ensuring that we are aligned and reducing the risk of re-work.
	We want you to succeed, and it can be discouraging to find that a lot of re-work is needed.

Thank you for the effort, @carlosedp!

[carlosedp]

I've submitted this because I saw most the proposals or previous discussions were almost 1 year old and didn't have updates since...
That's ok tho... it was a neat implementation and worked pretty well here.
Thanks for the amazing tool.

[sxyazi]

I've submitted this because I saw most the proposals or previous discussions were almost 1 year old and didn't have updates since...

Yeah there hasn't been much progress on it so far - no one has been able to work on it yet, unfortunately. If you're interested in it, feel free to open a new discussion!

[carlosedp]

What if I kept the gitignore flag and transform the overrides into the more granular way you mentioned in the issue:

[manager]
visibility_rules = [
    { dir = "~/", hide = "go|\.git" },
    { dir = "*/", hide = "\.git" }  # fallback
]

I feel this could work for both cases... one which people can hide all that's ignored and the other for people who want to define the hiding...

[carlosedp]

Because I feel what I implemented already does a similar thing but in a more generic way that you can override the hiding in a global manner.

[sxyazi]

What I have in mind is something like this:

# yazi.toml
[files]
excludes = [
  # SFTP
  { urn = "*.tmp", in = "sftp://**" },
  # Search results
  { urn = "/root/**/*.pyc", in = "search://**" },
  # Regular
  { urn = [".{git,DS_Store}", "__pycache__"], in = "/code/**" },
  # Fallback
  { urn = ".DS_Store", in = "*" }
]

• in is the directory URL where the rule applies that can match both the scheme and path of the URL.
• urn is the file path within that directory and can be either a string or an array of strings. For most directories, it's a single-level path; in the search view (flat view), it can be multi-level.

in which:

urn is one or more globs, they are compiled into regular expressions with globset (as Vec<Regex>). During matching, the Vec<Regex> is converted into a RegexSet to search for the first match, for better performance.

There are paired options prepend_excludes and append_excludes as most other rules, so users can prepend/append custom rules to the preset.

We can also provide a built-in command or a Lua API to allow loading other ignore rules from external sources so that users can subscribe to the cd event and set different rules for different directories at runtime, similar to the way folder-specific rules work.

LF (a file manager) has a good example with its hiddenfiles and on-cd hook to achieve this:

cmd on-cd &{{
  if [ "$PWD" = "/foo" ]; then
    lf -remote "send $id set hiddenfiles \"*mp4\""
  elif [ "$PWD" = "/bar" ]; then
    lf -remote "send $id set hiddenfiles \"*pdf:*txt\""
  else
    lf -remote "send $id set hiddenfiles \".*\""
  fi
}}

[carlosedp]

Hi @sxyazi , would you reopen this as I've changed the implementation to follow the patterns as you explained above?
It's all done already.

[carlosedp]

I also updated the docs to match the changes here: yazi-rs/yazi-rs.github.io#294

[carlosedp]

Actually I've reopened the PR with new code here: #3266