Open text files with non-editor

[scottkosty]

Some text files are not meant to be open in a text editor. For example, a .lyx file has a format that is plain text but it is meant to only be edited by the application LyX.

taskopen currently sees "text" in the following output

$ file lyxfile.lyx 
lyxfile.lyx: LyX document text

and decides to open with EDITOR because of the following code:

if ($filetype =~ m/text|empty/ ) {
                $cmd = qq/$EDITOR/;
}

On first thought, I think I would prefer to get rid of the hardcoded detection of text files. Why not let xdg-open just deal with everything? That way the user can easily customize the behavior from a central location.

Back to this specific issue, it is difficult for me to configure taskopen to open .lyx files in LyX. One solution would be to process the custom regexes before the default regexes. Again on first thought (as you can see, I am hesitant to suggest these changes with confidence), this seems to make sense, because if a custom regex matches, a user likely prefers the custom command over the default command.

I volunteer to make a patch, if we can decide on the desired behavior.

[scottkosty]

I forgot to say that my current workaround for this issue is to modify the FILE_REGEX and append

.*(?<!\.lyx)$

so as not to match .lyx files. I have not tested much but I think the above negative lookahead should work (I will report back if it doesn't). I don't know if there is a more simple way.

[jschlatow]

@scottkosty I get your point. The file type detection is indeed a bit obscure and more of a relict from times where taskopen was not using xdg-open. I think it'd be more transparent leaving this decision to xdg-open (or whatever is configured as FILE_CMD). However, note that another option that came to my mind would be to check the MIME type for text/plain (as file can also return the MIME type).

Regarding your second issue I think modifying the FILE_REGEX is the best option. I actually have a similar use case for taskopen in which the CUSTOM_REGEX performs a different action on a file than xdg-open would do. More precisely, I have a couple of markdown files that I either want to edit/open (which is the default action) or compile to a pdf. The latter I achieve by invoking taskopen with -Fso that it ignores the FILE_REGEX.

Intuitively, I would rather keep the evaluation order of FILE_REGEX and CUSTOM_REGEX because this way adding a CUSTOM_REGEX will never influence the behaviour of the default taskopen features.

[scottkosty]

@ValiValpas Checking the MIME type would also be an improvement. It's up to you whether you prefer to let xdg-open handle everything or switch the mime-type. Thanks for being open to an improvement here. Whichever change you prefer, I would volunteer to propose a patch if you don't feel like it.

Interesting use case regarding the markdown files. I understand your point for wanting to keep the evaluation order of FILE_REGEX and CUSTOM_REGEX. That makes sense.

Thanks for your comments on this issue!

[jschlatow]

@scottkosty I think it's totally fine to drop the filetype check and leave it to xdg-open. I'd be glad to receive a patch from you.

[scottkosty]

I made a pull request. Since I don't know what the future release number would be, I did not add a NEWS entry. Next time should I just edit such that the release is unspecified. e.g. the top of the file would be the following?

  - Allow xdg-open to handle all files (#96)

Bugfixes and minor improvements in taskopen 1.1.1

  - Fix warnings when TEXT_REGEX or NO_ANNOTATION_HOOK are undefined (#93)
  - Fix comment in default taskopenrc (#92)

[jschlatow]

Thanks a lot @scottkosty. My workflow is a bit odd as I implemented an automated versioning. More precisely, I make all changes to the devel branch for which I installed a pre-commit hook that bumps the release number. Next time it'd therefore be great if you made your contributions to the devel branch...not a major issue though ;-)

[scottkosty]

Next time it'd therefore be great if you made your contributions to the devel branch

I'd be happy to do so. I hope I remember. I should, because there is a similar git setup in the taskwarrior repos.

Thanks.