Scrolling the text editor in bottom pane and getting line height

#1

So I’m creating a TextEditor in a bottom pane like so (abbreviated for brevity):

...
Class MyView
    @element = document.createElement 'div'
    @textEditorView = document.createElement 'atom-text-editor'
    @element.appendChild @textEditorView
    @textEditor = @textEditorView.getModel()
    ....
    scrollDown: () ->
        @textEditor.setCursorBufferPosition(@range.start)
        @textEditor.scrollToCursorPosition()
Class MyModel
    @element.appendChild @textEditorView
    @MyView = new MyView()
    @panel = atom.workspace.addBottomPanel(item: @MyView.getElement(), visible: true)
    @MyView.scrollDown()
...
myViewStyle { overflow: scroll; height: 300px;}

But the editor does not scroll when my scroll method is called, only when the user actually scrolls manually, similar to the issue described here.

This leads me to two questions:
1. Is there a way to get this TextEditor in the bottom pane to scroll via the API like I want?
2. If not, I figure I can get it to scroll to where I want with some CSS hacks, but I’d need to be able to get the current line height of the editor in pixels. Is there a way to get this value?

#2

I ran into the same problem a week ago. You have to set position: absolute; CSS property on the atom-text-editor element:

.my-awesome-panel atom-text-editor {
  position: absolute;
}

See also this topic:

#3

Ah thank you again @olmokramer ! That seems to have fixed my problem. Would you happen to have any insight as to why the editor wouldn’t scroll the first time its opened, but does so every subsequent time after that?

#4

You’re welcome :smile: Whether the text editor is allowed to scroll depends on the height of the .editor--private (or .editor-contents--private, can’t remember), and this height depends on whether the element has position: absolute; or not, I don’t really understand why. So if the height is calculated before your panel is attached to the DOM, and thus its style hasn’t been calculated yet, the height is calculated incorrectly the first time… or maybe the height couldn’t be calculated correctly because your panel had display: none;. Or maybe something else along those lines… You can probably fix this by calling editor.getDisplayBuffer().setHeight(editorView.clientHeight) or something similar after your panel is visible for the first time.

#5

Hmm so I’ve tried a variety of ways to set the height like you said in the above post, but my issue is still there. Currently I’m trying to use a callback like so

@panel.onDidChangeVisible () =>
  @editor.displayBuffer.setHeight(@editorView.clientHeight)
  @scrollEditor()
@panel.show()

But this doesn’t seem to work. Is there another callback or something that will be triggered when the appropriate height has been calculated?

#6

After reading through the source code, you might actually have to call @editor.displayBuffer.setHeight(someHeight) before showing the panel/attaching the panel to the DOM… I remember I did something like that to fix this problem, but I also remember that somehow along the road I didn’t need it anymore. If you can give me a link to the rest of your code I would be willing to take a look at it and hopefully find the real cause of this. In the meantime, you could take a look at my minimap-codeglance package and how I use the text editor there. Now that I think about it, maybe explicitly setting @editorView.style.height might be the actual fix to the problem. Try setting it before you attach the panel, if that doesn’t work try after attaching the panel and if that doesn’t work, try both (although the last one sounds like a stupid fix…).

#7

Ah okay I’ll continue messing with it for the night. The repo is here if you have a minute and happen to see the whats causing the problem. Just go over into text.html, put your cursor over the id name (id="…|…") and hit shift-cmd-e to reproduce my issue. It should scroll the editor directly to the class name, which it only currently does the second time onwards. Thank you again.

#8

Thanks, I’ll take a look at it tomorrow :smile:

#9

Hi @Maushundb, I’m sorry but I got terribly busy over the weekend. I’m free tomorrow, though.

#10

Hey @olmokramer don’t worry about it, I changed some stuff to work around the issue :blush: Thank you so much for the help though!