Files shown without hits when maximum number of results reached

[oscargus]

Issue Report Checklist

• [x] Searched the issues page for similar reports
• [x] Read the relevant sections of the Spyder Troubleshooting Guide and followed its advice
• [x] Reproduced the issue after updating with conda update spyder (or pip, if not using Anaconda)
• [ ] Could not reproduce inside jupyter qtconsole (if console-related)
• [ ] Tried basic troubleshooting (if a bug/error)
  • [ ] Restarted Spyder
  • [ ] Reset preferences with spyder --reset
  • [ ] Reinstalled the latest version of Anaconda
  • [ ] Tried the other applicable steps from the Troubleshooting Guide
• [x] Completed the Problem Description, Steps to Reproduce and Version sections below

Problem Description

Minor issue that doesn't really affect anything, but still something that one may want to fix.

When searching using the Find pane and reaching the maximum number of hits, sometimes a file is added to the list that do not have any hits. I've also seen cases where two files without hits are added. Probably some counter is a bit off, so the files are added although the maximum number of results is already reached.

What steps reproduce the problem?

1. Search for something quite common in a directory
2. Have a bit of "luck"

What is the expected output? What do you see instead?

Files without any visible hits should not be in the search results. The files that have no search results, do indeed have hits, just that they do not show up as the maximum number is reached.

Paste Traceback/Error Below (if applicable)

Versions

• Spyder version: 5.0.5 None
• Python version: 3.9.5 64-bit
• Qt version: 5.9.7
• PyQt5 version: 5.9.2
• Operating System: Windows 10

Dependencies

# Mandatory:
atomicwrites >=1.2.0          :  1.4.0 (OK)
chardet >=2.0.0               :  4.0.0 (OK)
cloudpickle >=0.5.0           :  1.6.0 (OK)
cookiecutter >=1.6.0          :  1.7.2 (OK)
diff_match_patch >=20181111   :  20200713 (OK)
intervaltree >=3.0.2          :  3.1.0 (OK)
IPython >=7.6.0               :  7.26.0 (OK)
jedi =0.17.2                  :  0.17.2 (OK)
jsonschema >=3.2.0            :  3.2.0 (OK)
keyring >=17.0.0              :  23.0.1 (OK)
nbconvert >=4.0               :  6.1.0 (OK)
numpydoc >=0.6.0              :  1.1.0 (OK)
paramiko >=2.4.0              :  2.7.2 (OK)
parso =0.7.0                  :  0.7.0 (OK)
pexpect >=4.4.0               :  4.8.0 (OK)
pickleshare >=0.4             :  0.7.5 (OK)
psutil >=5.3                  :  5.8.0 (OK)
pygments >=2.0                :  2.9.0 (OK)
pylint >=1.0                  :  2.9.6 (OK)
pyls >=0.36.2;<1.0.0          :  0.36.2 (OK)
pyls_black >=0.4.6            :  0.4.6 (OK)
pyls_spyder >=0.3.2;<0.4.0    :  0.3.2 (OK)
qdarkstyle =3.0.2             :  3.0.2 (OK)
qstylizer >=0.1.10            :  0.1.10 (OK)
qtawesome >=1.0.2             :  1.0.2 (OK)
qtconsole >=5.1.0             :  5.1.0 (OK)
qtpy >=1.5.0                  :  1.9.0 (OK)
rtree >=0.9.7                 :  0.9.7 (OK)
setuptools >=39.0.0           :  52.0.0.post20210125 (OK)
sphinx >=0.6.6                :  4.0.2 (OK)
spyder_kernels >=2.0.4;<2.1.0 :  2.0.5 (OK)
textdistance >=4.2.0          :  4.2.1 (OK)
three_merge >=0.1.1           :  0.1.1 (OK)
watchdog >=0.10.3             :  2.1.3 (OK)
zmq >=17                      :  20.0.0 (OK)

# Optional:
cython >=0.21                 :  None (NOK)
matplotlib >=2.0.0            :  None (OK)
numpy >=1.7                   :  1.20.3 (OK)
pandas >=1.1.1                :  None (NOK)
scipy >=0.17.0                :  1.6.2 (OK)
sympy >=0.7.3                 :  1.9.dev (OK)

[steff456]

Hi @oscargus,

Thanks for opening this issue, if you could find a way to have the systematic way of reproducing this bug it will be great. We will work on this for one of our future releases.

@ccordoba12 have you encounter this issue while doing the improvements for the files pane?

[oscargus]

I'd say that it is systematic in the sense that it always behave like this, but to actually trigger it require some specific searches.

However, searching for class in the current master spyder source directory (commit bb2ed9a6c90df30f370f7f67413d31b363cbfe15 ) gives eight files at the end without any hits. Even if you manage to add a few classes before you can try it, something like that is quite likely to trigger it. Now I was using the current master version of Spyder, so I can confirm that it is still there.

[steff456]

I'll give it a try! Thanks :)

[ccordoba12]

@ccordoba12 have you encounter this issue while doing the improvements for the files pane?

I haven't seen this error but I usually don't go until the end of the list.

However, searching for class in the current master spyder source directory (commit bb2ed9a ) gives eight files at the end without any hits

Thanks @oscargus! I could reproduce it with your help and will try to fix it in our 5.2.0 version, to be released at the end of September.