Search History improvement (seems like a bug too)

[nikov]

Hi,
I just noticed search history cannot be sorted based on incrementing serial value.

What I mean:
Search History's "Date searched" sorting's primary intention is to show the search history with the most recent searches first.
This purpose is way better served if the sorting is based on incrementing serial value instead of system clock's value.
Because system clock can be unstable or unpredictable. It can easily deviate by software/hardware error.
Thus, using system clock's value to sort for recent searches may not always bring the most recent searches first.
Associating an incrementing serial value with every search and then sorting by that serial is a more stable way to bring the most recent searches first.

The "Last Search Date" data can be kept as this provides more search information.

Everything's "Recent File List" does not suffer with this problem. And many programs implement recent item list in this way.

Thank you for your consideration.

[NotNull]

The Last Search Date is internally stored as a FILETIME (number of 100 nanoseconds ticks since 1601) and just shown in a "human-friendly format".
The FILETIME is used for the sorting. And I doubt that anyone is able to enter multiple searches withing 100 nanoseconds

To verify, check Search History-1.5a.csv or Search History.csv in the Everything profile folder (most likely the %appdata%\Everything folder). Entries will look like:

Code: Select all

Search,Search Count,Last Search Date
"ext:exe",2,133438676009038973
"nopath:exact:notepad.exe",1,133438666512506316

[nikov]

The Last Search Date is internally stored as a FILETIME (number of 100 nanoseconds ticks since 1601) and just shown in a "human-friendly format".
The FILETIME is used for the sorting. And I doubt that anyone is able to enter multiple searches withing 100 nanoseconds

To verify, check Search History-1.5a.csv or Search History.csv in the Everything profile folder (most likely the %appdata%\Everything folder). Entries will look like:

Code: Select all

Search,Search Count,Last Search Date
"ext:exe",2,133438676009038973
"nopath:exact:notepad.exe",1,133438666512506316

Thank you NotNull,

I didn't mean about precision of 100 nanoseconds.
It doesn't matter even if the ticks are as short as Planck time .

System clock time can drastically deviate as far as even in the range of hours and days for many reasons.
Such as, battery over discharge/corrupt, operating system error, incorrect time synchronization, hardware corrupt, etc.
These are not even rare events. These things happen.
Compared to this, sorting based on incrementing serial value is way stable.

I hope now you understand what I tried to mean.

Thank you.

[NotNull]

Right, missed that completely!


Might be technically more challenging to implement than sequential "events".
For example (simplified)
Search ID# date
----------------------------------------------
a 1 00:01
b 2 00:02
c 3 00:03
d 4 00:04
e 5 00:05


Now at 00:06, search for "d" again. What should the new list look like?

[NotNull]

Right, missed that completely!


Might be technically more challenging to implement than sequential "events".
For example (simplified)

Code: Select all

Search	ID#	date
-----------------------
a	1	00:01
b	2	00:02
c	3	00:03
d	4	00:04
e	5	00:05

Now at 00:06, search for "d" again. What should the new list look like?

[nikov]

Thanks NotNull, but I also added the Count column to make it similar to the Search History file:

At 00:06, if "d" is searched again then I guess the new list should look like:

Code: Select all

Search	#ID	Count	date
-------------------------------
a	1	1	00:01
b	2	1	00:02
c	3	1	00:03
d	6	2	00:06
e	5	1	00:05

Suppose, then, for some reasons at 00:07, clock alters to 00:04 then searching for "d" again would yield I guess:

Code: Select all

Search	#ID	Count	date
-------------------------------
a	1	1	00:01
b	2	1	00:02
c	3	1	00:03
d	7	3	00:04
e	5	1	00:05

Then sorting by "ID#" would suggest to user:

Code: Select all

d
e
c
b
a

Which is intended. Because "d" is the most recent search.
On the other hand, if it was sorted by "date" then it would suggest to user:

Code: Select all

e
d
c
b
a

This is not intended. Because "e" is not the most recent search. "d" is the most recent search.

[void]

I will consider a serial number to sort search history.

Thank you for the suggestion.

For now, Everything will assume the system clock is stable.

[nikov]

Thank you void,
And also you may consider this for "Run History" and other similar features if they exist as well.
But I think for now, Search History is the most important because users will most likely click the drop down button on the search edit and expect a sorted by recent list by seeing its use case/format, at least I find it more useful.

Thank you.