The default maximum result display count seems to have been mistakenly set to `250`

[leonasdev]

Description

In: https://github.com/nvim-telescope/telescope.nvim/blob/20bf20500c95208c3ac0ef07245065bf94dcab15/lua/telescope/pickers.lua#L561C1-L565C44 , the comment seems to indicate that the default value for max_result should be 10000.

But in: https://github.com/nvim-telescope/telescope.nvim/blob/20bf20500c95208c3ac0ef07245065bf94dcab15/lua/telescope/pickers.lua#L319 , __scrolling_limit is set to 250 when opt.temp__scrolling_limit is not present which seems wrong.

When users search for keywords, they may scroll beyond 250 entries to find a specific item. If the actual number of entries exceeds 250, users might mistakenly believe that they have thoroughly searched for the keywords.

And traversing 250 entries is more likely compared to navigating through 10000 entries.

So, I believe setting max_result to 10000 is more reasonable, or alternatively, allowing users to configure this value based on their performance preferences would be a better option.

Neovim version

NVIM v0.9.2
Build type: Release
LuaJIT 2.1.1692716794

Operating system and version

Ubuntu 22.04

Telescope version / branch / rev

master

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
- OK fd: found fd 8.3.1

Steps to reproduce

1. nvim
2. :Telescope highlights
3. The prompt shows the total of result may beyond 250 (like 500 or something)
4. When you scolling results list, you'll find that not all results is on the Results list.

Expected behavior

The max_result value should set to something like 10000 not 250, or alternatively, allowing users to configure this value based on their performance preferences would be a better option.

Actual behavior

The max_result seems accidentally set to 250, whcih users might mistakenly believe that they have thoroughly searched for the keywords.

Minimal config

vim.cmd [[set runtimepath=$VIMRUNTIME]]
vim.cmd [[set packpath=/tmp/nvim/site]]
local package_root = '/tmp/nvim/site/pack'
local install_path = package_root .. '/packer/start/packer.nvim'
local function load_plugins()
  require('packer').startup {
    {
      'wbthomason/packer.nvim',
      {
        'nvim-telescope/telescope.nvim',
        requires = {
          'nvim-lua/plenary.nvim',
          { 'nvim-telescope/telescope-fzf-native.nvim', run = 'make' },
        },
      },
      -- ADD PLUGINS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
    },
    config = {
      package_root = package_root,
      compile_path = install_path .. '/plugin/packer_compiled.lua',
      display = { non_interactive = true },
    },
  }
end
_G.load_config = function()
  require('telescope').setup()
  require('telescope').load_extension('fzf')
  -- ADD INIT.LUA SETTINGS THAT ARE _NECESSARY_ FOR REPRODUCING THE ISSUE
end
if vim.fn.isdirectory(install_path) == 0 then
  print("Installing Telescope and dependencies.")
  vim.fn.system { 'git', 'clone', '--depth=1', 'https://github.com/wbthomason/packer.nvim', install_path }
end
load_plugins()
require('packer').sync()
vim.cmd [[autocmd User PackerComplete ++once echo "Ready!" | lua load_config()]]

[staticssleever668]

I've tried the option for a few days and noticed an issue - if you call the 'restore' picker with a different temp__scrolling_limit value than the previous picker, instead of the previously selected line the very last one is always selected.

[Conni2461]

We actually changed it from 10000 down to 250 because of performance issues. Having a scrolling limit that high means that we actually need to sort 10k items correctly on every input change (or at least we start the sorting). if its just 250 we can discard correctly sorting everything after 250 we only need to figure out whats inside that window.

Maybe 1000 is more reasonable.

For resume we could just load zhe same scroll limit

[mister-choo]

We actually changed it from 10000 down to 250 because of performance issues. Having a scrolling limit that high means that we actually need to sort 10k items correctly on every input change (or at least we start the sorting). if its just 250 we can discard correctly sorting everything after 250 we only need to figure out whats inside that window.

Maybe 1000 is more reasonable.

For resume we could just load zhe same scroll limit

Again, an option would be nice

[gzagatti]

I faced a similar issue when going through a list of diagnostics. The list was well beyond 250 items because the diagnostic was overly sensitive. Telescope let me scroll until item 250, but it wouldn't go past this number of items even though it displayed additional results at the bottom of the list. I know I could have filtered the results, but for this particular task I couldn't write a filter that would select only the results I want with confidence.

A suggestion would be to add a shortcut that the user can press to add all the results to the current list. This would be similar to a "load more..." button in some websites. That way, all the results would have a hard limit of 250 by default, but could be increase on a case-by-case by the user.