notepad-plus-plus / notepad-plus-plus/notepad-plus-plus

[Bug?/FR] "Find in Files" results not visible in results pane for long lines

Open
#9,879 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C++
Stars
29.4k
Forks
5.4k
PR merge metrics
No merged PRs in 30d

Description

Description of the Issue

For files with very long lines -- e.g. obfuscated JavaScript files with no line breaks -- the "Find In Files" results pane truncates the line before the location of the actual match, more often than not causing it to hide the search results.

Double-clicking the results does highlight the result and move the cursor to its location in the editor, so that part is good. However, it's not always possible to see the results in the results pane itself: You have to select each individual result so that it becomes visible in the editor, which can be a workflow issue when there are a lot of results.

Steps to Reproduce the Issue
  1. Use the "Find in Files" feature to search a source file or directory where the file(s) have very long lines and a lot of results.
  2. In the results pane, observe the long lines, scroll all the way right to see where they are truncated.
Current Behavior

The location / context of the results is not visible in the results pane.

Proposed Behavior

One option could be to also truncate the beginning of large lines, so that the result (with surrounding context) appears in the section of the line that the results pane displays.

And, personally, I wouldn't mind if the lines were truncated (left and right side) in such a way that horizontal scrolling was no longer needed in the results pane at all; i.e. center on match and truncate to window width. But that'd just be icing on the cake; I don't know what the best option is, really.

Example:

https://user-images.githubusercontent.com/5651184/118405268-06527d00-b645-11eb-989b-1d3f163e5c4e.mp4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reproducing the issue through the Find in Files feature with an obfuscated JavaScript file containing very long lines and many matches, then inspect the results pane behavior. Done means match locations and surrounding context remain visible in the pane without selecting each result; the payload names no source file or test to begin with.

Written by the indexing model from the issue text.

Assessment

Tech stack
cpp
Domain
desktop, search
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
38/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.