@Kha I marked the corresponding methods as `protected`.
I currently can't stand `throw_error`, and I am optimistic about
server highlighting feature you are working on :)
@Kha The old `= true` workarounds are not needed anymore, they were
due to another issue and are not related to yesterday's issue.
That is, the one exposed by the `ForIn` typeclass.
When `pp.safe_shadowing` is set to true, we still use the
suggested name if the "body" does not contain a free variable with the
suggested name. This is the approach used in Lean 3, and I think it
improved the result in all affected tests.
The implementation was simple. The only nasty case was `delabAppMatch`.
The main motivation for this feature was hovering information such as
```lean
f : {α_1 : Type} → α_1 → α_1
```
when hovering over the `f` at
```lean
def g (α : Type) (a : α) :=
f a
```
With `safe_shadowing`, we get the nicer
```lean
f : {α : Type} → α → α
```
cc @Kha
@Kha Now, all parsers defined by `Init/Std/Lean` packages have
precedence >= `min` and <= `max`.
The only exception is `<|>` since it is an infix operator sharead with
the tactic DSL.
BTW, the meaning of `f $ a <|> b` changed with this commit.
It was `f (a <|> b)`, and now is `(f a) <|> b`. The problem is that
the precedence of the `$` parser is now greater than the `<|>` parser.
I will try another experiment where I make sure we do not "reuse"
term infix operators in the tactic DSL.
@Kha It seems the new builtin antiquotation notation you added depends
on the array literal notation that is not builtin. I got the following
error after `update-stage0`
```
Lean/PrettyPrinter/Delaborator/Builtins.lean:455:2: error: elaboration function for '_kind.term._@.Init.Data.Array.Basic._hyg.3391' has not been implemented
```
The base name changed from `_kind.term` to `termKind`. I had to change
it because every parser we were defining was in the artificial (sub-)namespace
`_kind` :)
We didn't notive because we didn't have scoped parsers.
