2. Basic Script Management

This chapter is an introduction to using the script management facilities of Proof General. We begin with a quick walkthrough example, then describe the concepts and functions in more detail.

2.1 Walkthrough example in Isabelle

Here’s a short example in Isabelle to see how script management is used. The file you are asked to type below is included in the distribution as ‘isar/Example.thy’. If you’re not using Isabelle, substitute some lines from a simple proof for your proof assistant, or consult the example file supplied with Proof General for your prover, called something like ‘foo/example.foo’ for a proof assistant Foo.

This walkthrough is keyboard based, but you could easily use the toolbar and menu functions instead. The best way to learn Emacs key bindings is by using the menus. You’ll find the keys named below listed on the menus.

• First, start Emacs with Proof General loaded. According to how you have installed Proof General, this may be by typing proofgeneral in a terminal, selecting it from a menu, or simply by starting Emacs itself.
• Next, find a new file by C-x C-f and typing as the filename ‘Walkthrough.thy’. This should load Isabelle Proof General and the toolbar and Proof General menus will appear. You should have an empty buffer displayed.

The notation C-x C-f means control key with ‘x’ followed by control key with ‘f’. This is a standard notation for Emacs key bindings, used throughout this manual. This function also appears on the File menu of Emacs. The remaining commands used will be on the Proof-General menu or toolbar.

If you’re not using Isabelle, you must choose a different file extension, appropriately for your proof assistant. If you don’t know what to use, see the previous chapter for the list of supported assistants and file extensions.

• Turn on electric terminator by typing C-c ; and enter:

  theory Walkthrough imports Main begin;

  This first command begins the definition of a new theory inside Isabelle, which extends the theory Main. (We’re assuming that you have Isabelle/HOL available, which declares the Main theory. You should be able to see the list of installed logics in Isabelle on the Logics menu).

Electric terminator sends commands to the proof assistant as you type them. At the moment you type the semicolon, the theory command will be sent to Isabelle behind the scenes. First, there is a short delay while Isabelle is launched; you may see a welcome message. Then, you may notice that the command briefly is given an orange/pink background (or shown in inverse video if you don’t have a colour display), before you see a window containing text like this:

theory Walkthrough 

which reflects the command just executed.

In this case of this first command, it is hard to see the orange/pink stage because the command is processed very quickly on modern machines. But in general, processing commands can take an arbitrary amount of time (or not terminate at all). For this reason, Proof General maintains a queue of commands which are sent one-by-one from the proof script. As Isabelle successfully processes commands in the queue, they will turn from the orange/pink colour into blue.

The blue regions indicate text that has been read by the prover and should not be edited, to avoid confusion between what the prover has processed and what you are looking at. To enforce this (and avoid potentially expensive reprocessing) the blue region can be made read-only. This is controlled by the menu item:

  Proof-General -> Quick Options -> Read Only

The first option ‘Strict Read Only’ was formerly the default for Proof General, and causes the blue region to be locked. Because of this, the term locked region term is used in Proof General documentation to mean the blue portion of the text which has been processed, although it is no longer locked by default. The current default is ‘Undo on Edit’ which causes the prover to undo back to any user edits. So if you change a processed piece of text you will need to re-process it. The final option, ‘Freely Edit’, allows you to freely edit the buffer without causing the prover to reprocess it. This can quickly lead to confusion and a loss of synchronization between what you are reading and what the prover has processed, so it is best used sparingly.

Electric terminator mode is popular, but not enabled by default because of the principle of least surprise. Moreover, in Isabelle, the semicolon terminators are optional so proof scripts are usually written without them to avoid clutter. You’ll notice that although you typed a semi-colon it was not included in the buffer! The electric terminator tries to be smart about comments and strings but sometimes it may be confused (e.g., adding a semi-colon inside an already written comment), or you may need to type several terminator commands together. In this case you can use the standard Emacs quote next character, typing C-q ; to quote the semi-colon. Alternatively you can use a prefix argument, as in M-3 ; to type three semi-colons.

Without using electric terminator, you can trigger processing the text up to the current position of the point with the key C-c C-RET, or just up to the next command with C-c C-n. We show the rest of the example in Isabelle with semi-colons, but these will not appear in the final text.

Coq, on the other hand, requires a full-stop terminator at the end of each line. If you want to enable electric terminator, use the menu item: Proof-General -> Quick Options -> Processing -> Electric Terminator

If you want to keep electric terminator enabled all the time, you can customize Proof General to do so, See section Customizing Proof General. For the common options, customization is easy: just use the menu item Proof General -> Quick Options to make your choices, and Proof-General -> Quick Options -> Save Options to save your choices.

• Next type on a new line:

  theorem my_theorem: "A & B --> B & A";

The goal we have set ourselves to prove should be displayed in the goals buffer.

• Now type:

  proof assume "A & C";

This will update the goals buffer.

But whoops! That was the wrong command, we typed C instead of B.

• Press C-c C-BS to pretend that didn’t happen.

Note: BS means the backspace key. This key press sends an undo command to Isabelle, and deletes the assume command from the proof script. If you just want to undo without deleting, you can type C-c C-u instead, or use the left-arrow toolbar navigation button.

• Instead, let’s try:

  assume "A & B";

  Which is better.

• From this assumption we can get B and A by the trivial step .. which splits the assumption using an elimination step:

  then obtain B and A ..;

• Finally, we establish the goal by the trivial step .. again, which triggers an introduction rule:

  then show "B & A" ..;

After this proof step, the message from Isabelle indicates that the proof has succeeded, so we can conclude the proof with the qed command.

• Finally, type:

  qed;

This last command closes the proof and saves the proved theorem.

Moving the mouse pointer over the qed command now reveals that the entire proof has been aggregated into a single segment (if you did this before, you would see highlighting of each command separately).

• Suppose we decide to call the theorem something more sensible. Move the cursor up into the locked region, somewhere between ‘theorem’ and ‘qed’, enter C-c C-RET.

You see that the locked segment for the whole proof is now unlocked (and uncoloured): it is transferred back into the editing region.

The command C-c C-RET moves the end of the locked region to the cursor position, or as near as possible above or below it, sending undoing commands or proof commands as necessary. In this case, the locked region will always be moved back to the end of the theory line, since that is the closest possible position to the cursor that appears before it. If you simply want to retract the whole file in one go, you can use the key C-c C-r (which corresponds to the up arrow on the toolbar), which will automatically move the cursor to the top of the file.

• Now improve the goal name, for example:

  theorem and_commutes: "A & B --> B & A"

  You can swiftly replay the rest of the buffer now with C-c C-b (or the down arrow on the toolbar).

• At the end of the buffer, you may insert the command

  end

  to complete the theory.

Notice that if you right-click on one of the highlighted regions in the blue area you will see a context menu for the region. This includes a “show/hide” option for folding a proof, as well as some editing commands for copying the region or rearranging its order in the processed text: “move up/move down”. (These latter commands occasionally help you reorder text without needing to reprove it, although they risk breaking the proof!)

Finally, once you are happy with your theory, you should save the file with C-x C-s before moving on to edit another file or exiting Emacs. If you forget to do this, Proof General or Emacs will surely prompt you sooner or later!

2.2 Proof scripts

A proof script is a sequence of commands which constructs definitions, declarations, theories, and proofs in a proof assistant. Proof General is designed to work with text-based interactive proof assistants, where the mode of working is usually a dialogue between the human and the proof assistant.

Primitive interfaces for proof assistants simply present a shell (command interpreter) view of this dialogue: the human repeatedly types commands to the shell until the proof is completed. The system responds at each step, perhaps with a new list of subgoals to be solved, or perhaps with a failure report. Proof General manages the dialogue to show the human only the information which is relevant at each step.

Often we want to keep a record of the proof commands used to prove a theorem, to build up a library of proved results. An easy way to store a proof is to keep a text file which contains a proof script; proof assistants usually provide facilities to read a proof script from a file instead of the terminal. Using the file, we can replay the proof script to prove the theorem again.

Using only a primitive shell interface, it can be tedious to construct proof scripts with cut-and-paste. Proof General helps out by issuing commands directly from a proof script file, while it is being written and edited. Proof General can also be used conveniently to replay a proof step-by-step, to see the progress at each stage.

Scripting is the process of building up a proof script file or replaying a proof. When scripting, Proof General sends proof commands to the proof assistant one at a time, and prevents you from editing commands which have been successfully completed by the proof assistant, to keep synchronization. Regions of the proof script are analysed based on their syntax and the behaviour of the proof assistant after each proof command.

2.3 Script buffers

A script buffer is a buffer displaying a proof script. Its Emacs mode is particular to the proof assistant you are using (but it inherits from proof-mode).

A script buffer is divided into three regions: locked, queue and editing. The proof commands in the script buffer can include a number of Goal-save sequences.

2.3.1 Locked, queue, and editing regions

The three regions that a script buffer is divided into are:

• The locked region, which appears in blue (underlined on monochrome displays) and contains commands which have been sent to the proof process and verified. The commands in the locked region cannot be edited.
• The queue region, which appears in pink (inverse video) and contains commands waiting to be sent to the proof process. Like those in the locked region, these commands can’t be edited.
• The editing region, which contains the commands the user is working on, and can be edited as normal Emacs text.

These three regions appear in the buffer in the order above; that is, the locked region is always at the start of the buffer, and the editing region always at the end. The queue region only exists if there is input waiting to be processed by the proof process.

Proof General has two fundamental operations which transfer commands between these regions: assertion (or processing) and retraction (or undoing).

Assertion causes commands from the editing region to be transferred to the queue region and sent one by one to the proof process. If the command is accepted, it is transferred to the locked region, but if an error occurs it is signalled to the user, and the offending command is transferred back to the editing region together with any remaining commands in the queue.

Assertion corresponds to processing proof commands, and makes the locked region grow.

Retraction causes commands to be transferred from the locked region to the editing region (again via the queue region) and the appropriate ’undo’ commands to be sent to the proof process.

Retraction corresponds to undoing commands, and makes the locked region shrink. For details of the commands available for doing assertion and retraction, See section Script processing commands.

2.3.2 Goal-save sequences

A proof script contains a sequence of commands used to prove one or more theorems.

As commands in a proof script are transferred to the locked region, they are aggregated into segments which constitute the smallest units which can be undone. Typically a segment consists of a declaration or definition, or all the text from a goal command to the corresponding save (e.g. qed) command, or the individual commands in the proof of an unfinished goal. As the mouse moves over the the region, the segment containing the pointer will be highlighted.

Proof General therefore assumes that the proof script has a series of proofs which look something like this:

   goal mythm is G
   …
   save theorem mythm

interspersed with comments, definitions, and the like. Of course, the exact syntax and terminology will depend on the proof assistant you use.

The name mythm can appear in a menu for the proof script to help quickly find a proof (see section Imenu and Speedbar).

2.3.3 Active scripting buffer

You can edit as many script buffers as you want simultaneously, but only one buffer at a time can be used to process a proof script incrementally: this is the active scripting buffer.

The active scripting buffer has a special indicator: the word Scripting appears in its mode line at the bottom of the screen. This is coloured to indicate the status: if it has a pink or blue background, the prover is processing the text (busy when pink). If it is in green, the buffer is completely processed.

When you use a scripting command, it will automatically turn a buffer into the active scripting mode. You can also do this by hand, via the menu command ’Toggle Scripting’ or the key C-c C-s.

C-c C-s

proof-toggle-active-scripting

When active scripting mode is turned on, several things may happen to get ready for scripting (exactly what happens depends on which proof assistant you are using and some user settings). First, the proof assistant is started if it is not already running. Second, a command is sent to the proof assistant to change directory to the directory of the current buffer. If the current buffer corresponds to a file, this is the directory the file lives in. This is in case any scripting commands refer to files in the same directory as the script. The third thing that may happen is that you are prompted to save some unsaved buffers. This is in case any scripting commands may read in files which you are editing. Finally, some proof assistants may automatically read in files which the current file depends on implicitly. In Isabelle, for example, there is an implicit dependency between a .ML script file and a .thy theory file which defines its theory.

If you have a partly processed scripting buffer and use C-c C-s, or you attempt to use script processing in a new buffer, Proof General will ask you if you want to retract what has been proved so far, Scripting incomplete in buffer myproof.v, retract? or if you want to process the remainder of the active buffer, Completely process buffer myproof.v instead? before you can start scripting in a new buffer. If you refuse to do either, Proof General will give an error message: Cannot have more than one active scripting buffer!.

To turn off active scripting, the buffer must be completely processed (all blue), or completely unprocessed. There are two reasons for this. First, it would certainly be confusing if it were possible to split parts of a proof arbitrarily between different buffers; the dependency between the commands would be lost and it would be tricky to replay the proof.(3) Second, we want to interface with file management in the proof assistant. Proof General assumes that a proof assistant may have a notion of which files have been processed, but that it will only record files that have been completely processed. For more explanation of the handling of multiple files, See section Switching between proof scripts.

Command: proof-toggle-active-scripting &optional arg

Toggle active scripting mode in the current buffer.
With arg, turn on scripting iff arg is positive.

2.4 Summary of Proof General buffers

Proof General manages several kinds of buffers in Emacs. Here is a summary of the different kinds of buffers you will use when developing proofs.

• The proof shell buffer is an Emacs shell buffer used to run your proof assistant. Usually it is hidden from view (but see section Escaping script management). Communication with the proof shell takes place via two or three intermediate buffers.
• A script buffer, as we have explained, is a buffer for editing a proof script. The active scripting buffer is the script buffer which is currently being used to send commands to the proof shell.
• The goals buffer displays the list of subgoals to be solved for a proof in progress. During a proof it is usually displayed together with the script buffer. The goals buffer has facility for proof-by-pointing.
• The response buffer displays other output from the proof assistant, for example error messages or informative messages. The response buffer is displayed whenever Proof General puts a new message in it.
• The trace buffer is a special version of the response buffer. It may be used to display unusual debugging output from the prover, for example, tracing proof tactics or rewriting procedures. This buffer is also displayed whenever Proof General puts a new message in it (although it may be quickly replaced with the response or goals buffer in two-buffer mode).

Normally Proof General will automatically reveal and hide the goals and response buffers as necessary during scripting. However there are ways to customize the way the buffers are displayed, for example, to prevent auxiliary buffers being displayed at all (see section Display customization).

The menu Proof General -> Buffers provides a convenient way to display or switch to a Proof General buffer: the active scripting buffer; the goal or response buffer; the tracing buffer; or the shell buffer. Another command on this menu, Clear Responses, clears the response and tracing buffer.

2.5 Script editing commands

Proof General provides a few functions for editing proof scripts. The generic functions mainly consist of commands to navigate within the script. Specific proof assistant code may add more to these basics.

Indentation is controlled by the user option proof-script-indent (see section User options). When indentation is enabled, Proof General will indent lines of proof script with the usual Emacs functions, particularly TAB, indent-for-tab-command. Unfortunately, indentation in Proof General 4.6-git is somewhat slow. Therefore with large proof scripts, we recommend proof-script-indent is turned off.

Here are the commands for moving around in a proof script, with their default key-bindings:

C-c C-a

proof-goto-command-start

C-c C-e

proof-goto-command-end

C-c C-.

proof-goto-end-of-locked

Command: proof-goto-command-start

Move point to start of current (or final) command of the script.

Command: proof-goto-command-end

Set point to end of command at point.

The variable proof-terminal-string is a prover-specific string to terminate proof commands. LEGO and Isabelle used a semicolon, ‘;’. Coq employs a full-stop ‘.’.

Command: proof-goto-end-of-locked &optional switch

Jump to the end of the locked region, maybe switching to script buffer.
If called interactively or switch is non-nil, switch to script buffer. If called interactively, a mark is set at the current location with ‘push-mark’

2.6 Script processing commands

Here are the commands for asserting and retracting portions of the proof script, together with their default key-bindings. Sometimes assertion and retraction commands can only be issued when the queue is empty. You will get an error message Proof Process Busy! if you try to assert or retract when the queue is being processed.(4)

C-c C-n

proof-assert-next-command-interactive

C-c C-u

proof-undo-last-successful-command

C-c C-BS

proof-undo-and-delete-successful-command

C-c C-RET

proof-goto-point

C-c C-b

proof-process-buffer

C-c C-r

proof-retract-buffer

C-c terminator-character

proof-electric-terminator-toggle

The last command, proof-electric-terminator-toggle, is triggered using the character which terminates proof commands for your proof assistant’s script language. LEGO and Isabelle used C-c ;, for Coq, use C-c .. This not really a script processing command. Instead, if enabled, it causes subsequent key presses of ; or . to automatically activate proof-assert-next-command-interactive for convenience.

Rather than use a file command inside the proof assistant to read a proof script, a good reason to use C-c C-b (proof-process-buffer) is that with a faulty proof script (e.g., a script you are adapting to prove a different theorem), Proof General will stop exactly where the proof script fails, showing you the error message and the last processed command. So you can easily continue development from exactly the right place in the script.

In normal development, one often jumps into the middle or to the end of some file, because this is the point, where a lemma must be added or a definition must be fixed. Before starting the real work, one needs to assert the file up to that point, usually with C-c C-RET (proof-goto-point). Even for medium sized files, asserting a big portion can take several seconds. There are different ways to speed this process up.

• One can split the development into smaller files. This works quite well with Coq, automatic background compilation, Automatic Compilation in Detail, and the fast compilation options, Quick and inconsistent compilation.
• One can configure proof-omit-proofs-option to t to omit complete opaque proofs when larger chunks are asserted. A proof is opaque, if its proof script or proof term cannot influence the following code. In Coq, opaque proofs are finished with Qed, non-opaque ones with Defined. When this omit-proofs feature is configured, complete opaque proofs are silently replaced with a suitable cheating command (Admitted for Coq) before sending the proof to the proof assistant. For files with big proofs this can bring down the processing time to 10% with the obvious disadvantage that errors in the omitted proofs go unnoticed. Currently, the omit-proofs feature is only supported for Coq.

  A prefix argument for proof-goto-point and proof-process-buffer toggles the omit-proofs feature temporarily for this invocation. That is, if proof-omit-proofs-option has been set to t, a prefix argument switches the omit-proofs feature off for these commands. Vice versa, if proof-omit-proofs-option is nil, a prefix argument switches the omit-proofs feature temporarily on for one invocation.

  Note that the omit-proof feature works by examining the asserted region with different regular expressions to recognize proofs and to differentiate opaque from non-opaque proofs. This approach is necessarily imprecise and it may happen that certain non-opaque proofs are classified as opaque ones, thus being omitted and that the proof script therefore fails unexpectedly at a later point. Therefore, if a proof script fails unexpectedly try processing it again after disabling the omit-proofs feature.

• An often used poor man’s solution is to collect all new material at the end of one file, regardless where the material really belongs. When the final theorem has been proved, one cleans up the mess and moves all stuff where it really belongs.

Here is the full set of script processing commands.

Command: proof-assert-next-command-interactive

Process until the end of the next unprocessed command after point.
If inside a comment, just process until the start of the comment.

Command: proof-undo-last-successful-command

Undo last successful command at end of locked region.

Command: proof-undo-and-delete-last-successful-command

Undo and delete last successful command at end of locked region.
Useful if you typed completely the wrong command. Also handy for proof by pointing, in case the last proof-by-pointing command took the proof in a direction you don’t like.

Notice that the deleted command is put into the Emacs kill ring, so you can use the usual ‘yank’ and similar commands to retrieve the deleted text.

Command: proof-goto-point &optional raw

Assert or retract to the command at current position.
Calls ‘proof-assert-until-point’ or ‘proof-retract-until-point’ as appropriate. With prefix argument raw, the activation of the omit proofs feature (‘proof-omit-proofs-option’) is temporarily toggled, so we can chose whether to check all proofs in the asserted region, or to merely assume them and save time.

Command: proof-process-buffer &optional raw

Process the current (or script) buffer, and maybe move point to the end.
With prefix argument raw, the activation of the omit proofs feature (‘proof-omit-proofs-option’) is temporarily toggled, so we can chose whether to check all proofs in the asserted region, or to merely assume them and save time.

Command: proof-retract-buffer &optional called-interactively

Retract the current buffer, and maybe move point to the start.
Point is only moved according to ‘proof-follow-mode’, if called-interactively is non-nil, which is the case for all interactive calls.

Command: proof-electric-terminator-toggle &optional arg

Toggle ‘proof-electric-terminator-enable’. With arg, turn on iff ARG>0.
This function simply uses customize-set-variable to set the variable.

Command: proof-assert-until-point-interactive

Process the region from the end of the locked-region until point.
If inside a comment, just process until the start of the comment.

Command: proof-retract-until-point-interactive &optional delete-region

Tell the proof process to retract until point.
If invoked outside a locked region, undo the last successfully processed command. If called with a prefix argument (delete-region non-nil), also delete the retracted region from the proof-script.

As experienced Emacs users will know, a prefix argument is a numeric argument supplied by some key sequence typed before a command key sequence. You can supply a specific number by typing <Meta> with the digits, or a “universal” prefix of C-u. See (emacs)Arguments for more details. Several Proof General commands, like proof-retract-until-point-interactive, may accept a prefix argument to adjust their behaviour somehow.

2.7 Proof assistant commands

There are several commands for interacting with the proof assistant and Proof General, which do not involve the proof script. Here are the key-bindings and functions.

C-c C-l

proof-display-some-buffers

C-c C-p

proof-prf

C-c C-t

proof-ctxt

C-c C-h

proof-help

C-c C-i

proof-query-identifier

C-c C-f

proof-find-theorems

C-c C-w

pg-response-clear-displays

C-c C-c

proof-interrupt-process

C-c C-v

proof-minibuffer-cmd

C-c C-s

proof-shell-start

C-c C-x

proof-shell-exit

Command: proof-display-some-buffers

Display the response, trace, goals, or shell buffer, rotating.
A fixed number of repetitions of this command switches back to the same buffer. Also move point to the end of the response buffer if it’s selected. If in three window or multiple frame mode, display two buffers. The idea of this function is to change the window->buffer mapping without adjusting window layout.

Command: proof-prf

Show the current proof state.
Issues a command to the assistant based on proof-showproof-command.

Command: proof-ctxt

Show the current context.
Issues a command to the assistant based on proof-context-command.

Command: proof-help

Show a help or information message from the proof assistant.
Typically, a list of syntax of commands available. Issues a command to the assistant based on proof-info-command.

Command: proof-query-identifier string

Query the prover about the identifier string.
If called interactively, string defaults to the current word near point.

Command: proof-find-theorems arg

Search for items containing given constants.
Issues a command based on arg to the assistant, using proof-find-theorems-command. The user is prompted for an argument.

Command: pg-response-clear-displays

Clear Proof General response and tracing buffers.
You can use this command to clear the output from these buffers when it becomes overly long. Particularly useful when ‘proof-tidy-response’ is set to nil, so responses are not cleared automatically.

Command: proof-interrupt-process

Interrupt the proof assistant. Warning! This may confuse Proof General.

This sends an interrupt signal to the proof assistant, if Proof General thinks it is busy.

This command is risky because we don’t know whether the last command succeeded or not. The assumption is that it didn’t, which should be true most of the time, and all of the time if the proof assistant has a careful handling of interrupt signals.

Some provers may ignore (and lose) interrupt signals, or fail to indicate that they have been acted upon yet stop in the middle of output. In the first case, PG will terminate the queue of commands at the first available point. In the second case, you may need to press enter inside the prover command buffer (e.g., with Isabelle2009 press RET inside isabelle).

Command: proof-minibuffer-cmd cmd

Send cmd to proof assistant. Interactively, read from minibuffer.
The command isn’t added to the locked region.

If a prefix arg is given and there is a selected region, that is pasted into the command. This is handy for copying terms, etc from the script.

If ‘proof-strict-state-preserving’ is set, and ‘proof-state-preserving-p’ is configured, then the latter is used as a check that the command will be safe to execute, in other words, that it won’t ruin synchronization. If when applied to the command it returns false, then an error message is given.

warning: this command risks spoiling synchronization if the test ‘proof-state-preserving-p’ is not configured, if it is only an approximate test, or if ‘proof-strict-state-preserving’ is off (nil).

As if the last two commands weren’t risky enough, there’s also a command which explicitly adjusts the end of the locked region, to be used in extreme circumstances only. See section Escaping script management.

There are a few commands for starting, stopping, and restarting the proof assistant process. The first two have key bindings but restart does not. As with any Emacs command, you can invoke these with M-x followed by the command name.

Command: proof-shell-start

Initialise a shell-like buffer for a proof assistant.
Does nothing if proof assistant is already running.

Also generates goal and response buffers.

If ‘proof-prog-name-ask’ is set, query the user for the process command.

Command: proof-shell-exit &optional dont-ask

Query the user and exit the proof process.

This simply kills the ‘proof-shell-buffer’ relying on the hook function

‘proof-shell-kill-function’ to do the hard work. If optional argument dont-ask is non-nil, the proof process is terminated without confirmation.

The kill function uses ‘<PA>-quit-timeout’ as a timeout to wait after sending ‘proof-shell-quit-cmd’ before rudely killing the process.

This function should not be called if ‘proof-shell-exit-in-progress’ is t, because a recursive call of ‘proof-shell-kill-function’ will give strange errors.

Command: proof-shell-restart

Clear script buffers and send ‘proof-shell-restart-cmd’.
All locked regions are cleared and the active scripting buffer deactivated.

If the proof shell is busy, an interrupt is sent with ‘proof-interrupt-process’ and we wait until the process is ready.

The restart command should re-synchronize Proof General with the proof assistant, without actually exiting and restarting the proof assistant process.

It is up to the proof assistant how much context is cleared: for example, theories already loaded may be "cached" in some way, so that loading them the next time round only performs a re-linking operation, not full re-processing. (One way of caching is via object files, used by Coq).

2.8 Toolbar commands

The toolbar provides a selection of functions for asserting and retracting portions of the script, issuing non-scripting commands to inspect the prover’s state, and inserting "goal" and "save" type commands. The latter functions are not available on keys, but are available from the from the menu, or via M-x, as well as the toolbar.

Command: proof-issue-goal arg

Write a goal command in the script, prompting for the goal.
Issues a command based on arg to the assistant, using proof-goal-command. The user is prompted for an argument.

Command: proof-issue-save arg

Write a save/qed command in the script, prompting for the theorem name.
Issues a command based on arg to the assistant, using proof-save-command. The user is prompted for an argument.

2.9 Interrupting during trace output

If your prover generates output which is recognized as tracing output in Proof General, you may need to know about a special provision for interrupting the prover process. If the trace output is voluminous, perhaps looping, it may be difficult to interrupt with the ordinary C-c C-c (proof-interrupt-process) or the corresponding button/menu. In this case, you should try Emacs’s quit key, C-g. This will cause a quit in any current editing commands, as usual, but during tracing output it will also send an interrupt signal to the prover. Hopefully this will stop the tracing output, and Emacs should catch up after a short delay.

Here’s an explanation of the reason for this special provision. When large volumes of output from the prover arrive quickly in Emacs, as typically is the case during tracing (especially tracing looping tactics!), Emacs may hog the CPU and spend all its time updating the display with the trace output. This is especially the case when features like output fontification and token display are active. If this happens, ordinary user input in Emacs is not processed, and it becomes difficult to do normal editing. The root of the problem is that Emacs runs in a single thread, and pending process output is dealt with before pending user input. Whether or not you see this problem depends partly on the processing power of your machine (or CPU available to Emacs when the prover is running). One way to test is to start an Emacs shell with M-x shell and type a command such as yes which produces output indefinitely. Now see if you can interrupt the process! (Warning — on slower machines especially, this can cause lockups, so use a fresh Emacs.)

This document was generated on April 6, 2024 using texi2html 1.82.