(Document list + Find + Multiple files + at least 1 file in dual show) bug:

[W TX]

@Alan-Kilborn
Here are snapshots that should give one a very clear picture of what improvement should be made and where the bug is located. I list one suggested improvement post each time so we can focus on only a small step and you know what I describe.

All files are the same for show example purposes.

Problem 1: there are many files having double views, one cannot recognize which one is at the upper pane or low pane.

Suggested Improvement:

1. All files belonging to the upper pane or low pane should have different color icons.
2. All files belonging to the upper pane should be listed at the upper part of the document list pane, and all files belonging to the low pane should be listed at the low part of the document list pane.
3. There should be a line separate the upper pane file names from low pane file names.

[Alan Kilborn]

@W-TX

Sorry but I still have no idea what you are talking about. Perhaps someone else will jump in and can help you. I’m out.

[Neil Schipper]

@W-TX said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

I don’t know if I can be of much help but in regard to:

There should be a line separate the upper pane file names from low pane file names.

There may be benefits to your use of “Document List” that I’m not aware of, but you may have a better experience if (in Pref-Gen) you turn this panel off, and turn on (=unhide) Tab Bar, and set it to Vertical. This way, in dual pane editing, there will be a visual separation between the two file groups. If a file is open in both panes, it will easier to tell which tab goes with which pane.

Some hints about expressing things (in this context):

• instead of “Click mouse left button”, say “click”
• instead of “search area”, say “search results pane” or “search results window”
• instead of “search position”, say “match” or “hit”

Finally, in your first post you wrote

the contents are unstable, showing mixed content of the search line with contents of an unexpected file

If a “find in files” operation results in bad behavior, this is where screen shots are very useful, and be clear about what happened, for example “in the results window, I clicked the match for Line 5 of 1-Fifo but it took me to Line 8 of 2-Fifo”

[W TX]

@Neil-Schipper
Thank you for your answer, especially helping me pointing to my spelling error.

I currently now open about 40 files to simultaneously edit them. So using the Tab Bar method is not an option.

This bug is closely related to the document list pane and files having dual views.

The above two panes show where the bug starts: a file in the document list pane has 2 views.

Move horizontal bar between the upper pane and the lower pane upperward to hidden the upper pane and maximize the lower pane. Click Ctrl+F keys to pop the “find window”, click the button “Find All in All Opend Documents” and get the following search result.

It has no problem, everything is normal.

It has a problem! I clicked the search result for 1-FIFO-Example, but it shows 7-FIFO-Example as shown in the document list pane. It enters the bug.

I clicked the last 7-FIFO-Example in the document list pane; it returns normally.

I further clicked the first search result for 1-FIFO-Example, it suddenly shows 2 same lines: “entity sync_fifo is”. And I found the situation becomes unstable, so I stopped immediately to avoid any damage to the edited files.

There is my analysis of the conditions under which the bug appears.

1. The document list pane is opened with at least one file having 2 views.
2. Move the horizontal bar between the upper pane and lower pane to hide the upper pane and maximize the lower pane.
3. Do a search with multiple files selection.
4. Click the mouse left bottom at the search results pane to show a selected file search position that belongs to the upper pane.
5. The bug happens.
6. If the mouse left bottom at the file content pane is clicked to try to edit the file, a bug appears and the editor enters an unstable condition.

The description of the bug conditions is slightly different from the copied snapshots, the reason is when it is entered into described conditions status is always unstable and has many different bad and unpredictable behaviors.

Here is my observation of why the error happens.

The bug is closely related to 2 view pane scheme. When one view pane is maximized and another pane is hidden and do a search for multi-files.

After the search, the maximized pane is the main pane. After clicking the search results pane for a file with the same pane, there is no error; when clicking the search results pane for a file with a different pane, the error appears.

The handling of the document list pane should be improved while the same bug would be corrected and disappear.
The 2 view mechanism is a very useful tool. When it is to compare one file with another file 2 views mechanism is necessary. But for most of the time, a Notepad++ user always prefers using one maximized pane and one hidden pane. He does not care about whether a currently edited file is in the upper pane or the lower pane. So the software designer should have such a design that when a file in the document list pane is clicked, it is always automatically shown in the maximized pane and the maximized pane setting is changed accordingly and belongs to the file. Currently, when a view pane is maximized and a file belonging to the hidden view pane is clicked, it shows nothing changed in the view pane because the hidden pane is hidden and the user has to manually move the separation bar to show the hidden file. The current design is not a good decision, it generates the bug I have showed and it also causes an uncomfortable edit environment.

[Alan Kilborn]

I attempted to reproduce your problem and I was “sort of” able to do it.

There is no concept of a “hidden” view. Just because you “hide” it by shrinking it to zero size doesn’t give it any special status.

What happens when you double click on a search result is that the correct file is activated in the primary view (the one that you seem to have “hidden”). This just happens to be the way it works with a cloned file–the double-click activates the owning file’s tab in the primary view and jumps the caret to the match. You’ll see this, if after activating the match you “unhide” the upper (primary) view and check to verify what file and line number it is at.

[Alan Kilborn]

Perhaps this could be a new feature request:

• If the file is not cloned, and the view the match is in is fully collapsed, uncollapse it (to a 50-50 split?) to show the tab of the source of the match

• If the file is cloned, and the primary view is collapsed, use the secondary view’s tab when going to the source line for the match (otherwise prefer showing the match in the primary view)

[W TX]

@Alan-Kilborn said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

There is no concept of a “hidden” view. Just because you “hide” it by shrinking it to zero size doesn’t give it any special status.

What I suggested is to give the mode of 2 view panes a special bit View_Mode in code design: 0: there is only one main pane; ‘1’: both panes are visible.

Now we don’ have to talk about the property: if a file has the primary view or the secondary view.
It is a new concept, making the dual-pane scheme much more user-friendly.

1. When starting, View_Mode = 0, showing only one pane.
2. When a user introduces a second view, the main pane is split into two panes, the top one and the bottom one, and View_Mode is set to 1. If a user shrinks any of the 2 panes, the View_Mode becomes 0.
3. Now new rules apply: regardless of where a file item is clicked, either is at the document list pane or the search result pane, if View_Mode = 0, the file content is shown in the main pane; if View_Mode = 1 the clicked file is displayed at one of the two-panes that is decided when it is opened.

The reason is users spend their most time in one window mode and if there is any need, they need to show 2 panes, especially for comparing.

It mimics the “Compare” function: when a comparison of 2 files is required, it automatically introduces 2 visible panes, the first selected one is at the top, the second selected file is at the button. After the comparison is finished it returns to the original status.

[Alan Kilborn]

@W-TX

I’d rather not tell the developers how to do their job, at that level. Plus, well, I don’t know, but I find your wording hard to read and follow.

[W TX]

@Alan-Kilborn said in (Document list + Find + Multiple files + at least 1 file in dual show) bug::

I attempted to reproduce your problem and I was “sort of” able to do it.

1. Could you please post the snapshots You repeated the bug, and describe how they are made, so more people can repeat the error and understand under what conditions the bug happens.

2. Could you please post the bug to the appropriate website to let NP++ developers know about the bug. I posted the bug here, hope someone can repeat the bug and report the bug upperward. As a heavy user of the NP++, spending almost 8 hours a day using the NP++, my duty is to report here any types of bugs and suggestions to make NP++ more user-friendly.

3. My improvement suggestion in 1 sentence:
   After a user collapses one pane of 2 visible content panes, there will be only one maximized window, showing any file a user most recently clicked, regardless of the position the new clicked file belongs to. Show 2 panes only when a user moves pane separation bar to let both panes visible,

[artie-finkelstein]

Alternate suggestion (somewhat alluded to by a previous response by Alan Kilborn):

Don’t move the vertical separator bar so that one of the views is fully obscured, leave at least one text line visible. The obscured pane is only hidden from the user, not from the editor. When a user makes the pane effectively invisible, what they are really doing is saying don’t show me the contents, so when the editor changes the contents (scrolls the file to display the match) the user can’t see what is going on.

This may not affect the purported bug, but it should at least make it easier to see what is going on. I do note that the Find All in All Opened Documents option will resize the document views to allow space for the Search results window and this may require appropriate resizing of all three panes.