nvim 'wrap_result' option make the first line of 'oldfiles picker' hidden

[ForteDexe]

Description

This happens when you have a long file path in the 'oldfiles picker' list.

Neovim version

Lastest stable

Operating system and version

Arch Manjaro KDE

checkhealth telescope

telescope: require("telescope.health").check()
========================================================================
## Checking for required plugins
  - OK: plenary installed.
  - OK: nvim-treesitter installed.

## Checking external dependencies
  - OK: rg: found ripgrep 13.0.0
  - WARNING: fd: not found. Install [sharkdp/fd](https://github.com/sharkdp/fd) for extended capabilities

## ===== Installed extensions =====

## Telescope Extension: `coc`
  - INFO: No healthcheck provided

## Telescope Extension: `file_browser`
  - INFO: No healthcheck provided

Steps to reproduce

wrap_result = 1

Expected behavior

No response

Actual behavior

Minimal config

None

[eyev0]

Having the same issue actually on any picker, setting wrap_result to true seems to offset first visible line to the (N+1)-th line when there are N lines wrapped in list

[Conni2461]

You probably wont see any Problems if you use sorting_strategy = ascending (see :help telescope.defaults.sorting_strategy). Would be nice if someone could test this

CC @sultanahamer i knew it wasnt that easy. Maybe that is not a feature we wanna have

[sultanahamer]

Wrapping doesn't create more lines is my understanding and navigating to line number with : works with wrap files in general. Let me see this computation part and see if its using something else to do the selection.

[sultanahamer]

The behavior I see is that selection is happening but is not in the visible view. We have to do ctrl +p and ctrl + n to see the actual selection. So, selection is happening alright but the scroll part is not.

[Conni2461]

sure the row seems to be correct but its still borked. And i dont need this issue so the fix needs to come from the community

[sultanahamer]

If this happens only when users chooses the option wrap_results = true then, we can let it be a known issue while myself and others work on the fix.

Since this option is disabled by default, it shouldn't affect many users.

[Conni2461]

We can leave it like this for now, i wont remove it. Only if the maintenance overhead is greater than the benefit of having it

[sultanahamer]

This is not reproducible if users types the search string slowly or type the entire search term except last letter and then press the last letter after half a sec.

Like if I have to search in git_files "main" then I can type "mai" with normal speed, give it a second to get results then press n and the picker is alright, scrolled till end of results, showing the selection as well.

Not sure if there is any computation involved here to fix.