Disabled intentionally.  Bug 418520.

(In reply to comment #1)
> Disabled intentionally.  Bug 418520.

As in permanently because it's expected behaviour that you cannot expunge messages in a search folder?  If so, with all due respect I think that's silly.  One certainly used to be able to do that.

IMHO, search folders are not somewhere you (or I at least) only visit occasionally to get some non-oft-used view of e-mail but rather where I do all of my e-mail work in.  When I create search folders that include my inbox and any other folders that I receive mail in, that's the folder I go to and work in as my main workflow with e-mail, all day long, every day.

I don't want to have to visit the many folders that might be comprising a search folder to individually expunge them every time I have deleted some mail from my search folder.

I find the justification in bug 41820 difficult to believe.  Is it really expected that once users have created a search folder that contains their other real folders, and that when they delete and expunge from the search folder that they don't realize that it removes the messages in the real folders?

And so instead of educating those users, we just remove this feature for all of the other users that use and enjoy it?  Maybe the first-time expunge in a search folder should pop up a "do you realize..." warning or something.  Or maybe have expunging in search folders (or all vfolders perhaps) enabled by some unexposed gsettings (or whatever is being used these days) flag.

But just removing such a feature for everyone that isn't entirely naïve seems not-so-nice.

Reopened by request of mcrha.

mcrha has graciously agreed to put this on his ToDo list.

Many many thanks!

As mentioned on IRC, add a secret option to enable expunge in vfolders for advanced users whom understand that such expunge can cause message delete from all folders being part of the vfolder where the expunge was called.

I cannot commit to stable (3.12) due to new translatable strings being added (in GSettings files).

Created commit d7be145 in evo master (3.13.8+) [1]

[1] https://git.gnome.org/browse/evolution/commit/?id=d7be145

(In reply to comment #6)
> I cannot commit to stable (3.12) due to new translatable strings being added
> (in GSettings files).

Good thing I have a Copr then.  :-)
 
> Created commit d7be145 in evo master (3.13.8+) [1]
> 
> [1] https://git.gnome.org/browse/evolution/commit/?id=d7be145

I tried applying this to stable but this hunk:

@@ -761,6 +762,13 @@ e_mail_shell_view_private_constructed (EMailShellView *mail_shell_view)
 		G_BINDING_BIDIRECTIONAL |
 		G_BINDING_SYNC_CREATE);
 
+	settings = e_util_ref_settings ("org.gnome.evolution.mail");
+	g_settings_bind (
+		settings, "vfolder-allow-expunge",
+		mail_shell_view, "vfolder-allow-expunge",
+		G_SETTINGS_BIND_GET);
+	g_clear_object (&settings);
+
 	/* Populate built-in rules for search entry popup menu.
 	 * Keep the assertions, please.  If the conditions aren't
 	 * met we're going to crash anyway, just more mysteriously. */

produced this compile error:

e-mail-shell-view-private.c: In function 'e_mail_shell_view_private_constructed':
e-mail-shell-view-private.c:766:2: error: implicit declaration of function 'e_util_ref_settings' [-Werror=implicit-function-declaration]
  settings = e_util_ref_settings ("org.gnome.evolution.mail");
  ^
e-mail-shell-view-private.c:766:2: warning: nested extern declaration of 'e_util_ref_settings' [-Wnested-externs]
e-mail-shell-view-private.c:766:11: warning: assignment makes pointer from integer without a cast [enabled by default]
  settings = e_util_ref_settings ("org.gnome.evolution.mail");
           ^
cc1: some warnings being treated as errors
make[3]: *** [module_mail_la-e-mail-shell-view-private.lo] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/builddir/build/BUILD/evolution-3.12.8/modules/mail'
make[2]: Leaving directory `/builddir/build/BUILD/evolution-3.12.8/modules'
make[2]: *** [all-recursive] Error 1
make[1]: Leaving directory `/builddir/build/BUILD/evolution-3.12.8'
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2

I simply changed:

+	settings = e_util_ref_settings ("org.gnome.evolution.mail");

to

+	settings = g_settings_new ("org.gnome.evolution.mail");

in the patch.  Is that sufficient?  It builds.  Just not sure if it breaks anything yet.

(In reply to comment #7)
> +    settings = g_settings_new ("org.gnome.evolution.mail");
> 
> in the patch.  Is that sufficient?

Yes, that is sufficient. The missing function was added recently, it's to share GSettings objects, instead of creating many of them (it's like 100 objects after start and entering each view).