073b2cfc83
as #4527 describes there is inconsistency between `by`, `case` and `next` on the one hand who, if the goal isn’t closed, put squiggly underlines on the first line, and `.`, which so far only squiggled the dot (which is a very short symbol!) With this change the same mechanism as used by `case`, namely `withCaseRef`, is also used for `.`. There is an argument for the status quo: The `.` tactic is more commonly used with further tactics on the same line, and thus there is now a higher risk that the user might think that the first tactic is broken. But * the same argument does apply to `by` and `case` where there was an intentional choice to do it this way * consistency and * a squiggly line just under the short `.` is easy to miss, so it is actually better to underlining more here (at least until we have a better way to indicate incomplete proofs, which I have hopes for) Fixes #4527, at least most of it.
20 lines
484 B
Text
20 lines
484 B
Text
refineFiltersOldMVars.lean:34:18-36:11: error: unsolved goals
|
|
case a
|
|
⊢ True
|
|
refineFiltersOldMVars.lean:44:17-46:18: error: unsolved goals
|
|
case b
|
|
h : Type
|
|
⊢ ?a
|
|
|
|
case a
|
|
⊢ Type
|
|
refineFiltersOldMVars.lean:66:4-66:11: error: no goals to be solved
|
|
refineFiltersOldMVars.lean:101:2-101:13: error: unsolved goals
|
|
case d
|
|
⊢ Bool
|
|
refineFiltersOldMVars.lean:102:2-102:13: error: unsolved goals
|
|
case e
|
|
⊢ Nat
|
|
refineFiltersOldMVars.lean:109:2-109:13: error: unsolved goals
|
|
case e
|
|
⊢ Bool
|