Hey, a Debian user reported (http://bugs.debian.org/626563) that some backup files (like ending with ~, emacs style) weren't hidden anymore. Regards, -- Yves-Alexis
Hi Yves-Alexis, Indeed, since the port to GIO the code simply uses the following function call: g_file_info_get_is_hidden() Before that it did something custom through a thunar-vfs function call. There used to be an open bug with a will to not hide the files ending with ~ and was marked as resolved because of the gio switch. https://bugzilla.xfce.org/show_bug.cgi?id=6871 I'm not touching the resolution of this bug, I actually believe it might be wise to hide files ending with ~ or .bak or whatever. Cheers Mike
The comment about the default behavior beeing the same as ls makes sense, though
So backup files need to be hidden as well? Is that what the pre-gio thunar did? If so we can simply patch thunar like below: gboolean thunar_file_is_hidden (const ThunarFile *file) { _thunar_return_val_if_fail (THUNAR_IS_FILE (file), FALSE); if (file->info == NULL) return FALSE; return g_file_info_get_is_hidden (file->info) || g_file_info_get_is_backup (file->info); }
(In reply to comment #3) > So backup files need to be hidden as well? Is that what the pre-gio thunar did? > If so we can simply patch thunar like below: > > gboolean > thunar_file_is_hidden (const ThunarFile *file) > { > _thunar_return_val_if_fail (THUNAR_IS_FILE (file), FALSE); > > if (file->info == NULL) > return FALSE; > > return g_file_info_get_is_hidden (file->info) > || g_file_info_get_is_backup (file->info); > } That looks nice, it'd fit my bug reporter, but the reporter of #6871 would be sad. I'm not too sure what to think (I guess it's a matter of preference). As I don't personnaly use emacs, I don't have ~/~~ files cluttering my hard drive so it doesn't really matter to me, but using the ls behavior makes some sense to me.
Yep, I think thunar-vfs assumed files ending with '~' are hidden, see: http://git.xfce.org/xfce/thunar-vfs/tree/thunar-vfs/thunar-vfs-io-local.c#n303 I have applied the fix suggested by Nick to master and to the xfce-4.8 branch. It might be smart to add a hidden option for disabling this behavior though. But for now, back to the old behavior it is: commit bb227bfe0d761476fbd8d72fa51afaeaffa10715 Author: Jannis Pohlmann <jannis@xfce.org> Date: Fri May 20 02:05:06 2011 +0200 Treat backup files as hidden, as with thunar-vfs (bug #7615).
Grrrr.... I'm one of the reporters who disagreed with this stupid behaviour (that is, hiding backup files). Comment #2: > The comment about the default behavior beeing the same as ls makes sense, though Makes sense, yes. But has anyone actually tested and verified this? On my system, ls *DOES* show backup files (ending with ~), and it only hides dot files. That's on gentoo, with no modifications made, simply plain /bin/ls. As it does on Red Hat Enterprise Linux. If debian devs patch their ls (though I doubt they do) this way, they should patch thunar too, not create a mess for other distributions. Another option: Choose an editor which doesn't spam all directories with backup files. vim or emacs, for a start. Or send a bug report to the editor's developer to get rid of this behaviour. > That looks nice, it'd fit my bug reporter, but the reporter of #6871 would be sad. I'm not too sure what to think (I guess it's a matter of preference). Very sad indeed. But I'm not the only one annoyed by the old behaviour; See old bug reports for proof. > I have applied the fix suggested by Nick to master and to the xfce-4.8 branch. > It might be smart to add a hidden option for disabling this behavior though. It would be the big salvation. How about a simple option in preferences "Treat backup files as hidden", or more clearly, "Treat files ending with ~ as hidden" (and I'd vote for default off). Please forgive me my sarcastic undertone. But I do not create backup files because I don't want to see them. They are important (hence backup) and should not go unnoticed.
(In reply to comment #6) > Comment #2: > > The comment about the default behavior beeing the same as ls makes sense, > though > > Makes sense, yes. But has anyone actually tested and verified this? On my > system, ls *DOES* show backup files (ending with ~), and it only hides dot > files. If we had opted for doing whatever 'ls' does, our file managers would look a lot different. > If debian devs patch their ls (though I doubt they do) this way, they should > patch thunar too, not create a mess for other distributions. This is not about Debian, it's about Thunar only. Let's try to avoid side blows here. > Another option: Choose an editor which doesn't spam all directories with backup > files. vim or emacs, for a start. Or send a bug report to the editor's > developer to get rid of this behaviour. VIM does right in creating hidden auto-save files. This debate is not about how we think text editors should behave. That clearly is beyond our scope of control. > > I have applied the fix suggested by Nick to master and to the xfce-4.8 branch. > > It might be smart to add a hidden option for disabling this behavior though. > > It would be the big salvation. How about a simple option in preferences "Treat > backup files as hidden", or more clearly, "Treat files ending with ~ as hidden" > (and I'd vote for default off). We have been very strict on what options to add to the Thunar preferences dialog. This is my personal assumption but I'm confident that the majority of people would never touch this option. This is reason enough for me not to show it. > Please forgive me my sarcastic undertone. But I do not create backup files > because I don't want to see them. They are important (hence backup) and should > not go unnoticed. We don't want temporary files created by applications solely for internal reasons to be visible to our users. This includes emacs-style auto-save files used to avoid data loss. If you happen to create backup files using the same naming scheme as emacs does then it might be worth looking for an alternative format (why not use a '-' or '.backup' suffix?). Or, even better, version your critical files properly using something like SparkleShare or command line tools like git. I guess I'm not telling you news by mentioning that backup files located in the same folder on the same partition are a very poor backup anyway. (I know these suggestions may sound arrogant but they aren't meant to be.) This bug remains resolved. We restored the old behavior which was lost during the migration to GIO.
(In reply to comment #6) > Grrrr.... I'm one of the reporters who disagreed with this stupid behaviour > (that is, hiding backup files). > > Comment #2: > > The comment about the default behavior beeing the same as ls makes sense, > though > > Makes sense, yes. But has anyone actually tested and verified this? On my > system, ls *DOES* show backup files (ending with ~), and it only hides dot > files. That's on gentoo, with no modifications made, simply plain /bin/ls. As > it does on Red Hat Enterprise Linux. > > If debian devs patch their ls (though I doubt they do) this way, they should > patch thunar too, not create a mess for other distributions. Please, read what I wrote before commenting like this. There's no such patch against ls in Debian, ls *does* show tilde files. When I wrote that the ls behavior made sense, it was the behavior to *show* the tilde file. So your whole comment is based on a false premise, on top of beeing a bit rude. > > Please forgive me my sarcastic undertone. But I do not create backup files > because I don't want to see them. They are important (hence backup) and should > not go unnoticed. Your sarcasms could be forgiven if it wasn't completely counter-productive and based on false interpretation on your part. Regards,
> If we had opted for doing whatever 'ls' does, our file managers would look > a lot different. Not much. Basically, I find ls' default output is very minimalistic and concise, yet useful, and the filemanager doesn't show much more, actually it sometimes shows less information. > This is not about Debian, it's about Thunar only. Let's try to avoid side > blows here. I apologize. The side blow to Debian was due to wrong premises about what I assumed had been said about ls output and was not intentional (read 'though I doubt it'). > This debate is not about how we think text editors should behave. > That clearly is beyond our scope of control. Someone did not like that the editor spammed the directory with backup files. Although out of scope, that's one of his arguments, so I brought it up again. > We have been very strict on what options to add to the Thunar > preferences dialog. Which is a good thing I like, as it keeps it simple and tidy. > This is my personal assumption but I'm confident that the majority > of people would never touch this option. This is reason enough for me > not to show it. If you ask someone, "Would you like to hide your backup files?", then I'm quite curious about the answer. I would like the aforementioned option, and others too, and that's reason enough for me for fighting for it. > We don't want temporary files created by applications solely for > internal reasons to be visible to our users. This includes emacs-style > auto-save files used to avoid data loss. I think now you mix it up. I do not complain about the autosave files, this must have been another user. In fact, all my editor's backup files are nicely being saved in a separate backup directory. And do they not start with dots, so they are being hidden anyway? I'm complaining what happens when you make a backup copy of, for example, your mail folder: cp -a mails mails~ I do not do this very often, so why should I want to hide it? (That reminds me that I do not like that naming convention of 'copy of folder xxx' too, as it makes renaming more difficult and in most cases requires navigation.) > I know these suggestions may sound arrogant but they aren't meant to be. I don't mind. They are irrelevant and off-topic anyway. > This bug remains resolved. We restored the old behavior which was lost > during the migration to GIO. Which was gladly lost during the migration to GIO. Actually, someone fixed it due to the migration, albeit without any intention to do so. Then you declared it fixed and everyone - except the one who reported this bug - seemed happy (not that I want to insult the reporter, I can understand why he wants to hide the backup files, and he even asked for an option in thunarrc). Now, you reintroduce the old behaviour without providing an opt-out for those who would like to change it. Some people seem to like it this way, some like it the other way. How do other major file managers solve this (nautilus, dolphin, korganizer)? It was only fixed because that is the way it worked before, even though (some) people complained. In this case, I think the right idea would be to introduce an option. Please, add an option in the gtk interface or thunarrc where one can decide what fits him best. > Your sarcasms could be forgiven if it wasn't completely counter-productive > and based on false interpretation on your part. I stand corrected and apologize. I only meant to be extremely sarcastic, not rude. I was annoyed that this thing has been changed again. Let me rephrase: I can happily revert this change for myself. However, others might not, and I think it would be more advantageous if we had an option to choose. As it is currently the case, there are more people complaining that backup files are being hidden by default than there are people complaining that they are not. So I'd go for the default behaviour being not to hide them, though the bug reporter might come and kill me for it.
(In reply to comment #9) > > This is my personal assumption but I'm confident that the majority > > of people would never touch this option. This is reason enough for me > > not to show it. > > If you ask someone, "Would you like to hide your backup files?", then I'm quite > curious about the answer. I would like the aforementioned option, and others > too, and that's reason enough for me for fighting for it. The only question I am concerned with is "Would you like to hide internal files created by your text editor?" (Note that some people don't even know which editor they use which makes it even more important to hide all the "crap" they don't need to know about.) The question is "Would you like to hide your backup files?" for you because your backup naming scheme conflicts with that of Emacs (and, apparently, a number of other text editors). Please understand that hiding auto-generated stuff from applications has a higher priority than the personal preference of individuals; in particular so as the naming scheme for auto-generated backups seems to have been adopted by other editors than just Emacs. > I'm complaining what happens when you make a backup copy of, for example, your > mail folder: cp -a mails mails~ Suggestion: Use "cp -a mails mails-" instead. > > I know these suggestions may sound arrogant but they aren't meant to be. > > I don't mind. They are irrelevant and off-topic anyway. Nice one. You certainly know how to communicate in a respectful manner, don't you? > Now, you > reintroduce the old behaviour without providing an opt-out for those who would > like to change it. Personal opinions aside, an accidental change in behavior is one thing mainly: a regression. Your perspective on the bug-fixing process is a projection of how you would like things to be seen and done. As far as I'm concerned, this case is closed.
> Please understand that hiding auto-generated stuff from applications has a > higher priority than the personal preference of individuals; in particular > so as the naming scheme for auto-generated backups seems to have been > adopted by other editors than just Emacs. I do not deny that crap should be hidden; The problem is that thunar won't let me decide what is crap and what not. So this is a case of "Machine tells me how I should behave". Sorry, but I'm a strong believer of "Human tells the machine what to do." You know what's so great about emacs? It is configurable. You can tell it: Do not create backup files, or use a special directory to store the backups. No harm done. Granted, emacs is a bit overkill for normal users. But other, more easy-to-use editors can be configured like this too. Thunar currently does not let you do this. It enforces standard behaviour on the user. This is something which I would like to see changed, and I'm quite confident others share this opinion. In fact, this is quite a controversial topic, as you can see here: https://bugs.kde.org/show_bug.cgi?id=3212 Would the regexp filter approach not be a viable solution? > Personal opinions aside, an accidental change in behavior is one thing > mainly: a regression. Your perspective on the bug-fixing process is a > projection of how you would like things to be seen and done. I agree on this. You're right, this bug report is about a regression, not a place for discussions. If you're interested, we could take this to the appropriate xfce discussion list.
(In reply to comment #11) > > Please understand that hiding auto-generated stuff from applications has a > > higher priority than the personal preference of individuals; in particular > > so as the naming scheme for auto-generated backups seems to have been > > adopted by other editors than just Emacs. > > I do not deny that crap should be hidden; The problem is that thunar won't let > me decide what is crap and what not. So this is a case of "Machine tells me how > I should behave". Sorry, but I'm a strong believer of "Human tells the machine > what to do." Then your idea of how a computer-based system works conflicts with the design philosophy behind Thunar. You are right, Thunar won't let you decide a about a lot of things. Its concept differs a lot from that of Emacs and other configure-heavy applications. There are a number of issues that I would consider much more controversial, like tabs or split-screen directory views. With Thunar, we follow a minimalist approach and we offer our vision of file management to the world. You are free to disagree and use something else or propose changes. However, most of the proposals we receive are rejected and there's nothing personal in that. It's in the nature of keeping things simple. (Besides, who wants to maintain code that consists 50% out of handling different configuration options?) (BTW, compared to other desktops, Xfce is quite configurable; Thunar is a bit of an exception but that's within the vision of its original author, Benny, and we stick to it.) > In fact, this is quite a controversial topic, as you can see here: > https://bugs.kde.org/show_bug.cgi?id=3212 > Would the regexp filter approach not be a viable solution? With me talking about simplicity and stuff you can probably imagine my answer. ;)