Highlight effect for matched path parts in `Fall file` are not visible

[blyoa]

When using Fall file, matched text in path parts of the candidate list does not show the highlight effect settings in vimrc.

Current behavior

Even if input text matches some parts of the path, the matched parts does not show the highlight effect. Only the file names are highlighted.

Current behavior example:

(deno is not highlighted in denops/fall)

Expected behavior

When input text matches parts of paths, I expect the matched parts of the paths to be highlighted.

Expected behavior example (hard-coded to show intended behavior):

Steps to reproduce

1. Open vim with the following minimal vimrc in this project directory:

   vim -u vimrc -N

2. Invoke :Fall file.

3. Input some text that is a substring of a path.

Minimal vimrc settings

let s:plugin_root_dir = '~/.vim/plugin_dir'
let &runtimepath .= ',' . s:plugin_root_dir . '/vim-plug'

call plug#begin(s:plugin_root_dir)
Plug 'cocopon/iceberg.vim'
Plug 'vim-denops/denops.vim'
Plug 'vim-fall/fall.vim'
call plug#end()

set termguicolors
set background=dark
colorscheme iceberg

function! s:customize_fall_style() abort
  hi link FallListSelected Title
  hi link FallListMatch Title
endfunction

augroup my_fall_style
  autocmd!
  autocmd ColorScheme * call s:customize_fall_style()
augroup END
call s:customize_fall_style()

Note

With default fall.vim settings, the matched parts in the selected line is difficult to see with some colorschemes. Highlights may not be displayed as expected.

Default settings example (the hi link ... lines in the above vimrc are commented out):

[lambdalisue]

Hmm… it’s a bit tricky. I’m not completely sure yet, but it seems that the highlight (decoration) provided by the smart_path renderer is overriding the highlight provided by the matcher (via the list component).

How did you create the

Expected behavior example (hard-coded to show intended behavior):

part? That might help me investigate further.

[blyoa]

I created the “Expected behavior example (hard-coded to show intended behavior)” with the following steps:

1. Replaced buffer.decorate with a modified version that supports the priority control (as proposed in 👍 Add a priority property to Decoration vim-denops/deno-denops-std#295).

2. Replaced the smartPath renderer with a modified version where the Comment highlight is assigned a priority of -10.

3. Modified the #renderContent method defined in denops/fall/component/list.ts so that decoration objects include a priority value, for example:

   const decorations = v.decorations
     .filter((d) => d.column < width)
     .map((d) => ({
       highlight: HIGHLIGHT_MATCH,
       ...d,
       line: i + 1,
       priority: d.priority ?? 10,
     }));

   (I think we may also need to specify priority in other objects for the decorate argument, but the above was sufficient to capture the “Expected behavior example (hard-coded to show intended behavior)” screenshot.)

---

As you mentioned, it seems that some highlights (e.g., Comment) may override others such as FallListMatch. My suspicion is that this is the cause of the issue.

I am not sure whether introducing highlight priorities aligns with the policy of this project, since it adds some complexity in terms of designing and maintaining priority values.