GNOME Bugzilla – Bug 756258
gedit takes a long time to open if ~/.local/share/recently-used.xbel is huge
Last modified: 2015-12-01 07:31:27 UTC
Gedit takes a long time to open if ~/.local/share/recently-used.xbel is huge. It took me a while to figure thiso ut but I eventually figured I would delete ~/.local/share/recently-used.xbel and now gedit opens quickly again. Since this file will eventually grow again, a more permanent solution would be much nicer. Thank you. This happens even when I type 'gedit' in a terminal without opening a file. The lag however is somewhat longer if I am actually opening a file.
I may have an idea what is going on here. The Recent section in open dialog shows everything even non-plain text files. evince for example shows only supported files (pdf, etc...) so it doesn't suffer from this.
Thanks for the bug report. It's probably a fallout of the changes in the OpenDocumentSelector.
hi, can you confirm the version because you tag the bug as a 3.18.x prob and i don't see any files in the recent list other than excepted at least in this version. the OpenDocumentSelector use gedit recent module criteria to filter items so that we only show text/plain mime types already opened by gedit : https://git.gnome.org/browse/gedit/tree/gedit/gedit-recent.c#n161
There is a confirmation in archlinux forums that 3.16.3 is fast and 3.18 is laggy. I also tested 3.16.4 and same lag. https://bbs.archlinux.org/viewtopic.php?id=203594
Apparently it also happens when URLs to remote servers are present in the recently used files.
Created attachment 314101 [details] [review] recent: fix mime and app filters Currently, the OpenDocumentSelector show recent files that are either text/plain mime type or already opened by Gedit. As we don't filter remote files, it lead to a delay when fetching recents wich are both remote and plain text mime type files. We need to filter all recents that are not both text/plain AND already opened by Gedit.
Review of attachment 314101 [details] [review]: This does not seem correct to me, but it is late so I may be a bit confused... 1) if a file is not text plain but was opened before in gedit, we definitely want to be able to find it again, while with your patch it would be filtered out because (!text/plain || app!=gedit) -> (!FALSE || FALSE) -> (TRUE || FALSE) -> (TRUE). As a matter of fact I think the sentence "Currently, the OpenDocumentSelector show recent files that are either text/plain mime type or already opened by Gedit" correctly describes the desired behavior. 2) whatever the filtering is, it seems to me that it is orthogonal to the fact of being slow due to fetching remote files: we could have plenty "text/plain" files opened via ssh with gedit in the recent files and it would be slow anyway
Created attachment 314163 [details] [review] OpenDocumentSelector: fix fetching of recents Previously we were querying each files for a precise access time but this is slow with remote ones. Let just gets the time from the recent manager ( sec precision vs msec ) We also now show remote files in the selector.
Attachment 314163 [details] pushed as ce9b516 - OpenDocumentSelector: fix fetching of recents
*** Bug 757343 has been marked as a duplicate of this bug. ***
*** Bug 756711 has been marked as a duplicate of this bug. ***