Search-results output has unconventional subfolder ordering

[alankilborn]

Search-results output has unconventional subfolder ordering

[pryrt]

With the first example, I was thinking it had just been a depth-first search, which makes sense algorithmically, though isn't what everyone is expecting. But with that second, it's obviously not depth-first, and does appear to be purely alphabetical.

I think displaying them alphabetical-by-file in a given layer, followed by alphabetical by subdirectory from that level would make the most sense to a user. And that's what Alan's "expected results" indicate, so I guess I'm saying "I agree, that would be best" ;-)

[alankilborn]

I think it is merely an effect from the recursion used, without further treatment.
This often happens with "simple" recursion algorithms.
As soon as a directory is detected, it is diven into, and this keeps happening as files and dirs are processed at that lower level, and successive lower levels, abandoning remaining files at one level as soon as a deeper directory is discovered.

For example, following the dir0\a.txt file, directory after directory (and their files) are encountered and processed, leaving dir0\t.txt as the last thing processed (all the recursive/directory processing has been completed).

A better algorithm would be to build a list of all of the directories, in depth-order, first. Then start searching those directories for files. I don't think any sorting needs to occur, as the natural order (as returned by FindFirstFile/FindNextFile seems sufficient). I believe that following this scheme would produce my expected output.

[alexprabhat99]

@alankilborn Could you please check out my PR #14899 which attempts to order search results output as is expected in this issue. This is my first attempt at contributing to any open source project. Your feedback would certainly help me improve. Thanks in advance!

[donho]

The existing Find in Files algorithm, while not flawless, effectively performs its task iteratively and recursively, ensuring that no files remain unsearched. However, altering this non-buggy algorithm could potentially introduce regressions.

While I consider this feature desirable, the associated risk of regression is not acceptable. Therefore, I stand by my rejection, and I hope my reasoning is clear.

[alankilborn]

@donho

---

While I consider this feature desirable

That's good, we have agreement.

---

the associated risk of regression is not acceptable

Can't we just prove that a feature's implementation doesn't create a regression, and then it can be accepted?
Note that I haven't looked at or tested the implementation in #14899, I'm just speaking generally here.

[donho]

@alankilborn

Can't we just prove that a feature's implementation doesn't create a regression, and then it can be accepted?
Note that I haven't looked at or tested the implementation in #14899, I'm just speaking generally here.

That’s a good question, and the criteria are indeed not obvious. In general, a completely new feature is more likely to be accepted (provided it’s a good feature, and, of course, judged by me). Alternatively, a behavior change involving a small amount of code is preferable because it has less impact on the current behavior of the application.

Regarding this feature request, even if the impact could be significant, if there were a large number of people who needed such behavior, it would likely be accepted. However, in this case, I prefer that either I or the devs I trust handle the change.

This list could give you a general idea for which kind of feature request will be accepted:
https://github.com/notepad-plus-plus/notepad-plus-plus/pulls?q=is%3Apr+is%3Aclosed

[alankilborn]

if there were a large number of people who needed such behavior

This one isn't a "need", it is more of a "this new way would be nicer". But that seems equally as valid.

---

I prefer that either I or the devs I trust handle the change.

How about a "dev you sort-of-trust". Me. :-)
I created this issue, and I was going to code it as well.

But I'd dislike casting aside the coding that's been attempted so far, without even looking at it...that doesn't seem fair to someone that's put their effort in. I'll take a look at the code that's been done...

[donho]

How about a "dev you sort-of-trust". Me. :-)
I created this issue, and I was going to code it as well.

It seems to me that this pre-condition is not fullfilled:

Regarding this feature request, even if the impact could be significant, if there were a large number of people who needed such behavior

[alankilborn]

if there were a large number of people who needed such behavior

Probably a decent number of people have observed a mess such as this:

Then thought: "WTF kind of ridiculous output ordering is this?" ...shrugged... and thought: "Well, at least it did the search." ...and moved on...

You've always been big on "let's see if a large number of users want this ... or complain about that..."
IMO that's a cop out for a feature you don't really want, even though things like this are said: "while I consider this feature desirable..."

You should be listening to the smaller group of users that care about making things better, e.g. comment contributors on this thread. Then the larger user group benefits, without having to put the effort into complaining (which they won't do, because they're interested only in getting their text-editing job done, not making a better thing).

[alankilborn]

Poll taken about how users feel: https://community.notepad-plus-plus.org/topic/25634