Comment author: kaaira

can i please work on this issue?

Is there anyone currently working on this bug? If not I would like to try it as a first contribution to the project. Any help in getting started would be greatly appreciated.

User "kaaira" mentioned interest last month, but we haven't heard from them since, so I would assume that no one is working on this bug.

On how to get started: I see two approaches

• We could just extend the size of the lexing buffer beyond what a user would reasonably send to their toplevel. Currently the size is set in stdlib.ml/lexing.ml in from_function, and is hardcoded to 1024 (bytes). We could bump this to, say, 2^17 (131072), if we decided that the increase in memory usage is reasonable; or we could make this value an optional parameter of the function, and only bump it for the one call that initializes the toplevel lexing buffer, in toplevel/toploop.ml:loop.

• We could follow the discipline suggested by @Armael of storing the whole toplevel phrase in a buffer exposed as a new global value by toplevel/toploop. Then in the part of parsing/location.ml that highlights code sections, when we detect that the input name is "//toplevel//", we can go look in that phrase buffer instead of the lexing buffer. This is a cleaner solution, but it is a bit more delicate to implement because you have to understand the phrase-parsing logic in toploop (where phrases start and stop) to reset the phrase buffer at the right time. I think that you should add content to this buffer in toploop.ml:refill_lexbuf and reset it where Lexing.flush_input is called.

Note: To understand how toplevel parsing work, in addition to toplevel/toploop.ml (and maybe stdlib/lexing.ml) you may want to have a look at parsing/parse.ml, the skip_phrase business.

Thank you so much for your help! I will get started on this.

While working on this issue, I came across something that I need to be clarified. Line 355 of parsing/location.ml reads if !lines >= Terminfo.num_lines stdout - 2 then raise Exit;. This is in the highlighting code and it seems to me that what this is doing is that regardless of how big the buffer storing the phrase is, the code will bail out if the phrase exceeds a certain number of lines. Is my thinking on this issue correct and if so how would I go about fixing the code so that the cursor can be moved up an arbitrary amount of lines and doesn't bail out for expressions with exceptionally long lines?

Ah, indeed. I think my original bug report is missing some information, and I'm sorry about that.

The interactive toplevel has two different ways of "highlighting" an error. In the "fancy" mode, it uses ANSI codes to go up in the terminal and underline the part of the input phrase corresponding to the location. This is the mode used by default (provided your terminal supports this but it is generally the case). The function responsible for this is highlight_terminfo as you have seen.

Alternatively (typically, because it is running in emacs through M-x eval-buffer, or if you run the toplevel with TERM=dumb in the environment), the toplevel can fall back to "highlighting" the location by printing it again (just like the normal compiler output).

Regarding this bug report, I was originally concerned only by the "dumb" highlighting mode. So I think it would already be nice to get this one fixed.
After this is done and if you feel motivated, you could try investigating if something could be done for the "fancy" mode as well. Maybe it could fallback to the "dumb" mode if the error appears outside of the terminal screen -- or maybe underlining text outside of the terminal screen is okay (the user would just have to scroll up to see it), and the test if !lines >= Terminfo.num_lines ... could simply be removed.

Ahhh thank you so much for the clarification that helps out a lot!