Apart from the AI moniker: a “text” file is at best a vague idea. What you consider to be text, is probably a sequence of bytes that convey meaning to you. Given that any file is only a sequence of bytes, deciding if something is a meaningful text in any of several hundred languages, a program, an image or something else entirely is not obvious for a machine. In some cases, it might not even be obvious to a human – would you be able to tell if a file contains a poem in Mandarin or a GIF only by looking at its bytes?
MacOS, like many Unixes, provides a program files that uses a ton of heuristics to figure out what the contents of a file might be. I doubt that finder uses that. It probably still relies on the old idea of looking at extensions (that was already a bad idea in MSDOSB and VMS).
Right.
DT should just give you the >>> OPTION <<<< of a preview where DT (or DTTG) displays as best it can, whatever file it is. 100% of the files I would use this for, that are currently WORTHLESS in DT for viewing, would be text files that DT simply gives up on since it doesn’t have the right “extension” (or the Operating System isn’t helping either).
DT/DTTGO are both lazy software in this regard IMHO.
Come on guys, you can do better…(This is “AI” software, right? And, you can’t even figure out what a text file is??? )
Going “Jeeeez” impresses on me as somewhat belittling in this context, but I might just be being a little sensitive 🥸
Did you pick up upon the fact that you can solve this problem for yourself using the AdditionalPlainTextExtensions hidden preference in DT (although not in DTTG to my knowledge)?
I have no doubt DTs programmers could help DT identify files which can usefully be displayed as plain text. Why doesn’t it already, then? Presumably because other things seemed more important to implement. For my use case I would agree with that decision. You for yours don’t.
Your feature request is for a “display as plain text” button or menu entry if I understand you correctly? That could easily be scripted in DT, but I don’t have a solution for DTTG handy.
Why should text file extensions be a (seemingly mysterious) hidden and not a default capability of a powerful software program? To wit, why shouldn’t the software do more without me “scripting” or “finding hidden extensions?”
What I’m suggesting is that anytime DT/DTTG can show a preview of a file, it should “know” what a text file is or at least go ahead and try to display the file – even if it’s garbage – if that’s what the user wants. I can view any kind of file in, say, BBEDIT, even though it may not be “readable”.
I know this might not be an easy task, but DT is an advanced program. Perhaps it could read the first “x” bytes in a file and if all fall within in a certain range, it could decide it’s a text file. Just a starting point idea.
(Note: My “Jeeez” above was not directed at any person. Sorry if that came across negatively. I was just expressing my opinion that DT misses the mark on what should be default obvious file display behavior. Again, just my opinion.)
So you’d rather have DT display the content of a file that has the extension PDF or JPG as meaningless garbage just because PRG files in your case contain text? I’m not so sure that this would be considered helpful by many people.
BTW, there are 10 different versions of PRG files (PRG File - What is a .prg file and how do I open it?). Why would DT prefer text over any other possible content here?
I’m really just saying it would be nice if DT would try to figure out if it’s a text file and display it.
That’s a much nicer way of saying it 
thank you 
Most (well designed) binary files have known headers. Often the first word is distinctive.
However, detecting filetype by reading the first few bytes is best handled by the operating system. We’re a long ways off from the heady days of of resource forks and other viable alternatives to extensions.
Thanks for your input on that so I could clarify.
I remember the days when file extensions were a Windows thing and the odd feeling when it became something Macs started to use more and more. 
maybe a checkbox “interpret this as an ascii file” might be useful.
Deliberately excluding all languages that use non-ASCII, like French, Spanish, Russian, Chinese, Thai, German… in fact, you’d have to offer far more possibilities than ASCII, namely all the ISO-Latin variants and utf-8, maybe even utf-16, and also the older codings for CJK, possibly Cyrillic, Hebrew and Arab.
As much as I find the fixation on file extensions stupid, in the case of the original poster they should simply tell finder that PRG is a text file and tell DT to treat it as such.
Why not just have DTTG have a “Preview” long-press option. If you select it, you get DT’s best attempt at displaying the file. For me, I know which files that would display correctly (like a Visual FoxPro “PRG” (program) file) and, like trying to show a binary file in BBEDIT, would be willing to accept the risk of seeing garbage displayed if I selected the wrong file.
And nowhere, an earnest request for OP to stand-down & restate 
DT figured out a long time ago their success is predicated on making life better. That’s why they’re Kong in this space.
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:
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.
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)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 ==>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.
Would you want the app to spawn a separate
fileprocess 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.
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.