medley
medley copied to clipboard
Interlisp
GREP: avoids tedit-file formatting, font change chars in Lisp source files, adds TGREP
The tedit-file part works only in 4th round or later (see discussion in #1496).
New entry TGREP puts the results in a scrollable TEDIT stream.
This also suppresses characters below (CHARCODE LF) in a Lisp source file.
A cosmetic different: filenames are preceded by a blank line and printed in bold.
On that front, I tend to say (FILES (FROM loadups)…), because MEDLEYDIR is used basically to set up DIRECTORIES, LISPUSERSDIRECTORIES… Is that better?
I think the only need for this is to get the stream declaration, so it can change the OUTCHARFN to suppress font change characters. Wouldn’t be necessary if STREAMPROP saw the external format fields as properties, so that the format behavior can be changed without creating a whole new format.
On Mar 5, 2024, at 8:17 AM, Nick Briggs @.***> wrote:
@nbriggs commented on this pull request.
In lispusers/GREP https://github.com/Interlisp/medley/pull/1513#discussion_r1513113434:
(PRETTYCOMPRINT GREPCOMS)
-(RPAQQ GREPCOMS ((FNS DOGREP GREP PHONE)
(INITVARS (PHONELISTFILES))))+(RPAQQ GREPCOMS
[(FNS DOGREP GREP LISPSOURCEOUTCHARFN TGREP)(P (MOVD? 'NILL 'TEDIT.FORMATTEDFILEP))(DECLARE%: ***@***.*** DONTCOPY (FILES (FROM VALUEOF (MEDLEYDIR "loadups"))Yeah, not a big fan of (FROM VALUEOF (MEDLEYDIR "loadups")) embedded in the COMS.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/1513#discussion_r1513113434, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJMOU6QMJFGJZQDLLODYWXVYJAVCNFSM6AAAAABCDPXBCCVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMYTSMJXGUYDEMJWG4. You are receiving this because you authored the thread.
the font control-codes are just treated as a SEPRCHAR ... is this going to be used for EDITCALLERS too? (This was originally the 'phone' LispUsers package, wasn't it?)
I got rid of the dependence on the stream record, by just suppressing lower-control codes in all cases. It could be made sensitive to LISPSOURCEFILEP, but that's probably not too valuable. (Note that the prior set up had a terrible bug, anyway, this supercedes).
Is it expected that if you do, when connected to medley/library
(GREP "FOO" "BROWSER.TEDIT")
you get a TYPE-MISMATCH error for NIL is not a NUMBER ?
grep-error.txt
That’s interesting.
It’s trying to look just at the “logical” characters of the Tedit file, and it is passing in the byte position of the end of the plaintext part of the file to prevent the search from going uselessly into the formatting section (unless you were looking, I suppose, for the name of a font or the internals of an image object—then use the real grep).
But the branch for Tedit files should be outside of the search loop. After the with-open-file opens it as a simple stream, if it satisfies the Tedit test, the stream should be coerced to a text stream and the search should run on that. FILEPOS will probably break when it tries to map an image object through the upper-case array, so the stream should also set the property that returns a special character code for objects.
On Mar 16, 2024, at 10:25 AM, Nick Briggs @.***> wrote:
Is it expected that if you do, when connected to medley/library
(GREP "FOO" "BROWSER.TEDIT") you get a TYPE-MISMATCH error for NIL is not a NUMBER ? grep-error.txt https://github.com/Interlisp/medley/files/14624663/grep-error.txt — Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/1513#issuecomment-2002054835, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJIFJ6QLZXJPGQKZRKTYYR6CJAVCNFSM6AAAAABCDPXBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA2TIOBTGU. You are receiving this because you authored the thread.
Works on BROWSER.TEDIT, but try it on lispusers/BLACKBOX.TEDIT -- I got a HELP! FILE BUFFER FOR NON-FILE PIECE
When it finds the text in a TEdit file, it reports it as being found in (for example)
(from #<IO Text Stream/137,5600)
rather than the original file name.
This is a problem in Tedit, Grep is OK.
(It seems to get in the wrong state when binning from a file is followed by peeking at an object.)
On Mar 16, 2024, at 11:09 AM, Nick Briggs @.***> wrote:
Works on BROWSER.TEDIT, but try it on lispusers/BLACKBOX.TEDIT -- I got a HELP! FILE BUFFER FOR NON-FILE PIECE
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/1513#issuecomment-2002070686, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJPJYPXC4BFRUR5ZIQ3YYSDFVAVCNFSM6AAAAABCDPXBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA3TANRYGY. You are receiving this because you authored the thread.
This is fixed in last commit. (the HELP is an independent problem)
On Mar 16, 2024, at 11:13 AM, Nick Briggs @.***> wrote:
When it finds the text in a TEdit file, it reports it as being found in (for example) (from #<IO Text Stream/137,5600) rather than the original file name.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/1513#issuecomment-2002072606, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJIWDHHSNVQRYXAIP6TYYSDTZAVCNFSM6AAAAABCDPXBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA3TENRQGY. You are receiving this because you authored the thread.
OK, looks good then. I discovered by accident that you have to be careful not to give it PATHNAMEs instead of atoms or strings for the files - grepping in (CL:DIRECTORY "*") fails, but that's DIRECTORYNAMEP failing because PACKFILENAME.STRING is unhappy.
Apart from fixing the lowe-level peekbin bug in Tedit, Grep could probably do more with image objects.
The line detection just ignores them for the match (you presumably can’t match on an object, and FILEPOS doesn’t like them), but it would be relatively easy to produce some representation of a particular image object on a line that elsewhere has a matching substring—a GETFILEPTR and a TEDIT.NTHCHARCODE. We could at least show its getfn, maybe in italics, or even run the display function of the image object so the whole thing appears in the output stream (if output is going to an image stream). Or just run its PREPRINTFN.
On Mar 16, 2024, at 11:42 AM, Nick Briggs @.***> wrote:
OK, looks good then. I discovered by accident that you have to be careful not to give it PATHNAMEs instead of atoms or strings for the files - grepping in (CL:DIRECTORY "*") fails, but that's DIRECTORYNAMEP failing because PACKFILENAME.STRING is unhappy. image.png (view on web) https://github.com/Interlisp/medley/assets/8138841/b1a6924a-051c-49bf-bfd9-fa8a8826e314 — Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/pull/1513#issuecomment-2002083472, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJOHQ27DVSUFDJVTIT3YYSHAZAVCNFSM6AAAAABCDPXBCCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAMBSGA4DGNBXGI. You are receiving this because you authored the thread.