Skip to content

[Feature request] Method to avoid accidental "Find All in All Opened Documents" delays #18429

Open

Description

@hairybaboon

Is there an existing issue (open or closed) for this?

  • I have searched the existing issues

Description of the Issue

Originally posted here to ask if such a feature existed: https://community.notepad-plus-plus.org/post/106403

The most relevant prior issue I found is #8213 which covers confusing button order and selection and accidentally hitting the wrong button. This shows precedent for avoiding clicking the wrong button.

Copy Paste from my community post:

I tend to have a lot of 150mb text files open at any given time. Multiple versions, flavors, etc. I basically only ever do Find all in Current Document. Since the Find all in All Opened Documents button is right next to it, I sometimes accidentally hit it and then get stuck waiting ages for it to search all the files, especially if it’s a complex regex.

Is there any way for me to disable the button? Or even have a popup after pressing that asks if I’m sure I want to do that? Even when I need to look at another file for the same thing, it’s usually 1 or two other files, not 10+, so it’s easier to go document by document.

Describe the solution you'd like.

There's a few possible solutions, each has benefits / downsides.

  1. Preferences setting to completely hide "Find all in All Opened Documents" button from the ctrl+f search menu.
    1. Downside: If button is hidden, takes a number of steps to re-enable if there is an immediate need, then have to disable again.
  2. "Are you sure" popup when "Find all in All Opened Documents" is hit.
    1. If the option for this were in Preferences, with a default value of OFF then status quo operation is maintained, but people could enable popup if desired
  3. Interrupt the slow active search. Nothing changes for activating the search, but provide a way to bail out of the search in progress.
    1. Might not be doable depending on how the background capabilities of the search work. Depending on how Notepad++ may lag, it might still take a while to bail out of the active search.

I think I would most prefer number 2. Doesn't affect anyone's existing setup, allows me to block accidental clicks, isn't a pain to overcome if I do need to run a "Find all in All Opened Documents"

Debug Information

Notepad++ v8.7.5   (64-bit)
Build time : Dec 21 2024 - 05:13:03
Path : C:\Program Files\Notepad++\notepad++.exe
Command Line : 
Admin mode : OFF
Local Conf mode : OFF
Cloud Config : OFF
Periodic Backup : ON
Placeholders : OFF
DirectWrite : ON
Multi-instance Mode : monoInst
File Status Auto-Detection : cdEnabledNew (for current file/tab only)
Dark Mode : OFF
OS Name : Windows 10 Pro (64-bit)
OS Version : 22H2
OS Build : 19045.3570
Current ANSI codepage : 1252
Plugins : 
    mimeTools (3.1)
    NppConverter (4.6)
    NppExport (0.4)

Anything else?

No response

Activity

  1. pryrt commented on Oct 1, 2026

    @pryrt
    Contributor

    My vote would be for option 3:

    Options 1 or 2 would only be useful to someone who accidentally clicks the button and never intentionally uses that button. I am guessing that's not a very common situation (no offense to the requester)

    Option 3, on the other hand, would work for the OP or anyone else who accidentally clicks, and has the benefit that it allows anyone to cancel a Find All that's taking too long (because they didn't remember they had their 100Mb file open, or because their regex was more complicated than they thought, or because they realized they made a mistake in their regex and want to stop it, or....)

    In other words, in my opinion, option 3 is useful to a wide variety of users, whereas options 1 or 2 are only for a small niche. Doing the implementation option that helps the most people is the best use of a developer's time.

    If I understood @Coises's reply in the Forum discussion correctly, then the option-3-based progress bar and cancel for Find All in Opened Documents could be handled similarly to Find In Files's (FIF) cancel: the progress would update between each file (or between each step of the search within a file), and the cancel could be checked/processed at that same time.

    So my vote would be for option 3 to be implemented similarly to the FIF progress/cancel implementation.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions