Error messages with wrong alignment due to tab characters

[wizeman]

When using tabs for indentation, error messages by the OCaml compiler appear with the wrong alignment:

File "common.ml", line 22, characters 36-55:
22 |            Some (Caml.really_input_string ch (Int32.to_int size))
                                         ^^^^^^^^^^^^^^^^^^^
Error: This expression has type int option
       but an expression was expected of type int
make: *** [Makefile:2: all] Error 1

This ends up becoming annoying if you always use tab characters, as it forces you to go to your text editor and manually go to the columns reported by the compiler to figure out which expression the error applies to.

[github-actions]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[kit-ty-kate]

I'm not sure why this issue has been automatically closed. #9118 was opened almost two years ago to fix this, but wasn't merged and the issue is still there. Should this be reopened?

[Octachron]

With #10582, the issue for single-line error message has been fixed. The issue with multi-line error message seems far less acute: in this case, the user code is possibly misaligned, but there is no mistargeted graphical arrow in the error message itself. It is not clear if the complex solution of #9118 is worthwhile.

[github-actions]

This issue has been open one year with no activity. Consequently, it is being marked with the "stale" label. What this means is that the issue will be automatically closed in 30 days unless more comments are added or the "stale" label is removed. Comments that provide new information on the issue are especially welcome: is it still reproducible? did it appear in other contexts? how critical is it? etc.

[kit-ty-kate]

Can someone reopen this?

also on a tangent, regarding the stale bot, since it was "following the example set by opam-repository" (c.f. #9530): ocaml/opam-repository#22288

[gasche]

also on a tangent, regarding the stale bot, since it was "following the example set by opam-repository" (c.f. #9530): ocaml/opam-repository#22288

Ah, yes, the stale bot is fairly controversial among OCaml maintainers. I'm in the camp that strongly dislikes the stale bot, but we didn't win this argument. I'm worried that if we make too much noise about this, the stale-botters are going to suggest tweaking the setting from "post a comment every six month" to "automatically close the issue after six month" -- so, they will claim in their evil ways, it will be less a nuisance after all. For now we stick to the awkward statu quo and focus on other things.

[dbuenzli]

Ah, yes, the stale bot is fairly controversial among OCaml maintainers.

You should still take into account that's not only a maintainer issue. It's an issue for all of us interacting with this repo and trying to improve the OCaml system.

Each time I receive 30 stale bots messages and the generally at least 2 * 30 messages that follow to basically do nothing about it, I'm on the verge of stopping to follow the ocaml repo.

Another effect it had on me is that I personally no longer care reporting some issues. I just feel it's disrespectful of my time to have issues closed by a bot (e.g. nowadays I wouldn't care reporting issues like this one #10018 which the bot wants to close). Good for you if your metric is the number of open issues, less good if you care about the quality of the system.

Using a bot is an ineffective way of declaring issue backlog bankruptcy. Machines are no substitute for issue curation and if you need a bot to say "no" to people then I think we have a larger problem. A well curated issue tracker is a good way of giving a direction to a project.

There's no harm in replacing the noisy bot by a much more aggressive closing policy (you can always reopen). Especially on vague, non actionable, issues ("ideas", "wouldn't be nice if") which you don't realistically see being solved in the next two years. Even actionable ones but for which there are realistically not enough ressources. These things can live in other communication mediums, or happily be here but closed for the time being.