Error message cropped

[janekdb]

It would be useful to be able to see the full error message,

[janekdb]

I have now found the hscroll control which is useful. It would be an enhancement to be able to use more of my screen.

Video: Horizontal scrolling challenge in julia-client 0.4.7

This shows there is plenty of horizontal space to occupy and reduce the amount of scrolling required to see the full messsage,

[marius311]

I agree 100% (as was discussed a bunch here). I can definitely understand the want to keep the output small until its expanded, and then I can kind of understand keeping the vertical size of the output small even once its expanded, but I still really don't see any reason for not using the entire horizontal space available. What of use could possibly be getting covered up?

Just throwing out an idea, what about options "Allow output box to fill screen horizontally / vertically / both" (which could be off by default, i.e. the current behavior)?

[pfitzseb]

I don't think anyone opposes the idea of making expanded results (or results in general) nicer, it's just that no ones gotten around to actually doing it yet.

[MikeInnes]

Yeah, mainly it's just technically a lot easier to have inline results as they are now. We have some patches to atom core which will improve the situation though.

[pfitzseb]

One idea would be to turn the inline result into a block result when expanding, but I'm not sure if that'd feel and look good.

[Karsten7]

@janekdb You can add

.ink.inline {
  max-width: inherit;
}

to your styles.less file (which can be opened using the Menu Bar: File ► Stylesheet...), to remove the default limitation to 400px.

[JobJob]

Adding this just above (and with the same indentation as) this line

pixels2edge = editor.editorElement.getBoundingClientRect().right - (r.view.offsetParent.offsetLeft)
r.view.offsetParent.style.width = pixels2edge - 24 + "px" #-24 for the vert scrollbar and a little clearance

edit: along with @Karsten7's suggestion
is a kludgy but acceptable workaround for me.
@MikeInnes what patches are you referring to in your previous post? How does my fix make you feel? : )

Btw Juno makers I have just been trying Juno out again in the last few days and am loving it! Thank you!

[JobJob]

For anyone game enough to use my ugly fix, here is an even uglier version that works better, I was finding the r.view.offsetParent wasn't always available (some rendering timing issue I guess).

Put this just above (and with the same indentation as) this line

ensureResultResize = ->
  if r.view.offsetParent?
    editorRight = editor.editorElement.getBoundingClientRect().right
    resultLeft = r.view.offsetParent.offsetLeft
    pixelsForResult = editorRight - resultLeft
    r.view.offsetParent.style.width = pixelsForResult - 24 + "px" #-24 for the vert scrollbar and clearance
  else if r? and !r.isDestroyed
      setTimeout(ensureResultResize, 5)
ensureResultResize()

As before you'll need to make @Karsten7's change to your styles.less file (which can be found in preferences->Open Config Folder button on left hand side)

n.b. Edited to add the check for r.isDestroyed to avoid infinite re-calling of ensureResultSize if you managed to clear the results box in the very short time after the result arrived, but before the results overlay got rendered and ensureResultSize was called, and the resize actually happened.

[pfitzseb]

This has been finally fixed in the latest Juno release.

[JobJob]

🎉