Closed masinter closed 2 years ago
... on the side of recall over precision, since the results of FFILEPOS are filtered by searching the S-expression after READing the results.
So, are you saying that it should always think of CLISPCHARS as atom delimeters (i.e. call SEPRCASE in EDITCALLERS with T)?
Separately, I think quote and comma should also be seen as atom delimiteres, maybe anything in the readtable that is a macro.
(It coud also be tightened up: look before the delimiter to see if it is escaped)
On Jul 22, 2022, at 9:16 AM, Larry Masinter @.***> wrote:
... on the side of recall over precision, since the results of FFILEPOS are filtered by searching the S-expression after READing the results.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/860#issuecomment-1192734294, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJJCV63U3R4HZBJPK7DVVLCODANCNFSM54MCNEOA. You are receiving this because you were mentioned.
If you look at man EDITCALLERS
it allows
ShellCommand("grep -boiwr editcallers .")
b: include byte offsets o: only show what matched (you could filter differently) i: case insensitive match (include files like those in CLOS) w: word delimited (simpler than writing a regexp) r: recursive (give a list of file names instead)
It just says that it allows for escapes, which are interpreted as don’t-check-for-a-delimiter. The question here is, when you don’t have escapes, what atom-delimiters should you be checking for?
(Note that the old code (and carried over into current code) was incorrect in the way it handles escapes in the middle of a search pattern: FOO$FIE. It treats this as if it was just FOO$, not requiring that there be a later FIE presumably before a next delimiter. A little sloppy, but maybe the READ and editor-match compensates for that for EDITCALLERS--but not for FINDCALLERS.)
The w option in the grep command doesn’t actually address our particular functionality, wherein we are trying to use an arbitrary read-table to determine what a “word” is. The seprs/breaks in the readtable presumably could be translated into a regexp without too much trouble.
On Jul 22, 2022, at 10:31 AM, Larry Masinter @.***> wrote:
If you look at man EDITCALLERS it allows prefix and suffix. There's a reference to Editcallers in the "MANAGER" lispusers (which I'd like to put into FULL as a friendlier interface to the file package, especially for CL users). FYI using the output of grep
ShellCommand("grep -boiwr editcallers .") b: include byte offsets o: only show what matched (you could filter differently) i: case insensitive match (include files like those in CLOS) w: word delimited (simpler than writing a regexp) r: recursive (give a list of file names instead)
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/860#issuecomment-1192792466, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJKFL5VVF3JA44WDCJLVVLLGJANCNFSM54MCNEOA. You are receiving this because you were mentioned.
I'm not sure what this issue is about... my temptation is to turn it into a Discussion since there isn't a problem per see.
If the issue is 'reviving CLISP' there is a lot of design work to do, and I'm not quite sure it's in our goals. s
Originally posted by @rmkaplan in https://github.com/Interlisp/medley/issues/853#issuecomment-1192178357
@masinter reply The introduction of Common Lisp and its usurpation of ":" for the package delimiter broke the most important use of CLISP to make RECORD-package references from A:B to (fetch B of A) and A:R.B to (fetch (R B) of A) So none of the source files in the post-Lyric era have CLISP and CLISP-expansion was put on a FLG basis. As for EDITCALLERS use of FFILEPOS I think you want to err on the side of