Add new icons support to `ya.input`

[hankertrix]

ya env output

Yazi
    Version: 26.5.6 (ef654f44 2026-06-24)
    Debug  : false
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.96.0 (ac68faa2 2026-05-25)
    Backtrace: None

Ya
    Version: 26.5.6 (ef654f44 2026-06-24)
    Debug  : false
    Triple : x86_64-unknown-linux-gnu (linux-x86_64)
    Rustc  : 1.96.0 (ac68faa2 2026-05-25)

Config
    Init             : /home/hanker/.config/yazi/init.lua (236 chars)
    Yazi             : /home/hanker/.config/yazi/yazi.toml (1632 chars)
    Keymap           : /home/hanker/.config/yazi/keymap.toml (9885 chars)
    Theme            : /home/hanker/.config/yazi/theme.toml (739 chars)
    VFS              : /home/hanker/.config/yazi/vfs.toml (No such file or directory (os error 2))
    Package          : /home/hanker/.config/yazi/package.toml (445 chars)
    Dark/light flavor: ArcSwapAny("bluloco-dark") / ArcSwapAny("bluloco-light")

Emulator
    TERM                : Some("xterm-kitty")
    TERM_PROGRAM        : None
    TERM_PROGRAM_VERSION: None
    Brand.from_env      : Some(Kitty)
    Emulator.detect     : Emulator { kind: Left(Kitty), version: "kitty(0.47.1)", light: true, csi_16t: (14, 32), force_16t: false }

Adapter
    Adapter.matches    : Kgp
    Dimension.available: Dimension { cols: 89, rows: 47, width: 1246, height: 1504 }

Desktop
    XDG_SESSION_TYPE           : Some("wayland")
    WAYLAND_DISPLAY            : Some("wayland-1")
    DISPLAY                    : Some(":0")
    NIRI_SOCKET                : Some("/run/user/1000/niri.wayland-1.2558.sock")
    SWAYSOCK                   : None
    HYPRLAND_INSTANCE_SIGNATURE: None
    WAYFIRE_SOCKET             : None

SSH
    shared.in_ssh_connection: false

WSL
    WSL: false

Variables
    SHELL              : Some("/bin/bash")
    EDITOR             : Some("nvim")
    VISUAL             : Some("nvim")
    YAZI_FILE_ONE      : None
    YAZI_CONFIG_HOME   : None
    YAZI_ZOXIDE_OPTS   : None
    SSH_AUTH_SOCK      : None
    FZF_DEFAULT_OPTS   : None
    FZF_DEFAULT_COMMAND: None

Text Opener
    default     : Some(OpenerRuleArc(OpenerRule { id: Id(3), run: NonEmptyString("${EDITOR:-vi} %s"), block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))
    block-create: Some(OpenerRuleArc(OpenerRule { id: Id(3), run: NonEmptyString("${EDITOR:-vi} %s"), block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))
    block-rename: Some(OpenerRuleArc(OpenerRule { id: Id(3), run: NonEmptyString("${EDITOR:-vi} %s"), block: true, orphan: false, desc: "$EDITOR", for: Unix, spread: true }))

Multiplexers
    TMUX               : false
    tmux version       : No such file or directory (os error 2)
    tmux build flags   : enable-sixel=Unknown
    ZELLIJ_SESSION_NAME: None
    Zellij version     : No such file or directory (os error 2)

Dependencies
    file          : 5.48
    ueberzugpp    : No such file or directory (os error 2)
    ffmpeg/ffprobe: 8.1.2 / 8.1.2
    pdftoppm      : 26.06.0
    magick        : 7.1.2-26
    fzf           : 0.72.0
    fd/fdfind     : 10.4.2 / No such file or directory (os error 2)
    rg            : 15.1.0
    chafa         : No such file or directory (os error 2)
    zoxide        : No such file or directory (os error 2)
    7zz/7z        : No such file or directory (os error 2) / 26.01
    resvg         : 0.47.0
    jq            : 1.8.2

Clipboard
    wl-copy/paste: 2.3.0 / 2.3.0
    xclip        : No such file or directory (os error 2)
    xsel         : No such file or directory (os error 2)

Routine
    `file -bL --mime-type`: text/plain

Please describe the problem you're trying to solve

Currently, the actions that have input, like create and rename have icon support, which should be added to ya.input as well.

Would you be willing to contribute this feature?

• Yes, I'll give it a shot

Describe the solution you'd like

I think that the ya.input function should take a new option in its parameter table, maybe called icon or something else, which takes a function that returns back an icon.

---@alias IconMap table<string, string>

local DEFAULT_ICONS_MAP = {
    [".+.lua"] = "lua_icon",
    [".+.rs"] = "rust_icon",
    [".+.py"] = "python_icon",
}

---@param input string The user's input
---@param icons_map IconMap? The mapping of lua patterns to the icon
---@return string icon The icon to display
function default_ya_input_icon(input, icons_map)
    icons_map = icons_map or DEFAULT_ICONS_MAP
    for pattern, icon in pairs(icons_map) do
        if input:match(pattern) then return icon end
    end
    return ""
end

function create_ya_input_icon(icons_map)
    return function(input)
        default_ya_input_icon(input, icons_map)
    end
end

The default ya.input.icon function could probably look something like the above, so that it is easy to pass a map of Lua patterns to the icons, which I assume is probably the primary way that users are going to use to produce an icon.

For more complicated purposes, the user would be able to just write their own function to manage the icon for the input.

Yazi should probably expose the default mappings for the icons, and optionally the default function (but it can just be called if an icon function isn't given).

Additional context

#4080 (comment)

This is just to discuss the API for adding icon support to ya.input.

Checklist

• I have searched the existing issues/discussions
• The latest nightly build doesn't already have this feature

[sxyazi]

There are still a few design details I'm not certain about yet:

• Should we support plugin-specific icons? Does that even make sense?
  • If yes, plugins get a lot more flexibility, but that also means plugins would need to maintain their own icon set and that could make the UI look inconsistent, e.g. the same file type might show one icon in the file list and built-in inputs, but a different icon in plugin inputs.
  • If no, can plugin needs be narrowed down so they only rely on the rules already defined under [icon] in the user's theme? For things that don't fit, could we solve it by expanding the theme system's icon rules instead? Are there any real-world use cases related to this?
• Should we expose the entire subtitle row of the input UI to the plugin system, which is the row where the icon is, so plugins can customize other things besides the icon?
  • If yes, how should plugin-defined content like "10/30" (cursor position/total length) interact with the icon? For example, how to make the icon go first (icon | 10/30), or last (10/30 | icon), or how they each have different text styles?
  • If no, should we just not consider subtitle customization at all, or is there some alternative way to support custom subtitles?

[hankertrix]

• Should we support plugin-specific icons? Does that even make sense?

For my plugin's use case, I think it's fine to just use Yazi's default icons, since I'm trying to provide the same experience, just with different behaviour.

However, I can see some use for plugin-specific icons in bookmark and tagging plugins.

• If yes, how should plugin-defined content like "10/30" (cursor position/total length) interact with the icon? For example, how to make the icon go first (icon | 10/30), or last (10/30 | icon), or how they each have different text styles?

Regarding this, I'm not sure if consistency across plugins is desired, but if it is not, then I think having plugin developers pass a function that takes the icon and formats it in the way the plugin developer desires would provide maximum flexibility. Yazi can provide a default function to format the content if no function is given.

[sxyazi]

@cschanhniem Your comment looks very much like written by AI. Just a mild reminder that AI-written comments are not allowed in this project.