Custom Query (361 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (7 - 9 of 361)

1 2 3 4 5 6 7 8 9 10 11 12 13
Ticket Resolution Summary Owner Reporter
#204 fixed undo stops undoing in large proofs David Aspinall mccreight
Description

In large Coq proofs (with more than 100 lines), undo stops working.

For instance:

Lemma Foo : True.

idtac.

[repeat "idtac." around another 112 times]

assert (NI : ~False).

intros IX; auto.

(* Process the script until here, then undo back 3 or 4 lines.

Notice that NI doesn't disappear. *)

#157 duplicate undo sometimes incorrectly tries to undo a larger container than is appropriate David Aspinall alex heneveld
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.)

#303 fixed underlining on error sucks David Aspinall Alexander Krauss
Description

While others may report more fundamental problems, here is another usability issue:

Underlining the command that causes an error seems like a nice idea at first... But in reality it just sucks:

It does not give me any useful information, since I immediately see which command is broken anyway. To the contrary, the underlining makes it more difficult to spot the error, because the sources are much less readable. This becomes even worse if I happen to have the mouse over the thing. Then everything turns all red and I lose syntax highlighting...

I mentioned this over lunch and found out that some colleagues independently discovered the same workaround that I use: Move point to the command area, hit space, hit backspace to make the underlining disappear. Then keep on working.

Although it is meant to be a help, I think this is a big step backwards in usability. Is there a way to disable it? And it should be disabled by default.

Alex

1 2 3 4 5 6 7 8 9 10 11 12 13
Note: See TracQuery for help on using queries.