Replies: 5 comments
-
... on the side of recall over precision, since the results of FFILEPOS are filtered by searching the S-expression after READing the results. |
Beta Was this translation helpful? Give feedback.
-
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 <#860 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJJCV63U3R4HZBJPK7DVVLCODANCNFSM54MCNEOA>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
If you look at
b: include byte offsets |
Beta Was this translation helpful? Give feedback.
-
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 <#860 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQSTUJKFL5VVF3JA44WDCJLVVLLGJANCNFSM54MCNEOA>.
You are receiving this because you were mentioned.
|
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
Originally posted by @rmkaplan in #853 (comment)
@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
Beta Was this translation helpful? Give feedback.
All reactions