Safe(er) evalulation of Lisp code in agda-mode #6537
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This was referenced Mar 16, 2023
|
According to #6123 (comment), this should only be merged AFTER #6536 |
phikal
force-pushed
the
safe-eval
branch
2 times, most recently
from
df21bf5
to
9d49cba
Compare
* agda2-mode.el (agda2-infer-type-maybe-toplevel): Sharp-quote 'agda2-infer-type'. (agda2-solveAll-action): Sharp-quite 'agda2-solve-action'. (agda2-compute-normalised-maybe-toplevel): Sharp quote 'agda2-compute-normalised' and 'agda2-compute-normalised-toplevel'. Sharp-quoting functions indicates that a symbol should have a bound function slot, and that the byte compiler should check if this is the case, otherwise emit a warning.
It is not necessary to use 'eval' to invoke a function with an argument list of unknown length.
This change builds on c7492c0, dropping the need for any queue (of string or a buffer), by inserting the process output directly into the process buffer and operating on thereon. We avoid the overhead of consing lists and strings, while simplifying the logic by relying more on Lisp primitives.
Since the process output can be chunked inconveniently (e.g. breaking mid-line), we need to make sure that we can recognise and handle these situations. This includes making sure we don't mis-`read' part of a command, then run into a type error later on, but also restoring the previous state, so that we can hope to correctly parse the data upon receiving the next output chunk.
Since this is a buffer local variable, we need to make sure that we are manipulating and accessing it in the right buffer.
By using 'forward-line' it was possible for some commands to not get parsed properly, leaving 'agda2-mode' in an inconsistent state.
|
This is currently unreviewable due to the large number of commits. Also, the test suite seems to be failing. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Based on #6536, these changes address address an old comment:
Instead of just directly passing Lisp code to Emacs to evaluate, a few simple checks are made to ensure the commands are of the expected data types (I hope I am forgiven for using Common Lisp types here). Furthermore, the arguments are not evaluated, and instead just passed to functions that we just "checked" are safe.
New commands that Agda can invoke now have to be tagged with a
declarestatement:(defun agda2-status-action (status) "Display the string STATUS in the current buffer's mode line. \(precondition: the current buffer has to use the Agda mode as the major mode)." + (declare (agda2-command string)) (setq agda2-buffer-external-status status)