REPL multiline display

[jlbas]

I'm not sure what's causing this behavior, but numpy arrays are being displayed on a single line in the REPL:

This is strange, as I don't remember this being an issue. Last time I used nvim-dap, the arrays were nicely formatted in the REPL, similarly as require('dap.ui.variables').hover() when multiline_variable_display is set to true:

I tried resetting to previous commits, but the single line formatting is still persistent. Any idea as to what might be causing this behavior?

[mfussenegger]

38a3919 and 41f982b touched the logic that prints the variables.

So if you try to go to an earlier version you'd have to go to 8b7e087

But the multiline handling shouldn't have changed with these commits. Are you sure this used to be different?

Could you enable trace logging (:help dap.set_log_level()) and post the log output you get after entering dx in the repl?

[theHamsta]

There have also been some patches for prompt buffers which could have changed behavior. For example, REPL output is now working without the need to be in insert mode in this buffer at least once.

[jlbas]

Apparently I was not properly resetting to earlier commits while testing. Having figured out how to do so, the output changed from multiline to single line in 41f982b.

It seems to me the newline sequences in the numpy arrays are being replace by whitespaces as a result of

nvim-dap/lua/dap/ui.lua

Line 88 in 41f982b

text = text:gsub('\n', ' ') -- Might make sense to change this and preserve newlines?

This is what the output looks like on d646bbc:

and here is the output log after entering dx in the repl:

[ DEBUG ] 2021-04-29T16:28:10Z-0400 ] ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:711 ]	"request"	{
  arguments = {
    context = "repl",
    expression = "dx",
    frameId = 2
  },
  command = "evaluate",
  seq = 10,
  type = "request"
}
[ DEBUG ] 2021-04-29T16:28:10Z-0400 ] ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:485 ]	{
  body = {
    presentationHint = {},
    result = "array([[[2.38268343, 2.19509032, 2.        , 1.80490968, 1.61731657],\n        [2.2678784 , 2.13656323, 2.        , 1.86343677, 1.7321216 ],\n        [2.15307337, 2.07803613, 2.        , 1.92196387, 1.84692663],\n        [2.03826834, 2.01950903, 2.        , 1.98049097, 1.96173166]],\n\n       [[4.38268343, 4.19509032, 4.        , 3.80490968, 3.61731657],\n        [4.2678784 , 4.13656323, 4.        , 3.86343677, 3.7321216 ],\n        [4.15307337, 4.07803613, 4.        , 3.92196387, 3.84692663],\n        [4.03826834, 4.01950903, 4.        , 3.98049097, 3.96173166]]])",
    type = "ndarray",
    variablesReference = 9
  },
  command = "evaluate",
  request_seq = 10,
  seq = 21,
  success = true,
  type = "response"
}
[ DEBUG ] 2021-04-29T16:28:10Z-0400 ] ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:711 ]	"request"	{
  arguments = {
    variablesReference = 9
  },
  command = "variables",
  seq = 11,
  type = "request"
}
[ DEBUG ] 2021-04-29T16:28:10Z-0400 ] ...nvim/site/pack/packer/start/nvim-dap/lua/dap/session.lua:485 ]	{
  body = {
    variables = { {
        name = "special variables",
        type = "",
        value = "",
        variablesReference = 24
      }, {
        name = "[0:2] ",
        type = "list",
        value = "[array([[2.38268343, ...6173166]]), array([[4.38268343, ...6173166]])]",
        variablesReference = 25
      }, {
        name = "dtype",
        type = "dtype[float64]",
        value = "dtype('float64')",
        variablesReference = 26
      }, {
        name = "max",
        type = "float64",
        value = "4.38268343236509",
        variablesReference = 0
      }, {
        name = "min",
        type = "float64",
        value = "1.6173165676349102",
        variablesReference = 0
      }, {
        name = "shape",
        type = "tuple",
        value = "(2, 4, 5)",
        variablesReference = 27
      }, {
        name = "size",
        type = "int",
        value = "40",
        variablesReference = 0
      } }
  },
  command = "variables",
  request_seq = 11,
  seq = 22,
  success = true,
  type = "response"
}

[mfussenegger]

Thanks for investigating further.

I'll either restore the old behavior or have an option to expand/configure the multiline behavior as part of #165

[patnr]

Apologies if I'm missing something obvious, but is there any chance of multiline output printing coming back?