-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
advance-to-point advance to the end of the current block #136
base: master
Are you sure you want to change the base?
Conversation
Hi Luke! I don't know whether the "go to this exact point" behavior is still useful, but I suspect it is: the automatic logic to figure out where a block ends is not very good, and so it's good to be able to override it. That said, I agree with you that I prefer your behavior when it works. Doesn't C-c C-n do what you want in most cases? (Process the next block?) |
Yes,
|
(t | ||
(fstar-subp-advance-until (point)))))) | ||
(fstar-subp-advance-until (save-excursion (fstar-subp-next-block-start) (point))))))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the right API to call is fstar-subp--next-point-to-process
@@ -3485,9 +3485,9 @@ into blocks; process it as one large block instead." | |||
((fstar-subp--in-tracked-region-p) | |||
(fstar-subp-retract-until (point))) | |||
((consp arg) | |||
(fstar-subp-enqueue-until (point))) | |||
(fstar-subp-enqueue-until (save-excursion (fstar-subp-next-block-start) (point)))) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this case shouldn't change since it overrides the default block subdivision logic
Maybe we could have a setting for this. Or maybe one of the F* devs can comment? |
Being able to configure C-c C-RET to behave like C-c C-n sounds like a good idea to me. FWIW, finding the end of the current definition is difficult without actually using F* to parse the contents of the buffer. FYI, in fstar-vscode-assistant, when the user hits Ctrl+. the editor passes the current cursor location to the F* server, F* parses the buffer and advances to checker to up to the definition that encloses the current cursor location. |
It feels like the proper way to address the problem. Is it an API that emacs can also use or limited to vscode? |
Is fstar-vscode-assistant using LSP or the custom F* protocol? |
This pull request modifies the behavior of
fstar-subp-advance-or-retract-to-point
such that it will advance to the end of the current block.Previously, if the cursor is in the middle of a block, for example,
Pressing
C-c RET
will passlet foo(
to the sub-process, and reports an error. The updated function will pass the entirety oflet foo ...
to the process and succeed. This is helpful when I'm still trying to figure out the function body (especially if it spans multiple line), since I won't need to move my cursor (which I can useM-n
) and back (which is more difficult).I'm not a fstar power user and in all my use cases, I'm always advancing the proof checker on a block granularity. Maybe there is indeed a demand for sub-block advancement (maybe at tactic level, such as in Coq). If that's the case, I can create a separate function for this altered behavior and register a different key for it.