medley
medley copied to clipboard
Interlisp
LISPSOURCEFILEP returns NIL for files starting with; -- i.e., only for managed files
the question that this seems most useful for is "is this a managed file". Maybe a different one for "is this a text-only LISP file?" Or add some options?
I'm not sure that it should return NIL if it looks like a commonlisp file, if instead it could decode and return the reader environment from the first line (as if it was a DEFINEFILEINFO). Functions like FINDCALLERS and EDITCALLERS might be able to behave better, even if not managed, and maybe even SEE from Tedit.
Maybe it should return a second value to say what type of source file it is, in addtion to the reader environment.
A separate question of what it should return if the first ; line doesn't look like a reader environment.
I see your point. There are a number of half-done "what is the X of this file, please look at it and decide" based on the file extension and the file contents. Even when you have a more definitive answer (file extension, MIME type), even then false positives are more costly than false negatives, and many workflows don't make provisions for tentative or multiple possible types, and the answer used to manage HCFILES and File Brower actions. I need a way of asking, about files without a file name extension or unknown one "Is this a Medley Interlisp FILEPKG managed file, as a guard against attempting to apply operations that only work on managed files. Perhaps LISPSOURCEFILEP isn't the right name? FILEPKG-FILE-P?
Some background:
- https://archive.org/details/System_33_Conversion_Larry_Masinter_1992-06-30_Xerox_PARC
- https://www.ietf.org/archive/id/draft-masinter-mime-web-info-00.pdf
- https://patents.google.com/patent/US8099445
I looked at the proposed code change, and it makes me a little nervous. The change is in \PARSE-FILE-HEADER, which is the subfunction that LISPSOURCEFILEP calls. But \PARSE-FILE-HEADER is called by a number of other functions. Is NIL the right value for an unmanaged file for all of those other invocations?
I have reviewed all of the calls to \PARSE-FILE-HEADER and it seems like none of them are prepared in any way for a single return value of the result. They all look like they were written using the existing MAN LISPSOURCEFILEP documented behavior. There is another function LISPFILETYPE which returns the type, and perhaps the introduction of better support for unmanaged files or the file manager workflow would be appropriate. Besides, there is no code written than I know of to deal with the (now common) emacs mode lines.
The TextModules manual (page 339 of the PDF) seems to imply the tool parses Emacs mode lines, but the impression I get from the code is it just discards them when reading.
solved another way -- LISPSOURCEFILEP might give an answer based on starting with a ; but it's OK. Save for another day.