discussion on config file structure

[ovwxxwvo]

discussion on config file structure

Hey mate, I like yazi, don't try to get rid of me, I will be by your side.
I will try to be polite & helpful.

Let's skip the formalities and get to the main topic.

---

Here is my personal opinion.

• The customized configure file just need one entry.
• The prepend_ and append_ things is a little bit overdone.

---

Explanation of my thoughts.

We have the default configuration file from this yazi,
& then the customized config file will be loaded with an override,
which is relatively simple.
The configuration file is loaded at most twice.

& then I feel that yazi has considered too much.
This prepend_ and append_ may make the things become complicated.

The xxxx.yazi/init.lua format already well regulated the path structure of the plugin.
Free users to organize the structure of the config file.

---

The customized configure file just need one entry.

On the yazi side, there may be two entries,
one for configuring the whole application,
and the other for configuring the plugin.

Unlike nvim, the configurations are all done with scripts.
Whether it's the old vim script or the new lua script.
which makes us only need one entry that compatible with
the old vim script configuration file in this entry.

No matter there is one or two entry, as user,
we just want to keep the config entry clean.
Also, for the configuration files of plugins & keymap & theme.
When they become too bulky in one file,
we will want to separate them into separate files.

The plugin config file will be under the init.lua file,
The basic config file & keymap config file & theme config file
will under the yazi.toml or maybe called init.toml, whatever.
Also, these files can include other branchs.

The most important thing is, actually,
all yazi needs to do is just give us an entry,
and then we organize the structure of the config file by ourselves.
Be happy to be everything under control.

someting like nvim init.lua, like this,

vim.cmd[[source ~/.config/nvim/deft.vim]]

require('lazy-nvim')

require('script.plugdown')

require('plugin.noice')
require('plugin.lualine')
require('plugin.matchparen')
require('plugin.mason')
require('plugin.cmp')
require('plugin.telescope')

require('keymap.normal')
require('keymap.visual')
require('keymap.contrl')
require('keymap.functn')
require('keymap.window')
require('keymap.plugin')

require('color.defaut')

someting like vim vimrc, like this,

" source $VIMRUNTIME/defaults.vim
source ~/.config/nvim/vim/plug.vim

source ~/.config/nvim/vim/script/auto.vim
source ~/.config/nvim/vim/script/basic.vim

source ~/.config/nvim/vim/script/plugdown.vim
source ~/.config/nvim/vim/plugin/airline.vim
source ~/.config/nvim/vim/plugin/markdownpreview.vim

" source ~/.config/nvim/vim/keymap/move.vim
" source ~/.config/nvim/vim/keymap/wins.vim
" source ~/.config/nvim/vim/keymap/ctrl.vim
" source ~/.config/nvim/vim/keymap/edit.vim
" source ~/.config/nvim/vim/keymap/func.vim

" source ~/.config/nvim/vim/color/forest.vim

---

The prepend_ and append_ things is a little bit overdone.

I really think this is very unnecessary
and needs a revolution to cut it off.

But this might require greater changes and modifications,
and it will be very painful.

What does the yazi think?

---

[sxyazi]

prepend_ and append_ are meant to avoid configuration merging, which is difficult or even impossible. Instead, Yazi uses configuration mixing and selects the first matching item at runtime.

For example, if I want to set a new [open] rule for xz and rar files to replace the default:

yazi/yazi-config/preset/yazi.toml

Line 71 in 6a4f6aa

{ mime = "application/x-{tar,bzip*,7z-compressed,xz,rar}", use = [ "extract", "reveal" ] },

With the current implementation, I just need:

[open]
prepend_rules = [
  { mime = "application/x-{xz,rar}", use = "my-own-opener" },
]

Questions for Your Proposal:

1. How would this work in your proposed approach?
   Specifically, how should Yazi merge the default "application/x-{tar,bzip*,7z-compressed,xz,rar}" with the custom "application/x-{xz,rar}" rule?

2. Handling Glob Expressions:
   Since the configuration uses glob expressions, would this require the development of a static analyzer to safely merge configurations?

3. Preventing User Confusion:
   How can we ensure the merged result is predictable and avoids surprising the user? Predictability is critical, especially in cases where overrides and default rules may conflict.

Would your approach provide better clarity or usability than the current prepend/append system?

[ovwxxwvo]

& I finally know what this prepend_ & append_ for,
some config option like [open] [opener] [plugin].

I prefer to take configuration mixing, like I already done.
but that just only for me, maybe.
I like to let it simple overwrite, like this,

[opener]

  edit = [
  	{ run = 'nvim "$@"', desc = "nvim", block  = true, for = "unix" },
    ]

  play = [
  	{ run = 'mpv "$@"',  desc = "mpv",  orphan = true, for = "unix" },
    ]

  extract = [
  	{ run = 'ya pub extract --list "$@"', desc = "Extract here", for = "unix" },
    ]

[open]

  rules = [

    # office
    { name = "*.pdf",  use = "edit" },
    { name = "*.doc",  use = "edit" },
    { name = "*.docx", use = "edit" },
    { name = "*.xls",  use = "edit" },
    { name = "*.xlsx", use = "edit" },
    { name = "*.ppt",  use = "edit" },
    { name = "*.pptx", use = "edit" },

    # { name = "*/", use = [ "open", "reveal" ] },
    { mime = "text/*",  use = [ "edit", "reveal" ] },
    { mime = "image/*", use = [ "play", "reveal" ] },
    { mime = "audio/*", use = [ "play", "reveal" ] },
    { mime = "video/*", use = [ "play", "reveal" ] },

    # Archive
    { mime = "application/{,g}zip",                            use = [ "extract", "reveal" ] },
    { mime = "application/x-{tar,bzip*,7z-compressed,xz,rar}", use = [ "extract", "reveal" ] },

    # Empty file
    # { mime = "inode/x-empty", use = [ "edit", "reveal" ] },
    # Fallback
    { name = "*", use = [ "edit", "reveal" ] },

    ]

Is that config mixing & prepend_|append_ can work together,
or we just can only pick one to setup the config file.
how does it work.

How about load 3 entry config file,

• one entry config file yazi.toml for config mixing, include basic keymap theme,
• one entry config file pend.toml for prepend_|append_, only for supplement,
• one entry config file init.lua for plugin load & setup.

Is this somehow your prepend_|append_ system can work well.
how your prepend_|append_ system work???

If me, I will just let user copy it all,
just kidding, not the way you wanted.

[sxyazi]

Is that config mixing & prepend_|append_ can work together,

I think you're confusing something - prepend_ and append_ here exactly refer to "configuration merging".

[ovwxxwvo]

# if I use this, 
[open]
prepend_rules = [
  { mime = "application/x-{xz,rar}", use = "my-own-opener" },
]

# end it up like this,
[open]
prepend_rules = [
  { mime = "application/x-{xz,rar}", use = "my-own-opener" },
  { mime = "application/x-{tar,bzip*,7z-compressed,xz,rar}", use = [ "extract", "reveal" ] }, 
]

# if I use this, 
[open]
rules = [
  { mime = "application/x-{xz,rar}", use = "my-own-opener" },
]

# end it up like this,
```toml
[open]
prepend_rules = [
  { mime = "application/x-{xz,rar}", use = "my-own-opener" },
]

is this right?