Custom Query (361 matches)
Results (19 - 21 of 361)
| Ticket | Owner | Reporter | Resolution | Summary |
|---|---|---|---|---|
| #157 | duplicate | undo sometimes incorrectly tries to undo a larger container than is appropriate | ||
| Description |
if you're undoing a command, "undo" will undo the largest container which ends with the command; this is not always correct behaviour, for example if our document ends halfway through a proof, or if we've made an edit which has reset the parsed container regions, then undo will try to undo the lemma, which is incorrect (and can cause prover state to become inconsistent). one option is to look at the proof state and only undo the largest container which has been closed (processed to the point where it is discharged, e.g. lemma .... sorry). alternatively when we do a parse we could record whether the container is closed. if we have to change the length of that container (e.g. because of an edit) then we reset the container to be open, and we don't undo it until a parse tells us its correct end location. it is possible that i broke this (if this used to work, then it is very likely!), by adjusting the end location of containers when edits are done. however i think the changes i made were necessary. but i think what i did to break it was approximately correct. (were we using empty children or whitespace to indicate that a container is parsed to closure? that would explain how i broke it. if so, i suggest we refactor to use a boolean "containerParsedToClosure" on a container to indicate that it is parsed to closure, rather than sticking empty containers or whitespace into the tree.) |
|||
| #406 | upstream | auto compile bugs when some outputs is done by coqc | ||
| Description |
To reproduce the bug: 1) have in file foo.v the following: Eval compute in 0. 2) Have in file bar.v the following: Require Import foo. 3) then try to script bar.v (with auto-compilation on), compilation of foo.v is started automatically but then there is an error due to the read-only status of coq-compile-response buffer. I think this is due to the fact that coqc compilation *does* the output. Cheers, P. excerpt of buffer *Messages*: Check /home/courtieu/titi.vo Recompile /home/courtieu/titi.v Waiting for process to die...done condition-case: Buffer is read-only: #<buffer *coq-compile-response*> |
|||
| #421 | fixed | proof-shell-exit raises an exception "Buffer foo.v has no process" | ||
| Description |
Hello, here is how to reproduce the bug: open a coq file (say toto.v). proof script one line. hit C-c C-x <enter> yes <enter> and you get this: Debugger entered--Lisp error: (error "Buffer toto.v has no process")
|
|||
