Option for avoiding overlay movements #11852

Merged
merged 8 commits into from Dec 12, 2016

Projects

None yet

6 participants

@MikeInnes
Contributor
MikeInnes commented May 26, 2016 edited

Right now overlays will often move up and down as you scroll, attempting to stay within the editor view. This makes sense for autocomplete, but less sense for things like annotations in code (see e.g. Ink, Hydrogen packages). Indeed in these cases the jumpiness feels very unstable.

So I added a simple option which turns it off. The name could probably do with refinement.

Edit: more helpful diff. Also, same testing concern as #11864.

@50Wliu 50Wliu added the needs-review label Jun 4, 2016
@OmarShehata

+1! I'm working on a tool to do some code analysis and annotation, definitely need this.

@lee-dohm
Member

We would need some specs to ensure we don't accidentally break this in the future too.

@MikeInnes
Contributor

Understood – do you have any comments on the testing concerns I mentioned in the linked issue? In particular,

I can't seem to find current tests and it seems like being headless causes difficulties for testing things like positioning.

Advice on what would make for an acceptable test would be much appreciated.

@OmarShehata OmarShehata referenced this pull request in OmarShehata/atom-tracer Aug 14, 2016
Open

Result div's move when scrolling #1

@Haacked
Haacked commented Aug 26, 2016

I'm not sure there's a good way to test this. I'll follow up on that.

In the meanwhile, there's a legitimate build failure here.

src/text-editor-presenter.coffee
line 478 Don't use &&, ||, ==, !=, or ! Replace "!" with "not"

Looks like an easy fix to at least get the build passing. 😄

@MikeInnes
Contributor

Ah yes, missed that – fixed!

@nathansobo
Contributor

Maybe we should phrase the naming in the inverse. Maybe an option like avoidOverflow which defaults to true but you can assign to false? I'd love to hear some other name ideas if you don't like avoidOverflow... that's just off the top of my head.

@Haacked
Haacked commented Aug 26, 2016

@MikeInnes regarding the testing question. I don't think we have any good way right now to write an automated test that exercises the UI and ensures that overlays stay in the same position as you scroll.

But there's probably a way to write a unit test to test this code in isolation such that the test fails when you revert your changes, but succeeds with your changes. Does that make sense?

@OmarShehata

Any news on this being merged?

@MikeInnes
Contributor

Apologies for letting this slide for a while. @Haacked Good news is I found the overlay positioning tests (perhaps they are new or I just missed them), so the tests I've just added are checking this really works :)

@nathansobo I'm not wildly opinionated about the name so will be happy to change to whatever the consensus is. avoidOverflow seems sensible – perhaps fixed or stayVisible as alternatives? Aside, it may be worth considering making this mode the default, assuming we can figure out an acceptable approach to backwards compatibility.

MikeInnes added some commits May 26, 2016
@MikeInnes MikeInnes add `stable` option e5ab835
@MikeInnes MikeInnes Update text-editor-presenter.coffee 20545ad
@MikeInnes MikeInnes scroll test
f9ef678
@nathansobo
Contributor

Taking a look at the failing tests.

@nathansobo nathansobo Rename `stable: true` to `avoidOverlay: false` and fix tests
As part of the test fixes, I’m honoring the `autoscroll: false` option
in `insertText` and `insertNewline` to avoid inadvertently scrolling the
editor during tests when the editor is modified.
f4c45c1
@nathansobo
Contributor
nathansobo commented Nov 28, 2016 edited

@MikeInnes can you give me push access to this branch? I made some changes in f4c45c1 that I'd like to apply to this PR before merging.

@MikeInnes
Contributor

Thanks @nathansobo, I've added you as a collaborator on my fork of atom.

@nathansobo nathansobo Document avoidOverflow option
a8930df
@nathansobo
Contributor
nathansobo commented Nov 28, 2016 edited

Thanks for granting me access. I also just added some documentation for the new option. For future reference, it's now possible to allow repository owners to make changes just to your pull request branch when you open the PR. But being a full collaborator works as well. Thanks for taking the initiative with this change. Hopefully we get a green build.

nathansobo added some commits Nov 28, 2016
@nathansobo nathansobo Merge remote-tracking branch 'origin/master' into MikeInnes-overlay-s…
…croll
851ae42
@nathansobo nathansobo Merge remote-tracking branch 'origin/master' into MikeInnes-overlay-s…
…croll
5060618
@nathansobo nathansobo Merge branch 'master' into MikeInnes-overlay-scroll
953e8ee
@nathansobo
Contributor

Figured out a CI failure caused by something on our end. Running another build now and will merge once it's green.

@nathansobo nathansobo merged commit 0a5f74a into atom:master Dec 12, 2016

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@nathansobo nathansobo deleted the MikeInnes:overlay-scroll branch Dec 12, 2016
@nathansobo
Contributor

Thanks for this contribution @MikeInnes! ⚡️

@MikeInnes
Contributor

Awesome, thanks for the help @nathansobo!

@pfitzseb pfitzseb referenced this pull request in JunoLab/atom-ink Dec 22, 2016
Open

inline results can cover executed code #107

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment