Recent

Author Topic: Console In/Output options  (Read 1478 times)

howardpc

  • Hero Member
  • *****
  • Posts: 4144
Console In/Output options
« on: November 30, 2020, 03:45:05 pm »
Is there an option somewhere to set the default width of the Raw Output pane or overall width of the Console In/Output window?
The IDE seems not to remember previously used widths, and usually I find the default not wide enough for debugging, and it would be less annoying if the window remembered its last setting, or if there was an option somewhere to override the default width.
Also, the minimum allowed width of the rightmost section (Output Style, Decorations and Line limit) could be narrower, releasing more pixels for Raw Output on small screens.

« Last Edit: November 30, 2020, 03:47:05 pm by howardpc »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Console In/Output options
« Reply #1 on: November 30, 2020, 04:02:34 pm »
Feel free to fix it Howard. The sizes etc. as recorded at the bottom of the window were intended to indicate that WINCH etc. signals were being correctly caught, and I believe that the decorations have got disabled over the last few months because Martin was trying to sort out parsing UTF-8 stuff coming back from the debugger... Unicode handling always was weak there.

It's still better than how I found it :-)

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Console In/Output options
« Reply #2 on: November 30, 2020, 05:10:34 pm »
The entire window is a big todo.

As for remembering sizes, look at the stackwindow (<install>/debugger/callstastackdlg.pas) => it has code to remember column widths.
This can be reused.

Also, I think that the current choices: hex/text/.... should be display not storage.
I.e. the text should always be stored as it is (stream of bytes), without the entire processing currently done [1].
Choosing one of the displays, should then display all of it in the chosen format.
  [1] The processing would still be done, when assigning storage to the Edit/Display-component.

The long term idea is to use SynEdit (and/or some terminal emulator, for escape sequences)
SynEdit now has word-wrap (beta). So that could also help.
It is possible (but not yet done) to add a hex-display-view SynEdit. Then that would be covered too (but not yet).
It may also be possible to add a "utf8 correction" layer.

IMHO, the window should also have tabs, so you can have one tab, where the entire window is filled with the output (no space allocated for buttons / maybe a context menu to hide the tabs)

So anyone who wants to give that a go => come forward. (or turn around and take a few steps back, then turn around again)

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Console In/Output options
« Reply #3 on: November 30, 2020, 05:26:43 pm »
The big issue appears to be that stuff arrives from the backend in "chunks", which makes both Unicode and EOL handling arduous.

The choice of display options is obviously tailored to the sort of things I've got recollection of having done over the years, which includes some fairly weird terminal-emulation stuff etc.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

Martin_fr

  • Administrator
  • Hero Member
  • *
  • Posts: 9794
  • Debugger - SynEdit - and more
    • wiki
Re: Console In/Output options
« Reply #4 on: November 30, 2020, 05:36:29 pm »
The big issue appears to be that stuff arrives from the backend in "chunks", which makes both Unicode and EOL handling arduous.

That should depend, on who the app writes the content. But it could also depend on the write buffer of stdout.

In any case, that is why the content should be collected as bytestream (no modification / no corrections). Then you can always append.

Of course it would be slow to always re-process the entire blob. But the position of the last safe-point (last eol) could be stored for both the blob, and the processed data.

The other issue is to append correctly to a memo (in case a memo does its own line breaking or whatever). Hence using SynEdit may be better.

(And if SynEdit learns to hold the binary blob, then that makes it even easier)

 

TinyPortal © 2005-2018