GtkFileChooserEntry: regenerate the completions if the dir_part changes
Consider this bug: 1. Open a file chooser; switch it to $HOME 2. Start typing "~/Dow" with some file that *does* exist in your $HOME 3. Delete the inline-completion selection (e.g. the "nloads" after "~/Down"). 4. While you are at "~/Dow_" hit Tab. No completion will occur. This happens because of the following. Say the GtkFileChooserEntry is in the process of loading $HOME, because _set_base_folder() was called. If the entry contains no text, then the FULL_PATH_COLUMN of the file system model will be set to unprefixed filenames from $HOME, like .ssh/ Documents/ Downloads/ somefile.txt Later we avoid reloading the folder if g_file_equal(old_folder, new_folder). However, the FULL_PATH_COLUMN gets populated in completion_store_set() out of the actual filenames that GIO returned, plus the chooser_entry->dir_part. If the user starts typing "~/Dow" then dir_part changes to "~/", *but* the folder won't be reloaded since it is also $HOME. However, the completion machinery assumes that FULL_PATH_COLUMN will contain prefixed entries like ~/.ssh/ ~/Documents/ ~/Downloads/ ~/somefile.txt So, we add an invariant that chooser_entry->dir_part and chooser_entry->current_folder_file must change at the same time, and must not get out of sync: If any of them changes, then the completions are regenerated.
Showing with 30 additions and 18 deletions