Why can't DTTG 3.0.5 (and DT 3) simply read any TEXT file (regardless of extension)?

DEVONthink
21

It’s true that it’s not totally obvious what is and is not a plain text file. But you can use some heuristics to make an educated guess and do what you can to display what’s there. Savvy developers have used such heuristics to extend QuickLook (what Finder does when you hit the spacebar) to recognize text files with nonstandard extensions. For many years I used QLStephen to do this:

QuickLookStephen

I just upgraded to Catalina two weeks ago and had to remove the version I installed a couple years ago as it was incompatible. I haven’t yet tried re-installing the version on GitHub. From what I see in the issue tracker, the current version works on Catalina but not Big Sur.

1 Like
22

Well, Finder is just a GUI program running in the user space of the OS, it is not the OS. The OS sees a text file correctly (as ASCII text). Please have a look at these simple commands:

522 22 18:32:08 ==>date >> date.prg
~ 
523 23 18:32:20 ==>file date.prg 
date.prg: ASCII text
~ 
524 24 18:32:27 ==>more date.prg 
Wed Apr  7 18:32:20 EEST 2021
date.prg (END)
23

Not an issue: the OS ‘sees’ all those correctly (as text):

525 25 18:41:17 ==>echo 'Radu Pârvu' > date.prg 
~ 
528 28 18:42:13 ==>more date.prg 
Radu Pârvu
~ 
529 29 18:42:17 ==>date >> date.prg
~ 
530 30 18:42:27 ==>more date.prg 
Radu Pârvu
Wed Apr  7 18:42:27 EEST 2021
~ 
531 31 18:42:36 ==>file date.prg 
date.prg: UTF-8 Unicode text
~ 
532 32 18:42:40 ==>
1 Like
24

I know that there’s a file utility on Unix-oid OSs. It does not exist on i*OS, though.

And we’re in an application here. Would you want the app to spawn a separate file process for each and every document it manages, just so that it’s able to (kind of) use the “right” preview for it? All this while there’s already a mechanism in the OS (or rather an OS utility) that provides for this? I think that this is not advisable for performance reasons.

25

Would you want the app to spawn a separate file process for each and every document it manages, just so that it’s able to (kind of) use the “right” preview for it?

It only has to interrogate how to display the file when the user displays it. It doesn’t have to do it all the time, for every file. Even spawning a shell to run file is probably a trivial overhead compared to all the other stuff DT has to do to display a file.

26

And all this because a user does not want to add the extension of their text file to the preferences?
Spawning processes in Unix is not exactly a cheap operation, BTW.

27

Firstly, I personally don’t need this capability. I’m addressing part of the feasibility issue, just because I happened to have just been dealing with QLStephen due to a Catalina upgrade.

Spawning processes in Unix is not exactly a cheap operation, BTW.

I was just writing Python multiprocessing code yesterday, spawning and forking processes. I’m aware of the overheads. For this kind of thing, they are trivial compared to GUI interactions and the timescales that matter to users viewing a file.

I just had a look at the QLStephen code. I only briefly looked at it, but it appears to mainly rely on Cocoa code interrogating existing MIME type file attributes.

I just re-installed QLStephen on my Mac with a new Catalina installation, and it works fine (I should repeat that the issue tracker indicates the Catalina build won’t run under Big Sur). As before, QuickLook display of plain text files is perceptually instantaneous. For example, in a code repo I’m currently working in, there’s a README file with no extension. Before installing QLStephen, QuickLook wouldn’t display it. Now it displays it instantaneously. QLStephen is doing work to build a thumbnail to display, and it’s still essentially instantaneous from a user’s perspective.

The point is that this is doable (at least through Catalina), if a developer wants to do it.

An interesting question for this thread is: If a user has installed a QuickLook extension, will DT use it for displaying files? For all I know, if it’s using the system’s QL capability behind-the-scenes, it would automatically do so without any work on the part of DT devs. If so, then QLStephen may be a solution to the problem (except for Big Sur, for now).

PS: As a caveat, I’ve played around further with exercising QLStephen. It catches some things that are displayable as text files, but not all. E.g., the repo I’m working in has some plain-text files with numerical data in files with a .sed suffix (“Spectral Energy Distribution”, nothing to do with the Linux sed utility!). Although they’re plain text, QLStephen isn’t displaying them. Maybe it depends on a MIME type being set elsewhere, or maybe .sed is registered for some app not providing QL capability.

29

Is not needed to spawn any process but build same functionality within the app.

Ref.: Index of /pub/file

30

Which, I think, takes us full circle back to where we were - a feature request which DT will hear and add to the list, I’m sure (@BLUEFROG?). The timing and implementation would be DT’s to decide.

31

Yes it has been noted from previous posts. And yes, there are no promises - implicit or explicit - on implementation.

1 Like