File extension flexibility

[ransome1]

Discussed in https://github.com/ransome1/sleek/discussions/512

^{Originally posted by **thejevans** August 30, 2023} I've been using sleek for a while now, and I love it. Would it be possible to either allow users to try to load any non-registered file type as if it was a todo.txt file, or to give an option to allow users to register other file extensions as todo.txt files? ## Context I recently started using Obsidian as a general note taking system, and there is a todo.txt plugin for it that works pretty well, but it doesn't have a lot of the features that sleek has that make todo.txt a really nice todo system. The advantages of using the Obsidian plugin that makes me want to use it in addition to sleek are that it is by far the best way I've found to interact with todo.txt on my phone, and I share some obsidian vaults with my partner, so it's a great way to share my todo.txt with them. The disadvantage is that the way the plugin system works for Obsidian is that plugins need to register file extensions that they are designed to work for, and are unable to do any regex on the file names themselves. This led the developer of the plugin to require todo.txt files to instead have .todotxt extensions. They have an experimental option to allow users to register other file extensions, but if I choose to register .txt files, then all .txt files will be rendered as todo.txt files when I open them in Obsidian, which is not ideal. My current workflow is to make hardlinks on my PCs like this `~/todotxt/todo-.txt` -> `~/obsidian//.todotxt`, which works, but is a bit annoying and kind of hacky. Given that sleek's whole thing is todo.txt files, I don't see a downside to adding this feature other than if it's difficult to implement. Thoughts?

[ransome1]

Hey @thejevans. I converted the discussion into an issue, so that it pops up on the project's board.

This functionality should now be available in the latest developer preview: https://github.com/ransome1/sleek/releases/tag/v2.0.0-dev8

There is now a setting, which allows you to feed any file type into sleek. Feel free to give it a try and let me know if it works.

[thejevans]

@ransome1 It works great!

[ludrol]

I tested 2.0.0-dev8.deb on ubuntu 23.04 with kernel 6.3.7 and it doesn't work. When I toggle on the setting I can't open any file even .txt. In default file selector I can't see any files, only directories. The file selector window still asks for "text files". If you want some specific debugging info ask away. Should I open a new bug report?

edit: rant: yarn is not TS package manager on linux it is own tool that does it's own legacy things. please note this in readme section of building from source

[ransome1]

I didn't check it on Linux, only on MacOS. @thejevans since it is working for you; On what OS are you on?

[ludrol]

This is quick and dirty fix. I think there shouldn't be a variable that enables the unsafe behavior. But that comes from a perspective as a linux user.

[ransome1]

Thanks @ludrol. What is it that makes it unsafe either generally or on a Linux system?

The other issue is that .todotxt is an edge case. There might be not another user besides @thejevans who will ever use it. I'm not happy with adding it to the code. What if somebody else needs for example .todo as an extension?

As the allowed file extensions are a comma separated list, we could also put this list to the config file as a setting: allowedFileExtensions: ['txt']. If somebody really needs some other extension than .txt, he or she could just edit the config file.

Thoughts?

[ludrol]

Unsafe

Not unsafe but enables stupid behaviour for the user. For example enables to open binary files where binary files shouldn't be opened. I trust user more and they should be to blame for their stupidity, but that's my opinion.

.todotxt

File extensions are arbitrary. Anyone can put anything at the end of the file. There isn't a file extensions registration office. And we are pretty sure that .todotxt file has the same syntax as todo.txt, plus enables us to mark files that are used with this specific syntax easly.

If user wants a todo for Bob and makes bob.txt how do we know what user put inside? If we make new extension bob.todotxt then a) files can be renamed easly b) text editors won't want to open that file but they can.

I think we should look on how .csv files are handled they are "plain text" and shouldn't be handled with a text editor.

config file

Putting arbibitrary values in one place is good coding practice.

I think there should ba a dialogue box (alredy implementd by OS) to choose what file types are allowed.

I have implemented this behaviour in the fix. When you enable all file extensions in the popup there is filetype chooser where you can choose witch filetype you are selecting. (Text files or All files)

[ransome1]

I propose we

1. remove the "All files" option and stick to a predefined set of extensions: .txt :)
2. we remove the setting which allows all file extensions
3. as described above we add a new setting in the config file: allowedFileExtensions: ['txt'] (@thejevans you would need to do this manually like this allowedFileExtensions: ['txt, todotxt'] ...)
4. When I find some time I will consider adding a UI element, to update the allowedFileExtensions. (@thejevans ... until this is deployed)

Would that be a proper solution?

I think there should ba a dialogue box (alredy implementd by OS) to choose what file types are allowed.

I don't know what exactly you're referring to here.

[ludrol]

Let's look for example at paint on windows (screenshot in polish locale) We have list of file extensions (.png, .bmp and others) we have "all image extensions" and "all files" That is objectively good design. We let the user choose what they want to open.

1. remove the "All files" option

I disagree. Users need an option to open all files.

2. we remove the setting which allows all file extensions

I agree

3. and 4.

This should be in one place. In the openFile() code is good. UI element would be nice but development time would be wisely spent elsewhere.

In my opinion todo.txt has bad file naming scheme. It is better to stick witch classic file extensions than invent new ways to name files in confusing ways. example.todotxt clearly marks the file type that I can rename it to whatever I want.

I don't know your development philosophy and I can't make a compelling argument that will sway your decision. I stand with libre mindset for opensource software. User should be free to use software as they please. And that means allowing users to open any any file type.

[ransome1]

I don't know your development philosophy and I can't make a compelling argument that will sway your decision.

Rather than a strict development philosophy I have a design philosophy in mind, which is keeping it simple for the user.

If I as a user now see .todotxt popping up in that list, I will ask myself Is this is a relevant file type? Is this maybe sleeks own file type? Should I use it?and Why does it not seem to be a text file? Because in your current proposal you're separating between Text Files (.txt .md) and todotxt Files (.todotxt). What makes .txt and .md text files but .todotxt not?

The other issue is that .todotxt is an edge case. There might be not another user besides @thejevans who will ever use it. I'm not happy with adding it to the code. What if somebody else needs for example .todo as an extension?

Or .mdTasks or .simpleTodos or whatever will come up in the context of some other application. Do you really want to add all these extensions in the code? I don't.

After reading through this thread again, wouldn't it be the most feasible solution to simply have it separated between Text files (only .txt) and All files?

98,53% of our users will use the default Text files anyways, is what my gut tells me. And the others can switch to All files and select whatever binary they want to inject into sleek ;) This would make it light on the interface and in the code too. With minimal adjustments, your PR almost covers it.

[thejevans]

Sorry for the delay, I was away from my desk for a few days.

I didn't check it on Linux, only on MacOS. @thejevans since it is working for you; On what OS are you on?

I was on my Windows 11 machine at the time. I didn't test on my other machines because my hardlink workaround still worked. I just tested the AppImage on NixOS with KDE Plasma, and I get the same behavior that @ludrol mentioned.

@ransome1 I think the solution you mention in your last comment is a good way to implement this, assuming it works for all OSs. File extensions are generally a decent heuristic for file behavior, but they are still just a heuristic. Having a way to work around them is a solid thing to have.

I have access to PCs running Windows 11 and various linux distributions, and I'm happy to test future fixes.