@radehi filetags has many little ideas built-in 😉
@publicvoit too bad there isn't a thesis about it to explain them to me
or...?
@radehi And many nice features are almost invisible to the user. E.g. when you're tagging within a TagTree structure and the original file gets renamed accordingly also with https://github.com/novoid/appendfilename/
filetags incorporates everything I've learned from the tagstore project and is used on a daily basis by me since a decade or so. And so it grew by eating my own dogfood.
@publicvoit It doesn't offer any alternative to renaming the files, does it? Although apparently it works for you, there's no way I'd try out a tagging system that renamed my files, even if it didn't insert spaces into the names. *Spaces*!
Spaces are not the *worst* possible thing to have in a filename; newlines would be worse.
But spaces do break make and most shell scripts, and renaming files breaks almost any references to the files anywhere else: `<a href="">`, `<img src="">`, hypertext links from org-mode files, `#include`, full-text search databases, symlinks, Emacs buffers currently editing the file, lines in my command-line history that do things with the file, `diff -r`, *everything*. The only exceptions are hardlinks (or reflinks) and that Git can usually track files successfully across renames. Renaming files is the opposite extreme from being "almost invisible to the user" if the user is someone like me.
So, although filetags looks like an interesting project with some potential UI advances, the chances that I'll try it if it insists on renaming my files are very, very small.
@radehi filetags is using filenames only, yes.
@radehi
In the last decade, I gave up my personal distaste for #spaces and special characters in file names.
Never regrettet it.
Never had any issue, not in my zsh nor in #shellscripts which I'm using. If there is an issue, it's usually the issue of the script & is easily fixed. Therefore, I try to come up with clean code rather than avoiding side effects of code bugs by omitting spaces and special characters in my file names. After all, the computer is here for me and not vice versa.
YMMV.
@publicvoit Yes, of course it's a bug in the shell script when it fails to handle spaces in filenames. I try hard not to include that bug in my own shell scripts. But I probably fail sometimes because the shell is just a ridiculously bug-prone programming language.
In `make`, though, there's just no way around it.
Yes, I could write a `make` replacement and a shell replacement that don't have these problems. But they will have they own problems, and they will take ten years before they're as good as the existing system, even with current high-level languages and the benefit of hindsight.
I'd prefer to spend those ten years making something new, building on what others have already built, rather than replacing it with clean code.
@publicvoit The renaming thing is a bigger obstacle to the diffusion of your innovations, though, at least to people like me. And, like the spaces thing, it's also a question of compatibility (in Rogers's term; as opposed to, for example, relative advantage). It's more or less the same thing as importing the files into SQLite as blobs. Except then you could still provide a compatible filesystem interface to them (say, through FUSE) that didn't change the filename every time you added or removed a tag; have you thought about doing that?
@radehi I do have multiple workflows in place where I do link the file independent of its location in the hierarchy as well as independent of its exact file name. When there is no hit, my tools do try to locate the (renamed) file via its unique start of the file name. Works perfectly fine on my side. Would never ever go back with absolute/relative paths and "exactly or lost"-approach. YMMV.
@radehi Nope. Just the readme file and maybe a little bit of practice.