After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 698311 - quick open: fails to find files I've opened recently
quick open: fails to find files I've opened recently
Status: RESOLVED FIXED
Product: gedit-plugins
Classification: Other
Component: General
git master
Other Linux
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2013-04-18 15:25 UTC by Adam Dingle
Modified: 2019-03-23 20:35 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Adam Dingle 2013-04-18 15:25:47 UTC
The Quick Open plugin often fails to find files I've opened recently.  A glance at the function RecentDocumentsDirectory.fill in virtualdirs.py reveals a couple of problems:

1. The code sorts recent documents in *ascending* order by time, then grabs the first 10.  So it's actually using the 10 *least* recently visited documents rather than the most recently visited ones.

2. I think the constant maxitems = 10 here is much too small.  I can easily imagine editing dozens of files in a day and then wanting to quickly open one that I last opened the previous day.  At the very least I think we should increase this constant.  A better solution would be to include all recent documents in this virtual folder, but then to limit the number of search results displayed to 10 or so in the view layer.  That way I could have hundreds of recent documents but still be able to recall any one of them by typing a few characters of its name.
Comment 1 Ignacio Casal Quinteiro (nacho) 2013-04-19 21:23:17 UTC
Fixed point 1
Comment 2 Ignacio Casal Quinteiro (nacho) 2013-04-19 21:38:50 UTC
About 2, the main problem is that right now quickopen is not async. This is something that we discussed some time ago but we really didn't have to implement. :(
Comment 3 Adam Dingle 2013-04-19 22:21:50 UTC
I still bet we could increase the maxitems constant a lot without any noticeable lag.  If we increase it to, say, 200, that might be good enough for now and we could always add asynchronous support later.
Comment 4 Adam Dingle 2013-04-19 22:33:54 UTC
Unfortunately the recent change cac267a7 does not fix point 1:

-         items.sort(key=lambda a: a.get_visited())
+        items.sort(key=lambda a: - a.get_visited(), reverse=True)

Changing "a.get_visited()" to "- a.get_visited()" reverses the sort order, but reverse=True reverses it again, so in the end the order is unchanged.
Comment 5 Ignacio Casal Quinteiro (nacho) 2013-04-20 07:50:24 UTC
urgh... forgot to remove the "-"
Comment 6 Ignacio Casal Quinteiro (nacho) 2013-04-20 07:52:39 UTC
Pushed the new fix, thanks for pointing it.
Comment 7 Ignacio Casal Quinteiro (nacho) 2013-04-20 07:56:13 UTC
200 seems fair enough. Probably we should close this bug and open another to make quickopen async.
Comment 8 Adam Dingle 2013-04-20 07:57:47 UTC
Sounds reasonable to me.
Comment 9 Ignacio Casal Quinteiro (nacho) 2013-04-20 13:36:24 UTC
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.